Reference design and implementation for asynchronous (long-running) commands

The SKA Telescopes are large, distributed systems, the telescope Control System has a hierarchical structure which enables operations to configure, control and monitor each telescope as a single system. The commands are propagated from the top-level user interface to the lowest level software components which interface with hardware and COTS components. Commands that co-ordinate telescope state transitions and execution of observations  are propagate through several levels of abstraction, and often require  co-ordination of state transitions and configuration of hundreds, if not thousands of components.  Such commands must be implemented as non-blocking commands; the client which initiates a command should not be blocked during the command execution.  The control should be returned to the caller within few milliseconds.  The progress of the execution of the command is tracked by additional attributes, and the completion of the command reported as a state transition (event).

Additional attributes should be implemented to track and report:

• target/desired operational state,
• command being executed,
• progress (either as a percent complete or set of stages).

With exception of the Abort() command which allows a Client to interrupt and stop execution of other commands, the commands are executed one at a time (an analysis will be performed and any exceptions indicated and properly handled).  

Note: A Client will have to wait for the execution of the current command to end in order to issue the next command; this will require the Client to monitor command execution and the device status, and in general makes a Client implementation more complex.  To address this issue, consider implementing the input command queue:

1) when a command is received, it is added to the end of the queue and control immediately returned to the caller. (Before adding a command to the queue, the device may check that the parameters are within range, if that is a simple operation).

2) When not executing a command, the command execution thread periodically checks the queue, and if the queue contains a command, removes the command from the beginning of the queue and begins execution (status attributes are set to indicate this).

2) Abort() command must be immediately executed. Abort() interrupts execution of other commands.

3) If implemented as commands, queries (perhaps not all) may be executed in parallel with commands that trigger state transitions.

Detailed design is in progress.

Useful information on Slack (with links back to Confluence).