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. Title/Name
  2. This is the name or title of the piece of software by which it will be referred to in this and other documents

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

    Examples of possible categories:
    measure beam parameters
    modify beam parameters
    measure hardware performance
    archive data (what kind?)
    retrieve/display data (what kind?)
    synchronization services

    B. Who uses it?

    Directly or indirectly:

    People: machine physicists, operators, hardware developers, hardware maintenance people, software developers, etc.
    Other applications: (specify)

  5. Operating Environment
  6. A. Where does it run? Is this an on-line or off-line application?

    B. What services or other applications does it depend on?

  7. Functional Requirements
  8. State in general terms the functions the application performs. All the information in this and the following sections is a combination of text, equations, tables, etc. These sections do not contain any references to program logic.

  9. Performance Requirements
  10. Specify system requirements for throughput, timing constraints, data-flow rates, etc. If relevant, also address performance requirements pertaining to the user interface such as responsiveness.

  11. Resource Dependencies
  12. DATA
    Identify the data types this project deals with: sources and types of inputs, destination and types of output. Define the units of measurement, accuracy and precision requirements, if applicable. In particular specify if the application uses pulse-by-pulse or "batch" data, low or high latency, continuous or "bursty", and a measure of data volume.

    CPU

    Is the application CPU intensive? What kind of processing does it require, desktop, field micro, etc.

    Access to Accelerator Hardware
    Is the access to the accelerator direct or indirect? Does it control machine devices or just reads back? How much, how often?

    Access to Processed Data
    From what sources or applications does this software obtain data? Don’t refer to implementation-dependent sources such as "EPICS Channel Access" or "SLC Message Service". Refer to generic sources rather than making assumptions about the implementation or choice of services at this point.

  13. Hindsight & Foresight [optional]

Functionally speaking, what features of this system were less than satisfying from the perspective of performance, user interface, functionality, etc. Again, the concern here is system functionality and not how it was implemented.

This is also the place to discuss any NLC requirements that you are aware of or functions that do not exist that are on someone’s wish list or might become desirable in the new machine based on its unique features. New facilities that would seem useful or that you have thought about over the years are relevant.