Communications hardware for Universal Ground Control Stations: Narrowing the field to AdvancedTCA

2With the proliferation of Unmanned Aerial Systems (UASs) across branches of the military, the concept of a Universal Ground Control Stations (UGCS) has emerged. Though common software architectures are already being established for these UGCSs, they still require a uniform, Modular Open Systems Approach (MOSA) to communications hardware. Selecting the appropriate architecture for UGCSs requires an evaluation of the performance, price, and environmental characteristics of available systems, with AdvancedTCA (ATCA) emerging as the most well rounded option for next-generation ground controllers.

The UAS market has rapidly evolved over the last 10 years. Initially, each type of UAS had limited mission capabilities with unique Ground Control Station (GCS) software and architecture, but over time UAS capabilities have increased significantly and the concept of a UGCS capable of manipulating multiple unmanned platforms has been adopted by the Department of Defense (DoD). This interoperability was demonstrated in 2011 at the Manned-Unmanned Systems Integration Capability (MUSIC) exercise, where control of UAS sensors was handed off between a UGCS and a Mini-Universal Ground Station Controller (M-UGCS), displaying the ability of a helicopter to receive video feeds and metadata from a UAS and forward it to troops on the ground.

While the concept of UGCS software is now intuitive for larger UAS platforms, there is ongoing discussion regarding hardware architecture. There are currently deployments based on commercial-grade servers, rugged Rack Mount Servers (RMSs), VME/VPX, and ATCA. While each hardware alternative has its advantages and disadvantages, to better understand them a look at the overall requirements and functions of UAS and GCS platforms is needed.

UAS control challenges and requirements

To understand the requirements of a UGCS for UAS platforms, the diversity and challenges of unmanned platforms themselves must first be considered. Multiple types and sizes of unmanned aircraft are employed across the various branches of the DoD, from small UASs such as the Wasp III or Raven that are used at the platoon level, to larger high-altitude systems like the MQ-1C Gray Eagle and RQ-4 Global Hawk. Because of the increased emphasis on extremely low Size, Weight, and Power (SWaP) in smaller UASs, as well as their range and endurance limitations, small UASs are typically autonomous or have a portable GCS that can be carried in a backpack. Most of these types of UAS have rugged hand held controllers, and that trend will continue.

For larger UASs, bandwidth to the GCS is a far more major concern (especially if the data link to the UAS is via satellite), as increased range precipitates larger amounts of video and metadata that need processing. One idea to address these bandwidth concerns is to take functions of the GCS and put them on the UAS, such as pre-processing sensor data on the unmanned platform itself to reduce bandwidth requirements. Another concept is to take some of the control functions from the GCS and provide the UAS with more autonomy.

Concurrently, though, there is also increasing pressure to add more sensors or weapon systems to the UAS. As with any aircraft, weight on UASs is directly related to range or endurance, and adding payload increases weight and bandwidth requirements. The final direction is not yet clear, but more payload will likely be added to the UAS with the majority of control and data processing continuing on the GCS.

General GCS hardware functions and requirements

A GCS is required to handle multiple functions, such as providing the main machine interfaces that allow operators to control the UAS, establishing external communication links to the UAS and other military units, and adding security for those links and the networks they are traversing. While most of the equipment within control stations has already been standardized, there is still a large amount of hardware variation in the switching, computing, and storage equipment of their communications systems. These assets must be able to monitor the controls of multiple UASs, receive sensor data, process it, store and retrieve it, and provide the information in a graph format. There are also background tasks that are required, such as providing mapping information, and many of these systems have started to look into virtualization technologies as well.

Performance requirements

The overall system requirements for computing, switching, and storage in a GCS are relatively straightforward. The computing requirements are fairly large and require multiple server-class processors since the memory density is fairly high and will continue to grow. Switching demands, on the other hand, are not as significant as many would think – HD video requirements lie somewhere between 4 Mbps and 6 Mbps, so even when dealing with multiple streams of HD video and other metadata, the bandwidth required should be under 10 GbE per computing element. There are two types of storage requirements for most GCSs – local storage on the computing element for storing application or other data used to operate the system, and a larger storage array used to save video or metadata coming off the UAS for later replay or distribution.

Environmental requirements

In order to evaluate hardware alternatives for a GCS, it is important to look at the possible physical requirements that will be placed on them. There are multiple deployment environments for GCSs, and each has unique environmental issues that need to be addressed:

  • Stationary: For these deployments, GCS equipment can either be in a container or at a command center. Typically, container systems are shipped with equipment fully installed, so the equipment needs to be able to withstand the vibration and shock of non-operational transport, although it is not moved as often as in a ground mobile type of deployment. The equipment could also be shipped to a command center after being broken down in transit cases to reduce some of the shock and vibration.
  • Seaborne: During these deployments, the GCS is often located in the ship’s data center. Equipment is usually sealed in shock-isolated racks that also provide conditioned air to minimize shock and vibration. In other cases, they may be installed in less ideal locations on the ship, and will need to be able to handle the typical shock and vibration of that environment.
  • Ground mobile: In these types of deployments, GCSs are typically mounted in a shelter on top of a vehicle. While the equipment is typically not operating when the vehicle is moving, it must be able to withstand shock and vibration transmitted to the rack when the vehicle is in motion.

In all cases, once the GCS is operational the air that the equipment is required to operate in will be benign (20 ºC to 35 ºC). However, there could be temperature ranges outside of this during initial startup, and dust and humidity are potential issues that might need to be addressed as well.

As with any military field deployment, there are other “soft” requirements, such as the desire for a minimum of 5-7 years of new hardware and support for units in the field, a 7-10 year lifecycle, good SWaP, and quick field serviceability. These factors considered, the ideal solution for a GCS communications system is standard-based COTS.

Comparing GCS hardware options

There are several hardware options available that can be used for GCS communications systems, including commercial or rugged RMSs with external switches and standard COTS blade architectures like VME/VPX and ATCA. Table 1 shows a high-level summary of how the different architectures can meet the requirements of GCS hardware.

Table 1: Each hardware option for GCS communications has its pluses and minuses.

Though total system cost will vary by the specific configuration, Table 2 shows the rough magnitude of the system cost of various hardware options.

Table 2: Relative cost per hardware architecture

Rack Mount Server systems

Commercial RMS systems

From an acquisition cost perspective, commercial RMS hardware is an attractive alternative as it contains the processing, switching, and storage capacity necessary to handle the requirements of a GCS. However, commercial RMS systems face challenges in several other key areas. Because commercial hardware is designed for installation in data centers where it is not frequently moved, these systems struggle in deployment environments that require equipment to be transportable. These products can be ruggedized by third parties, but that significantly increases cost.

Commercial RMS-based solutions tend to be pizza box designs that are stacked one on top of the other, each with its own metal enclosure, power supplies, and fans. Because of this architecture, they are also significantly heavier and consume more power than bladed architectures in which the enclosure, power supplies, and fans are shared among all of the computing, switching, and storage elements. In addition, because these systems are designed for commercial use, they also have shorter lifecycles, providing 3-4 years of service. This is compounded by the fact that commercial RMS architectures are generally proprietary, so components are usually only available from a single vendor at a higher price point.

Rugged RMS systems

Rugged RMS systems are designed to handle more rugged environments than their commercial counterparts; they have the right processing capability and it is possible to get longer lifecycles from them. The two challenges rugged RMS solutions face are with weight and power consumption. Compared to standardized COTS solutions, RMSs are typically 25-33 percent heavier and consume more power because they require multiple power supplies. In addition, larger systems are more difficult to service. Specifically, because Ethernet connections are often externally wired, replacing a failed unit requires that the servicer ensure all connections are made correctly and securely. The added weight of a rugged RMS makes this field replacement process more difficult than in bladed systems.

Bladed COTS architectures

Both VME/VPX and ATCA architectures offer standards-based COTS solutions that are well suited for GCS environments. As shown in Table 1, these too have unique advantages and disadvantages.


VME/VPX hardware easily meets the previously mentioned ruggedization, long lifecycle, and SWaP requirements, but it presents challenges in terms of performance and cost. The board size of VME/VPX systems is smaller than RMS or ATCA offerings, so it has difficulty fitting the processor memory and other components necessary for higher performance processing. It is also more expensive, as VME/VPX sells mainly into rugged Aerospace and Defense (A&D) verticals, and is differentiated in the marketplace through the many hardware variations available; unlike ATCA, VME/VPX does not consider high-volume commercial applications that drive cost points down.


Conversely, ATCA is a standard COTS bladed architecture that was designed to work in modern telecommunications networks. Because it was targeted at high-density networking applications, ATCA meets the performance requirements of GCS applications and offers an 8x performance improvement over VPX and 40x the computing horsepower of VME.

ATCA systems have a better performance per dollar ratio over competing technologies because they ship in volume from multiple vendors. As ATCA is a bigger form factor, a single board can contain higher performance processors and better clock speed, as well as more memory on a single board than VPX solutions. The difference in processing can be as much as 15 percent, translating to a 35-60 percent better price/performance ratio for ATCA than VPX.

Though it is not as hardened as the VME/VPX specifications, ATCA systems comply with Network Equipment Building Standards (NEBS), giving them a moderate degree of inherent ruggedization. In order to handle vibration in a seaborne or ground mobile environment, extended ruggedization can also be applied to bring commercial ATCA systems into accordance with MIL-STD-810 and MIL-STD-901 (Figure 1). This might include using machined card guides instead of stamped card guides, and stiffening the chassis. If the application is more rugged than the system was designed for, there might be some minor mechanical modification of the hardware needed.

Figure 1: The Gemini 14-slot Vertical ATCA Rugged COTS Chassis has been vibration tested for compliance against MIL-STD-810 Method 514.4, MIL-STD-167 Type 1, and against MIL-STD-810 Method 513.5 for acceleration.

A universal approach to a ground control

The Modular Open Systems Architecture (MOSA) being adopted by the DoD has resulted in a good comprehension of the benefits of standardized COTS architectures. Defense acquisition groups understand that by using established COTS hardware they can leverage an interoperable architecture, reduce hardware variation in the field, and reduce the cost of testing and certifying new components. Considering all available hardware options, ATCA is the best choice for building the majority of future UGCS systems.

Rick Nace is a Senior Staff Engineer at LCR Electronics, Inc.

Donald Germany is the Product/Engineering Manager for System Integration at LCR Electronics, Inc.

LCR Electronics