![](media/image1.png){width="2.4583333333333335in" height="1.375in"}

**Readout and Control System Requirements**

**BTeV Document** (number to be assigned)

**14 November 2023**

**Authors**

***^1^Fermilab***

***P.O. Box 500***

***Batavia, IL 60510 USA***

***E-Mail: xxx***

***E-Mail: xxx***

***Phone: (630) 840-xxxx***

FAX: (630) 840-xxxx

1 Introduction [1](#introduction)

2 High Level Requirements [1](#high-level-requirements)

2.1 Input Rate Requirements [1](#input-rate-requirements)

2.2 Intermediate Rate Requirements [1](#intermediate-rate-requirements)

2.3 Output Rate Requirements [1](#output-rate-requirements)

2.4 Excess Capacity & Scalability [1](#excess-capacity-scalability)

3 Readout Electronics [2](#readout-electronics)

3.1 Generic [2](#generic)

3.2 Data Combiners [2](#data-combiners)

3.3 Optical Data Links [2](#data-links)

3.4 First Level Buffers [3](#first-level-buffers)

3.5 Event Builder [3](#event-builder)

3.6 Timing [3](#timing)

3.7 Gating and Control Distribution
[4](#gating-and-control-distribution)

3.8 Firmware [4](#firmware)

3.9 Electronics Standards [4](#electronics-standards)

3.10 Reliability [5](#reliability)

3.11 Test Features [5](#test-features)

3.12 Maintainability [5](#maintainability)

3.13 Module and Link Identification [5](#module-and-link-identification)

4 Controls and Software
[6](#controls-and-software-readout-control-and-monitor-software)

4.1 Generic [6](#generic-2)

4.2 Run Management [6](#run-management)

4.3 Buffer Manager [6](#b.3-buffer-manager)

4.4 Trigger Managers [7](#trigger-managers)

4.5 Detector Manager [7](#detector-manager)

4.6 Partitioning [7](#partitioning)

4.7 Data Storage [8](#trigger-managers)

4.8 Slow Control [9](#slow-control)

5 Infrastructure and Integration [9](#infrastructure-and-integration)

5.1 Control Network [9](#control-network)

5.2 Control Room [9](#control-room)

5.3 Databases [9](#databases)

5.4 Test Stands [10](#test-stands)

5.5 Installation [10](#installation)

6 Safety and Computer Security [10](#safety-and-computer-security)

6.1 Safety [10](#safety)

6.2 Security [10](#__RefHeading___Toc508097696)

Dependency Appendices [12](#dependency-appendices)

A. Detector and Front-end Electronics Dependencies
[12](#a.-detector-and-front-end-electronics-dependencies)

A.1 Front-end to Data Combiner [12](#a.1-front-end-to-data-combiner)

A.2 Detector Data Rates [12](#a.2-detector-data-rates)

A.3 Detector Timing [12](#a.3-detector-timing)

A.4 Slow Control [12](#a.4-slow-control)

B. First Level Trigger Dependencies
[12](#b.-first-level-trigger-dependencies)

B.1 Trigger Latency [12](#b.1-trigger-latency)

B.2 Trigger Data Format [13](#b.2-trigger-data-format)

C. Second Level Trigger Dependencies
[13](#c.-second-level-trigger-dependencies)

C.1 Request Timing [13](#c.1-request-timing)

D. Facilities Dependencies [13](#d.-facilities-dependencies)

D.1 Installation [13](#d.1-installation)

# Introduction

This document describes the highest level requirements for the BTeV
Readout and Control System. The purpose of the BTeV Readout and Control
System is to transfer detector data to archival storage, interfacing
with the various triggering components as needed. This system also
includes the monitoring and controls of the detector itself. The
counting room infrastructure as well as the data (archival?) storage are
also covered by this document.

# High Level Requirements 

This section describes Readout and Control System requirements that are
necessary to achieve the goals of the BTeV experiment. Note that
\"event\" in this document refers to data from a single crossing,
regardless of the number of interactions in the crossing. It is assumed
throughout this document that data from a single interaction are
contained within one event.

## Input Rate Requirements

Most of the data produced by the detector is below predetermined
thresholds and is suppressed at the detector. Approximately 10^13^ bits
per second leave the detector and must be processed by the Readout
System. The Readout System may provide compression for data that has not
already been compressed at the detector. All data presented to the
Readout System Electronics is expected to be in digital form.

-   **Requirement 2.1-1 (Input data rate):** The BTeV Readout System
    must accept a data rate of at least 10^13^ bits per second.

-   **Requirement 2.1-2 (Event data):** Data from a single interaction
    must be contained in a single event, which is the data from a single
    crossing.

## Intermediate Rate Requirements

The combined acceptance of the first level trigger is expected to be
approximately 1% of all crossings. The data size of these accepted
events may be larger than the average for all events, and additional
data will be generated by the first level triggers.

-   **Requirement 2.2-1 (First level buffering):** The Readout System
    must buffer all data received from the detector for the period of
    the first level trigger decision.

-   **Requirement 2.2-2 (Second level data rate):** The Readout System
    must be capable of delivering a data rate of 2 X 10^11^ bits per
    second (2% of the data transmitted from the detector) to the second
    level of the trigger system.

## Output Rate Requirements

The combined acceptance of the second and third level trigger is
expected to be approximately .05% of all crossings. The Readout System
writes data from the third level trigger system to permanent storage.
Some of the output data may be summarized, resulting in a reduction in
event size of at least 50%.

-   **Requirement 2.3-1 (Output data rate):** The Readout System must be
    capable of delivering a data rate of 5 X 10^9^ bits per second from
    the third level trigger processors to the data storage system.

-   **Requirement 2.3-2 (Reverse datapath):** The Readout System must be
    capable of delivering data at a reasonable rate from the data
    storage system to the processors, allowing use of the processors for
    offline reconstruction when the detector is not operating.

## Excess Capacity & Scalability

Readout System bandwidth requirements are based on the sum of estimated
data rates for each of the subdetectors.

-   **Requirement 2.4-1 (Scalability):** The Readout System must permit
    an increase in capacity of at least a factor of two in data
    throughput at every level (starting with the data combiners since
    it's unlikely that the links to the front-end boards will scale in
    number or throughput.)

# Readout Electronics 

The hardware components of the BTeV data collection system are described
in this section. The first elements of the data acquisition system are
the Data Combiner boards. Front-end modules and on-detector electronics
are described in the sub-detector requirement documents.

As the architecture for the Data Acquisition system is defined in
parallel with the Level 1 trigger architecture, an implementation with
multiple, parallel DA subsystems is starting to converge. Each one
working on a complete event, and each one operating at 1/n the crossing
rate, where n is the number of parallel systems.

## Generic

The following requirements apply to all components of the Readout
Electronics.

-   **Requirement 3.1-1 (Control & status):** The Readout Electronics
    must respond to Run Control commands and must provide error and
    status information to the Error Handling/Recovery and Status
    Monitoring Systems.

-   **Requirement 3.1-2 (Fault tolerance):** The Readout Electronics
    must continue to operate in the presence of faults, such that only
    data from the failed component is affected. Error detection must be
    sufficient to automatically identify and isolate failed components.

-   **Requirement 3.1-3 (Synchronization):** At every stage of the
    readout chain a synchronization mechanism shall be provided that
    relates event fragments to crossing number.

## Data Combiners

The Readout System will provide a standard component (Data Combiner) for
receipt of digital data from front-end modules. The Data Combiner will
also distribute control, monitoring and timing information as well as
configuration constants such as sparsification constants to/from the
front-end modules.

-   **Requirement 3.2-1 (Number of front-end ports):** The Data Combiner
    must accept data from as many front-end boards as necessary to
    effectively utilize the bandwidth of the output data links.

-   **Requirement 3.2-2 (Processing & buffering):** The Data Combiner
    must be capable of performing data compression on any uncompressed
    data received, and must provide sufficient local buffering to smooth
    data rates on the output data links.

-   **(Back pressure see also L1 buffer)**

-   **Requirement 3.2-3 (Remote access):** The Data Combiner must be
    remotely resetable and reconfigurable under all conditions not
    involving hardware failure of the module.

-   **Requirement 3.2-4 (Timing distribution):** The Data Combiner must
    distribute control and synchronous timing signals, as necessary, to
    each front-end module. **Standard interface to front-end modules
    (serial link for data; separate line for timing? Use data link also
    for configuration/download?)**

## Data Links

Data is transmitted from the detector to the counting room on short
reach optical links. The Data Links are routed from the detector to the
counting room through conduits with a cross sectional area of
approximately 2000 square centimeters (this may place a limit on the
number of fibers that can be routed).

-   **Requirement 3.3-1 (Cable bandwidth):** Maximum link distance is
    approximately 70 meters. The cable must allow operation within the
    specified error rate over a distance of at least 100 meters at 2.5
    Gbps or higher.

-   **Requirement 3.3-2 (Error rate):** The maximum allowable bit error
    rate for an individual data link is 10^-15^. This corresponds to a
    system bit error rate of less than 30/hr for each stage of data
    transmission.

-   **Requirement 3.3-3 (Error detection and recovery):** The data link
    protocol must provide error detection and automatic
    resynchronization on packet boundaries.

-   **Requirement 3.3-4 (Synchronization):** Serial data links must be
    synchronized to local oscillators (not to the accelerator clock).

## First Level Buffers

The First Level Buffers receive data from the Data Combiners and various
stages of the First Level Trigger. The data is held until a trigger
decision is made, and then either discarded or forwarded to the Second
Level Trigger.

-   **Requirement 3.4-1 (Buffer size):** The First Level Buffers must be
    capable of holding data until a first level trigger decision is
    made. It is assumed that the decision time will be limited by a
    timeout in the first level trigger.

-   **Requirement 3.4-2 (Input data ordering & format):** The First
    Level Buffers must accept data that is not in crossing order, but
    may impose a requirement on sources that all data be **grouped** by
    crossing (i.e., data from crossing n may arrive either before OR
    after data from crossing m, but may not arrive both before AND
    after.) The First Level Buffers must extract framing information
    (crossing number and end-of-record) from received data packets for
    use in identifying and routing the data.

-   **Requirement 3.4-3 (Burst Mode):** On command, the First Level
    Buffers must stop accepting input data and must allow data already
    in memory to be output without being overwritten.

-   **Requirement 3.4-4 (Null data):** A First Level Buffer must be
    capable of generating a null data packet with the proper crossing
    identifiers when its data source is disabled or malfunctioning.

## Event Builder

For each event accepted by the first level trigger system, all necessary
data from all detector subsystems must be combined and delivered to
processors in the second level trigger system.

-   **Requirement 3.5-1 (Data rate):** The Event Builder must be capable
    of delivering a combined rate of 2 x 10^11^ bits per second to the
    second level trigger system.

-   **Requirement 3.5-2 (Data routing):** The Event Builder must be
    capable of routing data from any first level buffer to any second
    level trigger processor (if multiple readout paths are implemented,
    first level buffers in one path need not connect to second level
    processors in a different path, but there must be a way to transfer
    data at lower speed between second level processors in different
    paths).

-   **Requirement 3.5-3 (Data buffering):** The Event Builder must
    provide either 1) a buffer depth of at least N maximum length
    packets per port, where N is the number of ports, or 2) a packet
    bypass mechanism to prevent head-of-line blocking.

    **Data Storage here instead of 4.7?**

## Timing

The Timing system generates signals that are synchronous to the
accelerator clock. It is assumed that only the Data Combiners and
associated front-end electronics will require synchronous timing, and
that all other components of the Readout System and Trigger System
operate asynchronously. The clock signal will likely be 53 or 106 MHz.
Alignment of the 7.6 MHz (132 nsec) crossing clock will be provided by a
synchronous command signal.

-   **Requirement 3.6-1 (Synchronous clock):** The Timing System must
    provide a clock which is synchronized to the accelerator RF (53.104
    MHz), and must distribute this clock independently to all Data
    Combiners. The synchronous clock must have no more than xxx psec of
    jitter.

-   **Requirement 3.6-2 (Command synchronization):** The Timing system
    must deliver at least one synchronous signal for the purpose of
    aligning commands to specific clock edges. Commands may be delivered
    asynchronously or may be implied.

-   **Requirement 3.6-3 (Crossing synchronization):** See Appendix
    A.3-2.

## Gating and Control Distribution

Each subsystem has a local manager which communicates with Run Control
and directs the operation of components in that subsystem. The manager
consists of a standard processor and associated software, along with the
electronics necessary to distribute synchronous and asynchronous control
signals within the subsystem.

-   **Requirement 3.7-1 (Synchronous control distribution):** The
    control signal distribution electronics for the Detector Managers
    must drive independent synchronous links to each Data Combiner. The
    distribution electronics must provide global timing alignment for
    each detector and must add no more than xxx psec of jitter to any
    signal. The distribution point for Data Combiners must be outside
    the collision hall.

-   **Requirement 3.7-2 (Asynchronous control distribution):** The
    control signal distribution electronics for all managers must
    provide bidirectional links for asynchronous control and monitoring
    of each component in the subsystem. The distribution point for Data
    Combiners must be outside the collision hall.

## Firmware

Components of the Readout Electronics will include embedded software in
the form of FPGA firmware and microcontroller code. The embedded
software should comply with the standards defined in the *BTeV Software
Standards* document wherever possible. This code will be developed using
application specific tools including compilers, debuggers, and
diagnostics.

-   **Requirement 3.8-1 (Software repository):** All firmware (source
    and object code) must reside in a software repository that will be
    used to keep track of different versions of the firmware as it is
    being developed.

-   **Requirement 3.8-2 (Version control):** The version number of the
    firmware that is used to process data must be managed in such a way
    that the firmware version that was used to process data can always
    be identified.

-   **Requirement 3.8-3 (System Software error detection):** Processes
    to regularly verify code and run standard datasets must be included.

-   **Requirement 3.8-4 (Development tools archival):** The development
    software and operating environment necessary to recreate the last
    implemented version of firmware for each component must be archived.
    Any unique hardware platforms or keys used in the firmware
    development process must also be identified and tracked.

## Electronics Standards

The hardware that is designed and built, or purchased to implement the
readout system will consist of digital electronics. This hardware must
comply with the *BTeV Digital Electronics Standards* document. This
document contains requirements, standards, and recommendations that
apply to all digital electronics in BTeV. The subjects that are
addressed in the document include interfaces, grounding, EMI, shielding,
infrastructure, safety, reliability, and maintainability.

-   **Requirement 3.9-1 (Electronics standards):** The readout system
    must comply with the *BTeV Digital Electronics Standards* document.

## Reliability

-   **Requirement 3.10-1 (Burn-in):** The Readout System hardware must
    undergo a burn-in process to minimize infant mortality failures in
    the production system.

-   **Requirement 3.10-2 (Low-stress design):** Circuit board assembly
    techniques must be employed to minimize component stress that would
    adversely affect reliability.

-   **Requirement 3.10-3 (Fault tolerance):** A level of fault-tolerance
    and redundancy must be designed into the architecture so that a
    noticeable percentage of processing elements must fail before the
    normal operation of the system is significantly affected.

-   **Requirement 3.10-4 (Uptime):** The Readout System must be ready to
    run during 95% of beam time (no more than 5% dead time for
    initialization, startup, etc.)

## Test Features

The subsections below contain requirements pertaining to the testability
of the Readout System components.

-   **Requirement 3.11-1 (Self-test):** Components must include built-in
    test structures such that all internal functions of the module may
    be tested with minimal use of external test equipment.

-   **Requirement 3.11-2 (Interface test):** Components must include
    built-in pattern generation and checking such that the interfaces to
    upstream and downstream components may be tested with minimal use of
    external test equipment.

## Maintainability

-   **Requirement 3.12-1 (Maintenance):** Sufficient numbers of spares
    must be assembled to allow the Readout System to be maintained by
    module replacement.

-   **Requirement 3.12-2 (Modularity):** The size and complexity of
    individual circuit boards must be minimized, such that replacement
    of a board can be considered a viable option to repair.

-   **Requirement 3.12-3 (Programming):** All programmable components
    must be \"in-circuit\" reprogrammable. If there is no permanent data
    link to the component, the programming interface must be accessible
    without removing the component from the system.

## Module and Link Identification

All electronics modules and links require identification.

-   **Requirement 3.13-1 (Module identification):** Each electronics
    module must have a label containing a unique bar code and its
    alphanumeric equivalent. Any module with a control system connection
    must also be identifiable by a unique electronic tag, which may be a
    network address.

-   **Requirement 3.13-1 (Link identification):** Each data link must
    have a label containing a unique bar code and its alphanumeric
    equivalent, and must be labeled at both ends. All module and link
    information will be stored in a database.

# Controls and Software \[Readout, Control and Monitor Software\]

\[Higher level software is required for running and monitoring the
experiment. This includes run management software, detector monitoring
software, partitioning of the readout and controls resources as well as
the detector itself, and data storage. This services will be provided in
a distributed environment which needs to communicate with the other sub
system managers.\]

The software required to operate the BTeV detector can be classified in
three categories. The first category includes run management and flow
control software and support for the partitioning of the readout. Data
quality monitoring, configuration, alarms and user (counting room?)
displays (interfaces?) are part of the second category. Control system
software to monitor voltages, temperatures and similar applications are
covered by the last software category. In addition, services will be
provided to support such a large distributed environment.

## Generic

## Generic

-   **Requirement 4.1-1 (Standards):** All software that is designed, or
    purchased to implement the system control functions must comply with
    the *BTeV Software Standards* document.

-   **Requirement 4.1-2 (Datataking Efficiency):** Software
    infrastructure, in particular configuration and downloading of
    detector constants, shall not introduce more than 5% loss in data
    taking efficiency

## Run Management 

Run Management software is necessary for starting/stopping and
organizing all components for data taking.

-   **Requirement 4.2-1 (Hierarchy):** The Run Management software must
    provide a central facility for system start, stop and automatic
    error recovery.

-   **Requirement 4.2-2 (Performance monitoring):** The Run Management
    software must provide appropriate monitoring/diagnostic information
    on DA performance for shift personnel through data taking periods.

-   **Requirement 4.2-3 (Information Services):** The Run Management
    software must archive run conditions for viewing offline.

-   **Requirement 4.2-4 (Error recovery):** Run Management software must
    provide central facility to process various component failures and
    to provide automated mechanisms for recovery where possible.

-   **Requirement 4.2-5 (Configuration changes):** Run management
    software must provide interface to change and track changes to run
    parameters.

-   **Requirement 4.2-6 (Partitioning):** Run management software must
    support multiple, independent runs. **Requirement**

-   **Requirement 4.2-7 (Remote Access):** Remote monitoring and
    configuration must be supported during normal operating conditions.

-   **Requirement 4.2-8 (Multi-platform support):** User interfaces must
    operate across a variety of operating system platforms.

-   **Requirement 4.2-9 (Connectivity):** The Run Control Host must have
    access (through the control network) to all other subsystem
    managers/controllers in the system.

-   **Requirement 4.2-10 (Reliability): --** How to address single
    points of failure (run control host ...)

-   **Requirement 4.2.11 (Performance):** - Run starts during the
    commissioning phase must be tunable to have minimal overhead times.

## Partitioning

During commissioning phases of both the detector and components of the
L1 and L2/L3 processing farms, multiple runs will need to happen in
parallel using a different set of resources. Some resources, may
however, be shared (data switches, the global level 1 trigger, etc.).
Partitioning is the ability to provide concurrent, independent runs with
their own user defined trigger requirements and user defined resources.
Partitioning must support more than just hardware commissioning - one
may split trigger processing nodes into different partitions to test
different algorithms or OS versions, etc.

-   **Requirement 4.6-1 (Granularity):** Must be able to commission
    sub-detectors without relying on other sub-detectors to be
    operational.

-   

-   **Requirement 4.6-2** **(Heterogenous)** Must support ability to
    have different trigger algorithms in the same partition

-   **Requirement 4.6-3 (Maximum size):** A single partition must be
    able to support the entire BTeV detector (ie, normal running).

-   **Requirement 4.6.4 (Resource Ownership):** Resources must be only
    be reserved for write access by a maximum of one partition. The
    granularity of a resource should be the smallest unit that does not
    impact other resources. Not all of a resource needs to be functional
    for it to be included in a partition

-   **Requirement 4.6-5 (Shared resources):** Resources must be capable
    of being shared across partitions.

-   **Requirement 4.6-6 (Communication):** All affected partitions must
    be notified when shared resources are modified.

-   **Requirement 4.6-7 (Excess Resources):** Idle L3 processing nodes
    must be available for use outside the data acquisition system.

-   **Requirement 4.6-8** **(Routing)** Data from any crossing must be
    able to go to any partition (ie, a given partition can receive
    consecutive crossings).

-   **Requirement 4.6-9** **()** Data from a particular beam crossing
    must go to all partitions that satisfy its trigger requirements.

-   **Requirement 4.6-10** **()** A given partition will receive a
    specific beam crossing no more than once.

-   **Requirement 4.6-11** **(Excess Capacity)** Idle L3 processing
    nodes must be available outside the data acquisition system.

-   

## Trigger Managers

The first and second level Trigger Managers are currently viewed as part
of the Trigger subsystems. However, they perform the same function as
other subsystem managers and may benefit from a common implementation.

## Detector Manager

The Detector Manager provides control/monitor fan-out and fan-in for the
Data Combiners associated with a specific subdetector. It also allows
standalone local control and monitoring of the subdetector. The Detector
Managers may be implemented using the same basic hardware and software
for all subdetectors, but may also include detector-specific software.

The Detector Manager receives and processes all control messages from
the Run Control system and returns status information. It also controls
the interface between the general timing system and individual
subdetector Data Combiners.

-   **Requirement 4.5-1 (Function):** The Detector Manager must allow
    standalone operation of a complete subdetector. This includes
    control and monitoring of both Run Control and Slow Control
    functions and emulation of synchronous signals from the Timing
    system. It must also be capable of reading (at a significantly
    reduced rate) any data which would normally be transmitted over the
    Readout System data links.

-   **Requirement 4.5-2 (Alarms):** The Detector Manager must be capable
    of locally displaying all subdetector alarms, in addition to passing
    this information to the Slow Control Host. \[central Alarm
    Manager?\]

## Data Storage (move to 3.6?)

Events passing the second and third level triggers will be transmitted
via optical links to a permanent storage system located in the Feynman
Computing Center.

-   **Requirement 4.7-1 (Storage system bandwidth):** The storage system
    must accept data at an average rate of 2 X 10^9^ bits per second. It
    must simultaneously supply data at an average rate of 2 X 10^9^ bits
    per second for offline analysis.

-   **Requirement 4.7-2 (Shared Resources):** The storage system must
    use the same archival robotics and media as BTeV offline.

-   **Requirement 4.7-3 (Buffering):** If the second level processors
    have local attached disk drives, these may be used to buffer data
    during short power or network interruptions at Feynman. The network
    supplying data to the data storage system and the data storage
    system itself must have excess bandwidth capacity to offload this
    accumulated data in a reasonable period of time. An interrupt
    capacity of 30 seconds in any 1 hour period is sufficient.

-   **Requirement 4.7-3 (Streaming):** Data storage must support storing
    similar events based on trigger type as a collection**.**

-   The data storage system must provide an integrated solution with a
    database management system (that's just a placeholder for a lot of
    work and interdependencies with the software/offline group. How will
    we store, catalog, and retrieve data?)

-   **Requirement 4.7-4 (Duplication of data):** Some data must be
    routed to more than 1 stream.

-   **Requirement 4.7-5 (Longetivity):** Data must be accessible for xxx
    months/years online and for xxx years in archived format.

## Central Services

Something on common DAQ features such as alarm and message logging,
displays etc

Something on the underlying software infrastructure such as CORBA
middleware

## Slow Control

The BTeV Slow Control system is used to monitor and set control/alarms
on the detector and in the off-detector electronics (pressures,
temperatures, high voltages, etc.)

-   **Requirement 4.8-1 (Segregation):** The Slow Control system must
    provide a data path which is independent of the Readout System data
    path, and/or must remain operational when the Readout System is
    off-line.

-   **Requirement 4.8-2 (Archival):** Slow control data and alarms must
    be archived at a rate appropriate to the functions being monitored,
    such that the state of the system is fully defined for later
    analysis in the offline code.

-   **Requirement 4.8-3 (Alarms):** The Slow Control Host must provide a
    centralized alarm display for all subsystems.

-   **Do error s here need to stop data taking or inhibit it from
    starting?**

-   **Field buses?**

# Infrastructure and Integration

## Control Network

The Control Network provides a general-purpose interconnection for all
other subsystems in the BTeV experiment. Run control commands need to be
routed to components both in parallel and in series.

-   **Requirement 5.1-1 (Control Network bandwidth):** The Control
    Network must provide sufficient bandwidth for efficient database
    access, download, monitoring, slow control and run control
    functions.

-   **Requirement 5.1-1 (Interconnection):** The control network must
    support a broadcast capability.

## Control Room

The Control Room...

-   **Requirement 5.2-1 (Accessiblity):** All information must be
    electronically accessible

## Databases

Databases are used throughout the system to provide accesses to
configuration parameter and to log status information. There may be
several global databases as well as local databases associated with each
subsystem.

-   **Requirement 5.3-1 (Uptime):**

-   **Requirement 5.3-2 (Backups/recovery)**

-   **Requirement 5.3-3 (Platform Accessibility)**

-   **Requirement 5-3.4 (Reliability)**

-   **Requirement 5-3.5 (Performance)**

-   **Requirement 5-3.6 (Scalability)**

-   **Requirement 5-3.7 (Longevity): Data must be available for n years
    after data taking has stopped.**

-   **Requirement 5-3.8 ():** Some online database information must be
    shared and synchronized (both directions) with data in offline
    databases.

## Test Stands

To the extent possible, all BTeV electronics will include built-in
self-test features. \"Test stands\" for these individual components will
consist mainly of a small power source and a means of connecting the
component to a standard desktop PC. For larger system tests, a test
stand which simulates the actual operating environment (full system
rack) will be necessary. An attempt will be made to minimize the number
of components designed solely for test purposes.

-   **Requirement 5.4-1 (Component test stands):** A standard
    development/test system including user modifiable,
    application-specific software and benchtop power must be provided
    for testing of individual electronics components.

-   **Requirement 5.4-2 (System test stands):** A standard rack based
    development/test system including system level software and power
    must be provided for testing of multiple components in a system
    environment.

## Installation

Installation...

-   **Requirement 5.5-1 ():** The

# Safety and Computer Security

## Safety

The Readout and Control System does not pose safety concerns beyond the
usual and customary issues associated with high-current low-voltage
digital electronics:

-   **Requirement 6.1-1 (Low Voltage, High Current Safety):** If
    high-current (greater than 10 amps operating or 50 amps rated
    current), low-voltage (less than 50 volts) supplies power the
    digital circuitry, the safety requirements for high current power
    distribution systems must be followed. These are detailed in the
    Fermilab ES&H Manual, Occupational Safety And Health section on
    Electrical Safety which can be accessed at
    www-esh.fnal.gov/FESHM/5000/5046.html.\
    Also, a hazard analysis sheet must be completed and signed by any
    person who will be working with any low-voltage, high-current
    system, circuit board, or other electronic device. The internal
    wiring of a commercially manufactured piece of equipment is exempt
    as detailed in the FESHM section reference above. The reference
    provides guidance on load connections, ribbon cables, multiple
    conductors and mechanical components.

-   **Requirement 6.1-2 (Computers): Safety of people or equipment
    cannot rely on computers or software.**

## Security

-   **Requirement 6.2-1 (Standards):** BteV readout and control system
    must conform to the Fermilab Computer Security Protection Plan

-   **Requirement 6.2-2 (Isolation):** Readout and controls system must
    operate when cut off from the Fermilab network.

-   **Requirement 6.2-3 (Rate):** Network architecture must be such as
    to allow for rapid isolation from the rest of the Fermilab network.

# Dependency Appendices {#dependency-appendices .unnumbered}

# A. Detector and Front-end Electronics Dependencies {#a.-detector-and-front-end-electronics-dependencies .unnumbered}

### A.1 Front-end to Data Combiner {#a.1-front-end-to-data-combiner .unnumbered}

-   **Dependency A.1-1 (Input data):** All data presented to the Readout
    System Data Combiners must be in digital form. To minimize the
    number of different Data Combiner designs, an optional front-end to
    Data Combiner Link specification will be proposed. Subsystems which
    adhere to this specification may interchange Data Combiner modules.

### A.2 Detector Data Rates {#a.2-detector-data-rates .unnumbered}

Cost and scaling of the Readout System is directly proportional to the
expected volume of data from the detectors. We rely on a reasonably
accurate prediction of average and worst-case data rates from each
subdetector.

-   **Dependency A.2-1 (Predicted data rates):** The bandwidth
    requirements of the Readout System will be based on the estimates of
    data rates provided by each subdetector, with some additional
    margin. These estimates should be as accurate as possible.

### A.3 Detector Timing {#a.3-detector-timing .unnumbered}

The Timing system and Data Combiners will distribute clock and
synchronous command signals to front-end electronics as necessary. There
are several options for distribution of these timing signals, but most
will require that fine adjustments (less than one clock period at 53
MHz) be done at the front-end module. The Timing system will maintain a
maximum jitter specification but will only correct for phase differences
in increments of one clock period. The front-end electronics must
compensate for differences in cable lengths and other delays following
the Data Combiners.

-   **Dependency A.3-1 (Timing signals):** Subsystems requiring
    synchronous signals with better than +/- 10 nsec phase resolution
    must provide local timing adjustment.

-   **Dependency A.3-2 (Crossing synchronization):** Any front-end
    electronics (or Data Combiner) containing a crossing counter must
    support a command that synchronizes the counter to zero at the next
    synchronous command signal. If the value of the counter at the time
    of the synchronous command signal is not already zero, a
    synchronization error must be reported for that front-end or Data
    Combiner.

### A.4 Slow Control {#a.4-slow-control .unnumbered}

-   **Dependency A.4-1 (Interface):** Interface to the main BTeV slow
    control system must be through a common SCADA package.

# B. First Level Trigger Dependencies {#b.-first-level-trigger-dependencies .unnumbered}

### B.1 Trigger Latency {#b.1-trigger-latency .unnumbered}

The **average** latency for first level trigger decisions cannot exceed
the time needed to fill a first level buffer at the maximum input data
rate. Also, assuming the use of DRAM in the buffer implementation, it is
preferred that the **maximum** latency of the first level trigger
decision, plus the time required to transfer the data to the second
level trigger, not exceed \[50\] milliseconds (this limit is chosen to
allow a circular buffer implementation and avoid DRAM refresh).

-   **Dependency B.1-1 (Latency):** The first level trigger must return
    a decision for all crossings within a specified maximum latency,
    even if processing for those crossings is not complete.

### B.2 Trigger Data Format {#b.2-trigger-data-format .unnumbered}

Data from the first level trigger may be stored in first level buffers
at various stages of the trigger calculation. The input bandwidth of the
first level buffers is dependent on the format of data received. The
buffers expect to receive data which has been grouped by timestamp
(crossing number), so that transfers to and from the memory can be
performed in blocks. If the received data is not grouped, the buffer
input bandwidth may decrease by a factor of 10 or more.

-   **Dependency B.2-1 ( ):** The first level trigger must group data
    written into First Level Buffers so that all data from a specific
    crossing in contiguous.

### B.3 Buffer Manager {#b.3-buffer-manager .unnumbered}

The Buffer Manager is the central point for assignment of events to
second level trigger processors. It receives trigger decisions from the
First Level Trigger System and receives requests for events from the
Second Level Trigger System

-   **Dependency B.3-1 (Assignment rate):** The Buffer Manager(s)
    transmit assignment messages to the First Level Buffers. The Buffer
    Manager must output assignment messages at a UNIFORM rate which does
    not exceed the AVERAGE L1 accept rate by more than 10%.

# C. Second Level Trigger Dependencies {#c.-second-level-trigger-dependencies .unnumbered}

### C.1 Request Timing {#c.1-request-timing .unnumbered}

There may be a significant latency (many milliseconds) between the time
a request for a new event is issued by a second level trigger processor
and the time that the event data is delivered to the processor. To avoid
idle time, processors should issue requests well in advance.

-   **Dependency C.1-1 (Latency):** Each processor in the second level
    trigger must request in advance and be capable of buffering returned
    data from as many events as necessary to avoid excess idle time
    waiting for data.

-   

# D. Facilities Dependencies {#d.-facilities-dependencies .unnumbered}

### D.1 Installation {#d.1-installation .unnumbered}

There are minimum space and power requirements for the readout and
control electronics.

-   **Dependency D.1-1 (Collision hall):** The Readout and Control
    electronics located in the collision Hall will require xxxU of rack
    space, xxx watts of electrical power and xxx BTU/hr of heat removal.

-   **Dependency D.1-1 (Counting room/Control room):** The Readout and
    Control electronics located in the counting Room will require xxxU
    of rack space, xxx watts of electrical power and xxx BTU/hr of heat
    removal.