Command Management

The Command Management capability is a new capability in TReK Release 3. This capability will provide a way to manage a multi-platform command environment that can include geographically distributed computers. This is intended to help those teams that need to manage a shared on-board resource such as a facility class payload. The environment can be configured such that one individual can manage all the command activities associated with that resource/payload.

The Command Management capability is "off" by default. The commanding features in Release 3 work just as they did in Release 2. So if you aren't interested in using this capability its existence won't cause you any extra work.

Example Configuration/Scenario

The figure below shows an example configuration. In this configuration, one TReK system is configured as a command node and the other two TReK systems are configured as command subnodes.

About the TReK Command Node

• The Command Node (while called a command node) can perform all TReK functions. We just label it as a command node here to clarify its role in this example.
• The Command Node is serving as the primary interface to the final destination (which could be the POIC, a Suitcase Simulator, or a PRCU, etc.).
• The Command Node can be configured to accept connections from other TReK systems located in different geographic locations.
• The Command Node can be configured in one of three different security configurations which each support different levels of security checks.
• When a destination is created on the Command Node it can be configured to be accessible by one or more remote TReK systems. By accessible we mean that the remote TReK systems (subnodes) can "attach" to the destination and send command function requests to the destination.
• When configuring a destination on a Command Node, the destination can be configured to perform user provided command validation checking. When this option is enabled, TReK provides a mechanism that allows user-provided software to check the contents of a command before the Command Node forwards the command to its final command destination (POIC, etc.).
• When a Command Node receives a command uplink request from a subnode, the command node will perform all the checks associated with that request and then if all checks are successful will send the command to its final destination (POIC, etc.). Any command responses that are returned from the final destination are passed back to the subnode that sent the command uplink request.
• A Command Node can enable/disable subnodes.
• A Command Node can track/record all command activity performed by the command node on behalf of the subnodes connected to the command node.
  

About the TReK Subnodes

• The TReK Subnodes (while called subnodes) can perform all TReK functions. We just label it as a subnode here to clarify its role in this example.
• A Subnode can create a TReK Destination that is used to connect to a TReK system.
• When a Subnode connects to a Command Node, the Subnode will receive a list of destinations that it is allowed to "attach" to.
• A Subnode can make several different types of command requests to a command node including: Uplink User Command Request, Uplink POIC Command Request, Uplink TReK Command Request, Update POIC Database Request, Update Command Node Database Request.
• A Subnode can display status/configuration information about its connection to a command node.
• A Subnode can receive and display command response information from the command node.
  

Scenario

The following scenario does assume some familiarity with the TReK Release 2 software.

1. The user on the TReK Command Node configures the TReK software to accept remote connections from TReK Subnode A and TReK Subnode B.

2. The user on the Command Node adds a POIC Destination (just as it normally would) and sets the destination's management properties to allow Subnode A and Subnode B to use this destination.

3. The user on the Command Node activates the POIC Destination thereby establishing a command connection with the POIC.

4. The user on TReK Subnode A adds a TReK destination (this is a new type of destination). This TReK destination identifies the IP address and port number of the TReK Command Node. The user activates the TReK Destination. During activation the user is prompted for a username, a password, and is shown a list of possible destinations that are available via the TReK Command Node. The only destinations that will show up in this list are those that the Command Node has allowed Subnode A to use. The user enters the username and password and selects the POIC destination that was created by the TReK Command Node user. The TReK Command Node returns a list of the commands available for Subnode A to Subnode A.

5. The user on TReK Subnode B also adds a TReK destination and connects to the TReK Command Node. Subnode B also selects to use the POIC Destination created on the TReK Command Node.

6. The user on Subnode A sends a command (e.g. command 44) to the TReK Destination (i.e. the TReK Command Node).

7. The Command Node receives command 44 and returns a TReK Receipt Response to Subnode A. The Command Node then forwards the command to the POIC. The Command Node sends the command responses received from the POIC back to Subnode A.

8. The user on Subnode B sends a command (e.g. command 90) to the TReK Destination.

7. The Command Node receives command 90 and returns a TReK Receipt Response to Subnode B. The Command Node then forwards the command to the POIC. The TReK Command Node sends the command responses received from the POIC back to Subnode B.

Command Activity continues in this manner.

During this activity the Command Node User can enable/disable remote subnode connections and enable/disable individual commands.