Over the last decade, the DoD has proven great benefit from the use of UAS for both peacetime and wartime operations. These successes ignited a significant increase in the number of UAS planned and procured and the future only looks to see an exponential increase in the quantity and diversity of UAS applications. Traditionally, each UAS was procured with its own stovepipe control segment, typically referred to as a Ground (or ship based or airborne) Control Station (GCS). These GCS operated one system variant and were typically "closed" systems utilizing proprietary interfaces. Development of the GCS was performed alongside the aircraft development and was procured through the aircraft prime contractor. As the number of new UAS were programmed in the Service budgets, the magnitude of RDT&E requirements for development of the associated GCS skyrocketed.

STANAG 4586 took the first step towards interoperable control segments, documenting a standard for unmanned aircraft/GCS system level command and control interoperability. This is the first step towards enabling GCS to control and monitor multiple types of unmanned aircraft, improving overall cost by reusing GCS, and enabling competition at the system level for complete GCS solutions. It also allows for command and control to be instantiated separate from traditional "ground" control segments (e.g. Army Apache control of ER/MP).

Command and control is just one perspective, however, and being satisfied with system level interoperability has significant consequences. Today, in order to improve situational awareness or bring improved capabilities to bear for the UAS operator, system acquisition program managers may have to recapitalize their entire inventory of GCS depending on the required change. This is a significant cost burden. In several cases, the number of UAS required for one system (after all aircraft and GCS deliveries) numbered 150-200 GCS when one includes systems integration labs, flight test assets, backup inventory, initial qualification training assets and continuing training assets. Adding in the upfront non-recurring engineering costs make improvement of the GCS through recapitalization near unaffordable, especially when you consider the vast number of varying UAS systems being considered in future Defense planning.

A common control system is not the answer to the RDT&E, interoperability, or production problems. This solution reduces competition and makes upgrades slower and more costly. One Service may have a particular need another does not and in order to stay common the sister Service would be forced to upgrade to a capability they do not want or need. In addition, each UAS has different missions, concepts of operation, physical requirements, deployment requirements, etc. Mission effectiveness mandates a tailored Human Machine Interface optimized through proper Human Systems Integration processes, considering the mission, information needs, and operator qualifications.

In order to enable future capability upgrades through competition without recapitalizing the fleet, this project must "break open" the UAS Control Segment components defined in STANAG 4586 into a modular and scalable architecture that can be implemented according to individual UAS needs. The architecture needs to be defined only to the level that:

• Allows for acquisition flexibility at system, subsystem, component, application, and service levels;
• Enables innovation at all levels of industry--UAS & non-UAS domains, especially at the subsystem and component/application/service levels;
• Allows for reuse across Service & Joint UAS programs where appropriate;
• Is scalable from systems such as a Scan Eagle laptop to a ER/MP OSGCS to a Global Hawk fixed facility to a ROVER;
• Can rapidly integrate new unmanned aircraft, sensors, weapons and other payloads while tailoring the Human Machine Interface to the mission;
• Is agnostic to a specific hardware and operating system;
• Can be implemented locally or over a geographically distributed system (including flight control);
• A core (and extensible) set of application platform interfaces and services is defined to promote openness and effective competition among application developers;
• Allows reuse of integrated applications or supporting tools/services across UAS programs with minimal effort;
• Separates critical safety-of-flight operations from mission support operations;
• Reduces the safety and airworthiness certification effort when introducing new mission capabilities;
• Separates security critical functions from other functions;
• Reduces the information security certification and accreditation effort when introducing new mission capabilities;
• Provides an open system interface with external systems including the GIG (as specified by the Net-Ready Key Performance Parameters) (NR-KPP).;
• Reduces the interoperability certification and accreditation effort when introducing new mission capabilities;
• Provides for a highly composable system using recombinant components that can be selected and assembled in various combinations to satisfy specific user requirements;
• Can evolve with changing missions, standards, and instantiations.