This is an overview of the concepts and services supported by the UCS Architecture. Click on an element for more information about it.
Applications are a combination of one or more services, infrastructure, and information resources that enable UAV operations. Separating the HMI “front end” from the services themselves allow the same service implementations to potentially support multiple form factors. It also allows a Program to implement its specific HMI requirements to support the Warfighter.
The Infrastructure layer provides capabilities that are necessary for services to function cooperatively.
Information resources within the control segment are managed, and supported via the Software Services, to reduce redundant storage and facilitate a single operational view.
The Software Services are specified to be technology-neutral, allowing a Program to select the right middleware for its requirements. Examples of potential middleware technologies include SOAP (W3C), DDS (OMG), the Java Message Service, and XMPP.
The UCS Architecture is designed to support a wide range of operating systems, from embedded to virtual systems to common workstation options.
| Subdomain | Status |
|---|---|
| Vehicle Management | ready for prototyping as of UCS 1.0 |
| Vehicle Message Layer | ready for prototyping as of UCS 1.0 |
| Sensor Management | ready for prototyping as of UCS 1.0 |
| Effects Management | ready for prototyping as of UCS 1.0 |
| Communications Management | ready for prototyping as of UCS 1.0 |
| UAS Health & Status Management | ready for prototyping as of UCS 1.0 |
| UAS Resource Management | ready for prototyping as of UCS 1.0 |
| Cargo Payload Management | ready for prototyping as of UCS 1.0 |
| Comms Relay Payload Management | ready for prototyping as of UCS 1.0 |
| Mission Management | ready for prototyping as of UCS 1.0 |
| Survivability Management | ready for prototyping as of UCS 1.0 |
| Subdomain | Status |
|---|---|
| Sensor Product Management | ready for prototyping as of UCS 1.0 |
| Sensor Product Archive | ready for prototyping as of UCS 1.0 |
| Sensor Product Capture | ready for prototyping as of UCS 1.0 |
| Sensor Product Exploitation | ready for prototyping as of UCS 1.0 |
| Sensor Product Dissemination | ready for prototyping as of UCS 1.0 |
| Subdomain | Status |
|---|---|
| Mission Planning | partial service definition as of UCS 1.0 |
| Data Dissemination | partial service definition as of UCS 1.0 |
| Airspace Planning | partial service definition as of UCS 1.0 |
| Effects Planning | partial service definition as of UCS 1.0 |
| Route Planning | partial service definition as of UCS 1.0 |
| Sensor Planning | partial service definition as of UCS 1.0 |
| Vehicle Planning | partial service definition as of UCS 1.0 |
| Subdomain | Status |
|---|---|
| Air Traffic | partial service definition as of UCS 1.0 |
| Battlespace | partial service definition as of UCS 1.0 |
| Environment | partial service definition as of UCS 1.0 |
| Situational Awareness | partial service definition as of UCS 1.0 |
| Subdomain | Status |
|---|---|
| Tactical Message Management (C4I) | partial service definition as of UCS 1.0 |
| Collaboration | no service definition as of UCS 1.0 |
| Subdomain | Status |
|---|---|
| Logistics Management | no service definition as of UCS 1.0 |
| Maintenance | no service definition as of UCS 1.0 |
| Mission Record & Playback | no service definition as of UCS 1.0 |
| Mission Support Information | no service definition as of UCS 1.0 |
| Training | no service definition as of UCS 1.0 |
The UCS Software Services are specified to be technology-neutral, allowing a Program of Record to select the right middleware software platform for its requirements. Consistent with the MDA philosophy adopted for UCS, a specific middleware software platform would be the target PSM in the PIM-PSM transformation chain.
This page describes two platforms referenced by the UCS Working Group to inform development of the PIM and transformation chain guidance. They are not the only middleware software platform alternatives, and neither is mandated by UCS.
DDS is an open standard managed by the Object Management Group (OMG). DDS employs a data-centric integration model to decouple applications. Applications communicate by publishing the data they produce and subscribing to the type of data they consume. They require no knowledge of each other, only of the data they exchange. Importantly, DDS goes beyond simple publish-subscribe. DDS middleware enables a “plug in” open architecture approach to integration.
 |
A simple application illustrating DDS concepts may be found here. |
 |
DDS has been used as the middleware software platform for the development of some prototype UCS service implementations.
 |
 |
The Web Services platform is comprised of a group of open standards maintained by the W3C or by OASIS. Web Services are frequently associated with the Service Oriented Architecture (SOA) paradigm because the Web Services platform realizes many of the design principles of SOA.
 |
While there are many resources on the Web, a good overview of the standards is available here. |
 |
The Technical Reference Model (TRM) for the UCS Architecture is based on the IEEE POSIX Open System Environment (OSE) Reference Model defined in IEEE-Std-1003.0-1995.
Figure 1: UCS Architecture Reference Model
The TRM comprises three principal layers:
The Application Layer is the focus of the UCS Architecture effort, and is described in the Architecture Model work product. The Application Platform Layer is described in the Core API Standards work product. By participating in the UCS Working Group, you can access currently available documents.
The External Environment includes Human-Computer Interfaces (HCI), information access/storage, and external communications.