by Sidik Isani
2001 May 24th
Last revised: 2001 June 25th
|Tip: For printing, download the PostScript version of this document.|
Science and engineering computer control interfaces have unique requirements. A visually appealing interface is good; a simple one is cruicial. Integration is also good, but not if traded for modularity or adaptability. Since science requirements are constantly changing, control systems must be able to keep up and be changed easily. When there are distinct hardware subsystems, it is a natural approach to develop separate engineering control interfaces for each, typically menu or command driven. If these programs are written as command line interfaces (CLIs), and follow a few guidelines set forth in this document, then they can be re-used completely as part of the final interface. (We refer to a conforming command line utility as an ``Agent''.) This can be a great savings in development costs.
With this model, knowledge of the system as a whole exists only in high level scripts which tie everything together. There is no mechanism (provided by Director, at least) allowing Agents to communicate with each other. The ``Director'' program functions as a command ``shell'', sending commands to the appropriate agent, and returning completion results (only a simple PASS or FAIL is supported) to the initiator (e.g., the script). The initiator can also be a graphical user interface, which is otherwise isolated from the control modules. Scripts can also be nested, and a graphical interface can call the high level scripts, the low level Agent commands or both. (In fact, it doesn't really know which commands are implement as scripts. It only has to pass the command line to Director.) Any interface which is capable of generating commands when buttons and menus are manipulated can be layered on top of Director. The RPM Web server (http://software.cfht.hawaii.edu/RPM/) is an example. This document focuses on creating the command-line level of the user interface.
2001 June 4 - Document released.
2001 May 24 - Adapted from Director Version 2 documentation. Added information to reflect multi-agent and other new capabilities of Director 3.x. See the old document for some more history on Director and how it compares with CFHT's ``Handler and Server'' model in the Pegasus environment.