The UCS Architecture is a service oriented architecture (SOA) and modeling framework for the specification, integration, implementation, and deployment of control station software. The architecture is centered on the specification of service interfaces and an associated data model. Platform independence (i.e. independence from the software operating environment) allows the UCS Architecture to be implemented on different platform technologies.

Service Model

In UCS, a service is a capability to achieve a real-world effect. Services are organized and accessed within the SOA paradigm. In a SOA, service providers and consumers are modeled as service participants. A participant represents a role that may be allocated to software components in a software product line (SPL). A participant is a service provider if it offers a service port, and it is a service consumer if it uses a request port. Participants may have any number of service ports and request ports.

To illustrate the UCS principle of services, the following example is provided:

Below is a SoaML model of a service participant. The participant called VehicleFlightStatus provides one service port called VehicleFlightStatus and uses two request ports called WCA (warnings cautions and advisories) and VehicleInterface. A service port has two logical interfaces: requests (incoming) and responses (outgoing). The interface direction is the opposite way for request ports.

A SOA may have hundreds (or perhaps thousands) of services, and therefore they are modeled within a formal service taxonomy. Below is a fragment of the UCS service taxonomy. Here VehicleFlightStatus is one of eight services that collaborate to form the Vehicle Management subdomain. This subdomain is one of eleven service subdomains that form the Primary Mission Control (PMC) domain. This service domain is one of six domains in the UCS Architecture.

In the UCS model, a service represents the smallest unit of accessible capability. Higher levels of capability are achieved by one (or more) service subdomains using one (or more) of their services. In a SOA, higher capabilities are modeled by use cases. For example, the use case called L2 Execute Vehicle Flight Control is achieved by participants in the Vehicle Management subdomain and Vehicle Message Layer subdomain.

Using the current example of the VehicleFlightStatus participant, the VehicleFlightStatusRequests interface has four operations: getVehicleFlightStatus, receiveVehicleWCA, startVehicleFlightStatus, and stopVehicleFlightStatus, whose parameters are one of two message types: VehicleFlightStatusRequest and WCARequest. The VehicleFlightStatusResponses interface also has four operations, which, between them use the message types: SystemStatusAlert and VehicleStatus.

The logical sequence of interface operations is defined by a service protocol. The same message type may be used in different service interface operations and by different services. In a SOA, the message types are specified by an Information Model.

Information Model

There are two purposes of the UCS information model. The first is to provide a catalog of the message types that may be exchanged by UCS services; the second is to define a common data model that is the basis for message type development and to make explicit the semantic relationship between one UCS message type and another.

At the center of the data model is an Entity-Relationship Model (ERM), which provides a common understanding of entities (identifiable and durable things in the real, operational world) and their states. Because the ERM is concerned with the states of entities in the real, operational world (for example, unmanned vehicles, missions, operational environment) it is agnostic to the interfaces and messages of a given software architecture. This makes it:

• extraordinarily reusable across DoD systems
• useful in integrating diverse architectures that interact with those same entities.

In the context of the common data model, a message type is a ‘view’ that is defined through the process of projection. At run-time, a message instance is a view (an information fragment) of the global state.

Because the concepts behind information modeling are abstract, we will focus on this example to illustrate the broader principles. The UCS information model adheres to the abstractions identified in the DoDAF Data/Information Viewpoint (DIV), i.e.

• DIV-1: Conceptual Data Model (CDM)
• DIV-2: Logical Data Model (LDM)
• DIV-3: Physical Data Model (PDM) – defined by users downstream.

In contrast to DoDAF, the UCS Architecture is more specific about the different roles of the CDM and LDM, and how message types are defined.  The basic organization of the UCS information model is shown below.

The CDM is an ERM for the Air Domain of the Unmanned Systems (UxS) Control Segment. Additional maritime and ground domains are being added for Revision A of the SAE standard. The ERM organizes entities according to objectives, domain resources (taskable entities), their missions, external resources (situational data), and their products (required data generated from a mission). This ontology is sometimes called the Objective-Mission-Resource (OMR) ontology.

The UCS ontology is useful for unmanned systems and is the core of the UCS Architecture. The CDM is supported by a common package that defines the attribute types that may be used in specifying the attributes owned by entities in the ERM. The LDM specifies logical message types that are created by a three-step process:

1. Service Message Type. For each message type identified in the service model, the data content is defined as a list of message attributes. At this point, the available attribute types are provided in the CDM common package. In this regard, message types are ‘conceptual’.
2. Projections. Each message attribute in the Message Model is equated to an owned attribute in the ERM. This process is called projection. The attribute name can be different at each end of the projection, but the attribute type must be the same (or components within the type must be the same).
3. CDM Refinement. For each owned attribute in the ERM, the conceptual attribute type is substituted for a valid logical attribute type in the Logical Shared Model package.

This process is summarized (and simplified) below for the message type called VehicleStatus, focusing on just one message attribute named airVehicleAcceleration. Here, the message attribute is equated with an owned attribute of an entity in the ERM named AirVehicle. This is the projection step. The refinement step is to substitute the ERM attribute type named Acceleration with the logical attribute type named Acceleration_NED_Tuple. In the ICD model, the result of these steps is summarized as a logical message specification. The structure of this data model ensures that the model is neat and compact, and the same engineering decisions are not repeated.