Online Design Goals

Overview

Below I list the overall specifications, performance requirements, and design goals of the Hall D Trigger/DAQ/Monitoring/Control effort, as well as addtional Electronics design goals. All groups working on the project, e.g. JLab DAQ group, JLab Electronics group, etc, must design to meet them. A complete set of experiment design goals has been compiled by Elton in GlueX-doc-866 in the DocDB.

I will specify and plan the entire project in three documents:

• Online Design Goals (this document)
• Online Major Milestones
• Online Work Breakdown, eventually to be entered into P3E or equivalent

The first sets the overall parameters of the project. The second adds the time element to the first and specifies major deliverables without going into great detail. The third is a fine breakdown that goes into details and includes assignment of responsitilities, timelines, dependencies, etc.

Other JLab groups will develop similar documents, then they will be reconciled and additional performance milestones, etc. will be developed.

Basic Requirements from Hall D Design Report

Important: High luminosity capability is NOT a CD-4 deliverable, and will only be achieved if additional funds can be procured. Thus at CD-4 all systems need only be capable of upgrade to high luminosity. An example of this is the monitoring farm, which at turn-on will process but not not reject events, and which needs to be expandable to implement the full L3 trigger.

The Hall D Trigger/DAQ system will be composed of:

• trigger system
• approximately 70 front-end crates
• timing distribution system
• a dozen or so asynchronous data sources
• a few dozen additional software components that do not generate high-speed data, but need to be integrated into the run control system
• all the associated computers and software needed to:
  • configure the system
  • take data
  • build events
  • store events on local disk
  • transfer event files to permanent storage.

At turn-on Hall D will accept 10**7 photons/sec, with an expected L1 trigger rate of 15 kHz (latest results from Alex Somov's MC studies, May-2008). At high luminosity the beam rate will be ten times higher, or 10**8 photons/sec, giving an expected trigger rate of 150 kHz assuming the same L1 rejection rate. With an average event size of 15 kByte the data rate off the detector at low luminosity will be 225 MByte/sec, and 2250 MByte/sec at high luminosity. At low luminosity there will be no L3 rejection, and all events will be written to disk (at 225 MByte/sec). At high luminosity we expect a L3 rejection rate of a factor of 10, so the rate to disk will also be 225 MByte/sec.

Notes: All front-end DAQ boards will be pipelined to handle the high trigger rate without deadtime. Triggers and backplane interrupts must be distributed to all front-end crates. Timing distribution must be appropriate for F1TDC's, 250 MHz FADC's, 125 MHz FADC's. and perhaps a few other miscellaneous modules.

The monitoring and controls effort consists of developing, configuring, controlling, and/or monitoring the following:

• approximately 70 front-end crates and associated detector electronics
• a few dozen compute servers, file server, raid system, and associated computer equipment
• monitoring farm consisting of about a dozen nodes (upgradable to up to 200 nodes for full L3 farm)
• a GBit wired and wireless networking system (eventually we'll need a 10 GBit system)
• about siz hundred detector hardware control points
• about 30,000 electronics control points (hv, lv, current trips, etc)
• at least one PLC, controlling the solenoid magnet and other devices
• many thousands of alarm channels
• interface to JLab accelerator controls system
• event display
• data quality monitoring system
• archive system for monitoring and controls data
• run bookkeeping system
• electronic operator log
• bug/error tracking system

Trigger/DAQ Design Goals

The initial design must satisfy the low-luminosity CD-4 deliverables, although systems should be capable of upgrade to high luminosity.

The DAQ design must include some headroom above the expected rates listed above. Thus I propose the following design goals and parameters for the Hall D DAQ system (numbers in parenthesis are for high luminosity):

• Accepted L1 trigger rate - 20 kHz (200 kHz)
• Average event size - 15 kByte (10 kByte)
• Data rate off detector - 300 MByte/sec (3 GByte/sec)
• Rate to monitoring farm - 300 MByte/sec (3 GByte/sec to L3 farm)
• L3 rejection - no rejection (factor of 10)
• Rate to local raid disk - 300 MByte/sec (300 MByte/sec)
• Rate to silo - 300 MByte/sec (300 MByte/sec)

also:

• Timing system able to synchronize front-end modules to better than 2 psec
• Energy-sum trigger system support multiple (>10) simultaneous trigger algorithms
• Overall trigger support multiple (>31) trigger types
• Overall trigger system programmable via VME
• Ability to stop/restart front-end tasks/programs without having to reboot
• L3/monitoring algorithm implemented via modifed version of offline reconstruction package
• All architectures designed to be expandable for high luminosity running

Although not a requirement or design goal, a feature useful during installation and testing would be the ability to support multiple, simultaneous runs to allow detector groups to check out their hardware in parallel.

Monitoring/Controls Design Goals

Some of the goals below refer to the environment seen by operators. Expert systems need not follow them, but should if possible.

• High-level experiment controls implemented via single operator interface
• Uniform look-and-feel to all monitoring gui's
• Uniform look-and-feel to all control gui's
• Alarms unified under a single alarm system
• Unified timeline system
• Unified help system
• Ability to search elog for previous solutions to current problems
• Facility in elog for notifying experts of non-critical problems and getting feedback/resolution
• Controls system must be compatible with EPICS, which will be used by the accelerator
• Controls system must accomodate a PLC, used to control the solenoid magnet and other systems
• All control loops implemented in PLC or in manufacturer-supplied devices
• Access and security architecture must allow off-site read-only viewing of online and controls data
• All architectures designed to be expandable for high luminosity running

Note...it would be useful to be able to grant control of particular devices to off-site personnel, as long as proper security is maintained.

Electronics Design Goals (need input from Fernando...)

• All crates and modules provide remote monitoring and reset
• Remote module programming ability provided when possible
• Remote monitoring ability via auxiliary connection (Ethernet, RS232, I2C, etc) provided when possible
• Minimize number of protocols needed to program and monitor hardware