September, 1999

J. Bogart

NLC Controls Requirements: Detector Interface

Detector Interface for a Pulsed Accelerator

(This document only describes facilities implemented for SLC/SLD or envisioned for NLC, but PepII/Babar facilities involve no new qualitatively different functionalities or requirements.)

The purpose of the detector interface is to provide the timely two-way transport of information between accelerator control system and detector control/data acquisition. For SLC/SLD several kinds of information were transported for a variety of purposes, including

• timing. Detector acquisition must be synched to accelerator beam pulse.
• interlocks (maintenance of compatible accelerator/detector states)
• online monitoring of beam, backgrounds, detector state
• offline analysis

The intercommunication between accelerator and detector occurs on multiple levels and time scales.

• Some data had to flow (in both directions) at 120 hertz, hence involved SLC micros and SLD acquisition modules
• Some data transfer took place on a time scale of order a minute between SLC Control System (central alpha) and SLD Online (central VAX).
• Typically an SLC scp would be running in the SLD Data Assembly Room and a couple SLD scps would be running at MCC.
• Data logged by SLD acquisition or history buffered by SLC Control System was analyzed offline

This is a high-level application (perhaps better described as a family of applications) which depends on many of the more basic facilities within the control system (database, display technology, history buffers, etc.) and, as implemented for SLC/SLD, even on large parts of the detector control system and data acquisition.

"Functional requirements" is maybe a misnomer. The list below is really an enumeration of the functions we had.

1. Provide interlocks so that detector cannot become vulnerable while accelerator is tuning and accelerator cannot begin to tune while detector is in vulnerable state.

2. Provide online noise information from detector at approximately 120 hertz (precise timing is unimportant) for machine tuning.

3. Provide accelerator timing to detector.

4. Provide beam-related information (e.g. currents) to detector acquisition at 120 hertz. Must be possible to correlate this information with detector event data by pulse.

5. Provide relevant correlated 120 hertz statistics for online monitoring (e.g. energy spectrometer average values and widths for "good" pulses, detector trigger rates, etc.). Displays should support flexible selection of cuts and of types of data to be correlated.

6. Provide for sharing of slowing-changing or occasionally-measured quantities (magnetic field strengths, beam scan results, polarization, etc.)

7. Provide logged quantities for offline analysis requiring correlation of accelerator and detector behavior.

The performance requirements vary with the different sub-applications. Only those involving real-time or near-real time response are listed here since any others are relatively modest. These "requirements" should maybe be taken with a grain of salt; they're what was required in order to implement the functionality we had, but not necessarily the functionality we could have used.

1. Detector requires a sufficiently accurate (order 10 nanoseconds for SLD drift chamber) timing signal from accelerator in order to synch acquisition start.

2. A relatively small and fixed amount of data (currents, bsm, etc.) had to be transferred at 120 hertz from SLC to SLD. It was a requirement to be able to associate this data with the proper pulse at the SLD end.

3. A similar amount -- order 10 numbers -- of per pulse information had to be transmitted from SLD to SLC. Here it was not necessary that the data be associated with the proper pulse or that it even be present every pulse.

1. Reliable path for permissive/veto signals used by interlocks

2. SLD access to SLC timing system.

3. SLD access to data from certain SLC devices at 120 hertz.

4. SLC access to SLD noise data

5. Modest network bandwith (between MCC alpha, SLD online cluster) for occasional database transfers.

6. Modest load on SLC micros, SLD "micros," on SLD online VAX and on MCC VAX.

From the Mark II run onwards, detector/accelerator intercommunication played an increasingly important role in improving the performance of the accelerator; it will be crucial for NLC. This is especially clear in the interaction region: both the accelerator and the detector are consumers of data issuing from there, whichever one formally owns the device producing the data. (Is an instrumented mask part of the accelerator or the detector?)

It should be clear that there never was such a thing as a "Detector Interface Facility;" instead there was a patchwork of hardware and software, some on the SLC side and some coming from SLD, some pre-existing and some specially built to meet needs as they were perceived. In fact the requirements on the detector interface are diverse and cannot be addressed by a single facility, but, in the design of a new control system, neither should they be met (or, rather, molded and then met) by making do with whatever pre-existing resources are at hand.

Since the detector interface is a broad, upper-level application, a good design will depend heavily on the availability of more fundamental utilities, resources and protocols. These include:

1. Distribution of timing information from accelerator to detector.

2. Something to support interlocks.

3. A robust protocol amenable to bandwidth upgrades for 120 hertz information to flow in both directions. For SLC/SLD the amount of such data was small. More probably would have been useful, but the communication between SLC camac and SLD Fastbus was so painful that we couldn't afford to consider it seriously. 120 hertz information flowing to SLD was incorporated into the log stream and used for monitoring; information flowing to SLC was available in history buffers and as scope traces for tuning. For NLC it seems likely that such information will be used much more actively (e.g., as input to feedback loops or as a veto) on both sides.

4. Support for transfer of data at the seconds-to-minutes time scale. For SLC/SLD the amount of data transferred was modest and put no noticeable strain anywhere. Undoubtedly more data will be transferred for NLC, but should not be difficult to accomodate. As in 2., it is likely that for NLC some of this data will be used as input to control rather than just for monitoring or bookkeeping.

5. Universal tagging of per-pulse or per-bunch data. This implies that a tag or pulse id must be reliably available to any component producing data at 120 hertz. It will allow correlation of information from any source. For SLC/SLD, this included at least the accelerator control system, detector acquisition, compton polarimeter and the WISRD (energy spectrometer). (Ideally the polarimeter and WISRD would have been more tightly integrated with one or the other of the major players, but that's another topic.)

6. Extensive and extensible logging of per-pulse data (not sparsified!) by both accelerator and detector. Combined with 3., this is an extremely powerful debugging and analysis tool.

7. Tools for statistical analysis, correlation and display of data.