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. Cater

This describes the functional requirements for the Computer Assisted Trouble Entry & Reporting program known as CATER. It is a program and associated database which tracks all Hardware and Software problems in the accelerator. It maintains a history of all problems since ~1980, now over 50,000.
 

2. Purpose

 

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

Because a large accelerator has so many hardware and software parts, some type of automated assistance is necessary for maintenance and fault history analysis.

B. Who uses it?

Just about everyone involved with accelerator operations. While anyone can report a problem, operators and machine physicists are the originators of most of the trouble reports. Hardware and software maintenance personnel solve the problems. Other operations personnel track maintenance history, looking for recurring problems. Management decides when things are really fixed and close out open problems.
 

3. Operating Environment

CATER is an offline application that runs on any VMS machine. Thus anyone with a VMS account can use it. It uses the VMS Rdb database for storing all problem and solution information and a VMS specific screen management package for the user interface.
 

4. Functional Requirements

I guess we'll start with the basic functions and then go to the user interface. The CATER database consists primarily of problem reports and their associated solutions.
 

1. Any valid user can enter or modify a problem report.
2. Any valid user can enter or modify a problem solution.
3. Any valid user can browse the database.
4. Only authorized managers can close out problems.
5. Problem reports and their associated solutions are in 2 formats; one for hardware and one for software.
6. The userid and time stamp of who entered the initial problem or solution are kept in the database.
7. The userid and timestamp of the last problem modification are kept in the database.
8. Each problem entered is given a unique id or number.
9. When hardware problems are initially reported they are automatically sent to the printer of the appropriate shop(s).
10. When software problems are reported they are automatically emailed to the appropriate managers.
11. Separate fields are available on the Modify forms for maintenance personnel to enter problem codes for statistical tracking of problem types. These fields are not visible on the Entry forms.
12. An automatic report runs every morning summarizing the new problems of the last 24 hours.
13. CATER can be initiated from a SCP with a single function key.

Now lets get down to the specifics of the user interface.
 

1. Each field is validated as it is entered.
2. Defaults are filled in wherever possible.
3. Some fields require cross-field validation.
4. Informational messages are presented when database updates, queries or other lengthy (>0.5 sec.) operations are performed.
5. Help is available with a single keystroke at any field.
6. When browsing, a long and short form report are provided.
1. The short form shows important fields on a single line
2. The long form shows all information about the problem(s) selected.
7. Any database field can be used for selection criteria when browsing.
8. Browsing queries are constructed dynamically depending on the fields entered. There is an implicit AND among all of the fields selected.
9. Reports can be displayed on the screen, sent to a file or printed.
10. There are a set of canned reports which can be printed just by entering the report number and specifying the printer.
 
5. Performance Requirements

Operators and machine physicists have zero tolerance for delays. Calling up menus and basic data entry and validation should be as close to instantaneous as possible. Data entry errors are fed back immediately to the user; no database transaction is required.

Since we allow the user to query on any set of fields, retrieval time for some queries is a problem. The indexes should be set up to minimize response time for the most frequent queries.

The user should not have to wait unnecessarily for anything. For this reason, requested canned reports are spawned off immediately as a batch job so the query and formatting of the report is done independently of the user's session.
 

6. Resource Dependencies

The main resource used is the database which holds all of the accumulated problems and their solutions.

The number of simultaneous CATER processes was also a problem at one point since many people would leave their process up indefinitely.
 

7. Hindsight & Foresight [optional]

There we're several major 20-20 hindsight issues, which we wish we had done differently.
 

1. Valid Primary Micro Unit (PMU) in all appropriate hardware problems. The initial difficulty was that the SLC database was only available on MCC and we did not want to limit the execution of CATER only to the MCC node. We could have extracted the valid PMU information into the Rdb database and validated it that way but we didn't. This was a major operational problem in identifying the exact device in question and in having many duplicate problem reports for the same device.
2. VMS seemed like it would be around forever but alas, it's now a tiny bit of the computing industry. Like the rest of the SCP, CATER is closely coupled to the VMS screen management package and the DEC (now Oracle) Rdb database. This made it impractical to port it to another system. Of course, who would have guessed in 1980 that a thing called a Web browser would become a universal client?
3. The canned reports were all "hand-made" and there was no facility for users to create their own customized reports.
4. Since the menus were all hand-built and each driven by a unique set of code, adding a new field involved changes in several places making maintenance difficult and error prone.

For the NLC we would want the CATER function to be much more tightly integrated with the rest of the NLC database. There's probably a whole list here that needs to be filled in.