[Top] | [Previous] | [Next]

C-7.2 Commanding Software Architecture

The Commanding Contact software architecture was determined based on commanding requirements as well as assumptions concerning technology projections and limitations. A high level notional view of thethe software architecture is depicted in Figure C-10.

Figure C-10. Commanding contact software architecture.

This architecture is based on the assumption of a distributed (client/server or object-oriented) architecture and a distribution service (middleware) layer. In such architectures, components communicate by passing messages across distribution services. Figure C-10 shows the Commanding application components (Transmit, Check Constraints, Execute Plan, Verify, and Display) across the top. It shows system service components (OS, DSS, DBMS, File, Security, etc.) along the bottom. Each component is connected to the distribution services layer by an API. The API defines the set of messages each component can send and receive, and actions associated with them. As a simple example, consider the situation of a command verification being sent to the SV operator. The component Verify would generate a message that would be output from its API and addressed to the HCI application. The HCI application would receive the message from its API and ultimately display the message on the screen to the operator.

Ideally, each Commanding functional component depicted in Figure C-10 would be vendor-independent and easily substituted. However, in practice certain components are commonly grouped together into higher level modules. Figure C-11 illustrates a common grouping seen in several commanding COTS products.

Figure C-11. Commanding contact software architecture implementation.

The Execute Plan, Verify, Check Constraints, and Display functions are grouped to provide a "Commanding Engine". This component would typically reside on a server or workstation. Real-world examples of this component would include SCL by ISI, and Intelligent Mission Toolkit (IMT) by Storm Integration. The Transmit component would typically stand alone, and would serve as the interface to the CFE. A real-world example here would be the software interface for the Loral System 500 Command and Control Module.