SLC Functional Description Document Format

The purpose of this document is to specify the functionality of the existing SLC/PEP-II control software subsystem and applications. Not to be included here are any design related or implementation discussions. Also, in order to distinguish SLC features from NLC requirements, any discussion of anticipated NLC software should be limited to the last section of the document.

  1. SCP User Interface
  2. This document is a functional description of the existing SCP User Interface (SCPUI) for the SLC Control System (SLCCS).
     

  3. Purpose
  4.  A. What is the application for and why is it necessary?

    To provide all users of the Control System with a consistent interface for interacting with all of it's diverse functions.

    B. Who uses it?

    Almost everybody. The main users are Operators who control almost all aspects of the accelerator. Machine Physicists use it to take and analyze data to understand various aspects of the machine. Programmers use it to test their S/W and also to take machine data relevant to the functions that they are implementing or debugging.

    Button Macros, which automatically run a sequence of operations by emulating button pushes and data entry are the main S/W user of the SCP touch panels. They are a key component and one of the most used aspects of the entire SCP user interface.
     

  5. Operating Environment
  6. All that is required to run a SCP is an X-Windows capable computer and an account on the MCC VMS machine.  In principle a SCP could be run from anywhere in the world. However, because there is presently no built-in security, it is only allowed to run inside of the SLAC domain.
     

  7.  Functional Requirements

  8.  
    Figures 1-4 show the four SCP windows which are part of the user interface. Figure 1 is the Touch Panel window, through which the user controls all of the SCP functions.  The types of functions asociated with buttons are ennumerated below.

    scptp.gif (12608 bytes)

    Figure 1 SCP Touch Window
     
    Figure 2 is the graphics window which is used to display graphics or text output depending on the function selected via the buttons.
     
     
       
        Figure 2 SCP Graphics Window
         
    Figure 3 is the error message window which displays global or local function messages.
         
        Figure 3 SCP Error Message Window
         
    Figure 4 is the knobs window which gives any user the capabiliy to "knob" one or more devices.
         
        Figure 4 Knobs  Window
         
    The following is a detailed list of functional requirements for the SCP interface:
       
    1. The SCPUI allows for unlimited menus of functions. Any button in a matrix can call up another panel. There are presently 3348 panels in the panel reference directory.
    2. Panel descriptions are simple ASCII files with fixed fields that can be edited with any text editor. There is no specialized panel editor that understands the syntax of a panel file.
    3. Code to be invoked when the button is pressed is dynamically determined at runtime.
    4. Action on one button can alter the state of other buttons on a panel.
    5. Some buttons on a panel can be dynamically defined at run time.
    6. An ancillary window for graphical or list output is always available.
    7. Global and local error messages sent in response to user actions are always available in another window.
    8. Hardware knobs are associated with the primary control panels in the Main Control Room.
    9. A software knobs window is available for use anywhere the is a SCPUI.
    10. A Button Macro facility is available for the recording and playback of a sequence of button pushes and data entry. A program file is produced which can be edited to alter the function of the macro.
    11. A library of these macros is maintained and available for display and selection for execution.
    12. Maintain a separate environment for the development and debugging of new panels and their code.
    13. The are a set of Continuously Updating Displays (CUDs) which provide an overview of the current accelerator status.

    14.  
  9. Performance Requirements
    1.  
    2. Speed. Any human interface must quickly provide an initial response. Normal human tolerance is about 2 seconds. For Control Room operators this reduces to about 0.5 seconds. Changing panels with the current SCP interface has a normal response time of well under 1 second.
    3. Functions provide some feedback that they are active.
     
  10. Resource Dependencies
    1.  
    Rapid panel response depends on several resources:
       
    1. Ethernet Network communication speed is the main determinant. I notice a big difference at 28.8K!
    2. Many functions are limited by SLCnet bandwidth or can saturate the network resulting in total system performance impacts.
    3. Local computer memory is fairly important. You want sufficient memory for buffers again to minimize network traffic.
    4. Local CPU speed is less important but you probably don't want an 8086!
    5. Performance on certain heavily loaded Feedback micros is sometimes a problem with user response times.
     
  11. Hindsight & Foresight [optional]
    Despite its apparent primitiveness from the contemporary viewpoint, this interface which combined a rapidly navigable set of panels with separate graphical and error message windows has proved surprisingly effective and durable. We certainly need to reproduce some parts of it for the NLC User Interface (NLCUI).

    To make up for its graphical shortfalls and the lack of a monitor capability, the SLCCS uses CUD displays which poll and process related sets of data. The monitor capability combined with the power of the EPICS database essentially turns the CUDs into simple DM displays.

    For the NLC we need to capture the local and global error message capability present with the SCPUI.

    Since we'll have a large number of displays, we also need a quick search facility so that one can quickly find the display(s) needed to perform the desired function. Traversing a tree of panels to find the button you're looking for can be painful. It will be more painful if each panel is a complex display that takes longer to paint than a panel though hopefully not much longer.

    The button macro equivalent functionality is absolutely essential and must be built into the NLCUI.

    So here's a starter list of NLCUI requirements that are an outgrowth of the SLCUI.

    1. Present global and local error messages in a standard way.
    2. Implement the equivalent to the button macro facility.
    3. Each production display should have an entry in a searchable database so that it's functions can be easily found by keyword.
    4. Implement the bookmark facility common to Web browsers.
    5. Provide a separate graphical window for certain plotting functions?