User Requirements Document: Hardware Description of The GET System

IRFU/CEA Saclay
GET -
Hardware description of the GET system
User Requirements Document

Issue: 0
Revision: 0
Reference: WiKi-reference
Created: 05-feb-2009
Last modified:
Prepared By: Frédéric Druillole

GET -Hardware description of the GET system Reference: WiKi-reference
User Requirements Document Revision: 0
Issue: 0 Last modified:
This document has been prepared using the CERN PSS-05 Templates. The CERN PSS-05 Templates
have been prepared by the Information and Programming Technology Group, ECP Division, CERN (The
European Laboratory for Particle Physics) and conform to the PSS-05 Software Engineering Standards
(ISBN 0-13-106568-8) defined by ESA (European Space Agency) BSSC (Board for Software
Standardization and Control).
page 2
Erreur ! Style non défini.
Abstract
Example: This document describes the requirements and constraints for the read-out electronics of the
Time Projection Chambers (TPCs) foreseen at the T2K 280 m neutrino oscillation experiment. It
addresses both hardware and software aspects, and groups in a single document the various
requirements, capabilities and constraints that have been identified. The purpose of the document is to
provide the most complete, accurate, and up-to-date list of specifications for the system being designed.
Document Status Sheet
Maintain document history information in the table below. The Document Status Sheet (DSS) provides a
history of issues and revisions of the document with a comment indicating the reason for the revision.
Note that the Document Title and the Document Reference Number should never change from one
revision to another.
Table 1 Document Status Sheet
1. Document Title: T2K 280 m TPC - Read-out Electronics - System and User Requirements
Document
2. Document Reference Number: EDMS blabla
3. Issue 4. Revision 5. Date 6. Reason for change
0 0 19 July 2005 Creation
page 3
Document Change Record
Record all changes between this and previous revision in a Document Change Record (DCR) table. A
new DCR per revision is required.
Table 2 Document Change Record (of changes made since issue ... )
Document Change Record DCR No.

Date
Originator
Approved By
1. Document Title
2. Document Reference Number [Document Reference Number]
3. Document Issue / Revision Number [Document Issue]/[Document Revision Number]
4. Page 5. Paragraph 6. Reason for Change
page 4
Table of Contents
Abstract.................................................................................................................iii
Document Status Sheet.......................................................................................iii
Document Change Record..................................................................................iv
Table of Contents..................................................................................................v
List of Figures.......................................................................................................vi
List of Tables.......................................................................................................vii
1 Introduction...................................................................................................1
1.1 Purpose of the document.............................................................................................1
1.2 Scope of the system....................................................................................................1
1.3 Definitions, acronyms and abbreviations....................................................................1
1.3.1 [Definitions]....................................................................................................1
1.3.2 [Acronyms].....................................................................................................1
1.3.3 [Abbreviations]...............................................................................................2
1.4 References...................................................................................................................2
1.5 Overview of the document..........................................................................................2
2 General Description......................................................................................3
2.1 Product perspective.....................................................................................................3
2.2 General capabilities.....................................................................................................3
2.3 General constraints......................................................................................................3
2.4 User characteristics.....................................................................................................3
2.5 Operational environment.............................................................................................4
2.6 Assumptions and dependencies...................................................................................4
3 Specific Requirements.................................................................................5
3.1 Capability Requirements.............................................................................................5
3.1.1 Data Acquisition.............................................................................................5
3.1.2 Synchronization..............................................................................................8
3.2 Constraint requirements............................................................................................10
3.2.1 General..........................................................................................................11
3.2.2 [subsection]...................................................................................................16
4 List of User Requirements.........................................................................17
A [Appendix Heading]........................................................................................19
page 5
List of Figures
Erreur ! Aucune entrée de table d'illustration n'a été trouvée.
page 6
List of Tables
Table 1 Document Status Sheet........................................................................................
Table 2 Document Change Record (of changes made since issue ... ).............................
page 7
page 8
1 Introduction
1.1 Purpose of the document
The purpose of this document is to define the most complete and accurate set of constraints and
requirements to drive the design of the read-out electronics of the TPCs. All relevant parameters, desired
performance figures, operating ranges, functionalities, etc shall appear in this authoritative document.
1.2 Scope of the system
The system being discussed in this document is the global set of electronic hardware (and the associated
software) that connects at the back of the gas amplification modules of the TPC’s on one end, and that
interfaces to the common Data AcQuisition (DAQ) system of the T2K 280 m experimental setup on the
other end. The system considered includes two main blocks: the part mounted directly at the back of the
TPC modules inside the magnet, and the part located outside of the magnet. The former shall be referred
to as “on-detector electronics” and the latter as “off-detector electronics”.
1.3 Definitions, acronyms and abbreviations
Specify special terms, acronyms and abbreviations used in the document. The subsections may be re-
organized as necessary. For each definition, acronym or abbreviation use a paragraph pair of either DL1
Term and DL1 Description paragraphs, or, of DL1 Term RIH and DL1 Description paragraphs.
1.3.1 [Definitions]
1.3.2 [Acronyms]
ASIC
Application Specific Integrated Circuit
ESA
European Space Agency
page 1
CERN
European Laboratory for Particle Physics
1.3.3 [Abbreviations]
1.4 References
List all external documents referenced in this document
[1] T2K 280 m Conceptual Design Report
1.5 Overview of the document
Provide an overview of the document.
page 2
2 General Description
2.1 Product perspective
Describe related external systems and subsystems.
2.2 General capabilities
The read-out electronics of the TPCs is responsible for amplifying, shaping and digitizing the signal of
the ~85.000 pads of these detectors. At the front-end side, low noise is critical and some flexibility is
needed to accommodate a wide range of options (gas amplification technology, gas mix). The large
number of channels combined to a sampling rate of several MHz lead to a peak data rate of several
Tbit/s, although the average event rate is rather low (a few Hz). After digitization, the system is
responsible for grouping the relevant data into event fragments and sending them to the common DAQ
system of the experiment. In addition to the main capabilities, the system being discussed in this document
performs some of the tasks required for the correct and safe operation of the TPCs: local system
configuration, detector calibration and performance monitoring, intra-TPC system synchronization and
interface with an experiment-wide synchronization network, interface to the DAQ and run control
systems, low voltage power distribution.
2.3 General constraints
On-detector TPC electronics is mounted at the back of the gas amplification system, in the space left
available between the detector planes and the magnet (or possibly a calorimeter surrounding the TPCs).
In this confined environment, space is scarce, power dissipation should be minimized, though water
cooling seems unavoidable, access is limited to maintenance periods, and tolerance to (a modest)
magnetic field is required. Compatibility at the mechanical and electrical level with the general
infrastructure of the experiment must be assured. For the integration of the TPCs in an experiment-wide
data acquisition and run control system, the system must conform to the commonly agreed hardware and
software interfaces. Local safety regulations for underground experiments must be followed and
compliance with all the fire, seismic and environmental directives that apply must be granted.
2.4 User characteristics
Describe who will use the software and when.
page 3
2.5 Operational environment
Describe what external systems do and their interfaces with the product.
2.6 Assumptions and dependencies
Describe the assumptions upon which the requirements depend.
page 4
3 Specific Requirements
List all specific requirements, with attributes.
User requirements fall into two categories: capabilities needed by users to solve a problem or achieve an
objective; constraints placed by users on how the problem is to be solved or the objective achieved.
3.1 Capability Requirements
Capability requirements describe functions and operations needed by users. Quantitative statements that
specify performance and accuracy attributes should form part of the specification of a capability.
Space and time dimensions can be useful for organising capability requirements. It is often convenient to
describe capability requirements in terms of a sequence of operations.
UR-1 [Statement Title]

[UR Statement]
Need [How essential is this UR]
Priority [Priority for incremental delivery]
Stability [How subject to change is this UR]
Source [Name of person, group, document, ... from which the UR originates]
Clarity [If more than one interpretation possible, this must be qualified]
Verifiability [Check that UR is incorporated into the design, is implemented in the software, and can
be tested]
[Any Other Attribute] [Value of any other attribute]
3.1.1 Data Acquisition
UR-2 Event acquisition rate and system dead-time

The system must be able to acquire the data of all TPC channels and transfer to the DAQ system at least
the non-empty values with no dead-time at a maximum rate that shall be specified. The maximum
acceptable average event rate is 20 Hz. The maximum peak event rate is 20 Hz. Consequently, the
minimum interval between 2 consecutive acceptable events is 50 ms. The maximum dead-time of the
system after each event is 50 ms.
Need mandatory
Stability to be discussed
Source [Name of person, group, document, ... from which the UR originates]
Verifiability
page 5
4 List of User Requirements
UR-01 [Statement Title]...................................................................................5

UR-02 Event acquisition rate and system dead-time........................................5
page 6
A [Appendix Heading]
page 7

User Requirements Document: Hardware Description of The GET System

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

User Requirements Document: Hardware Description of The GET System

Uploaded by

Copyright:

Available Formats

IRFU/CEA Saclay

User Requirements Document

Prepared By: Frédéric Druillole

Document Status Sheet

Table 1 Document Status Sheet

Document Change Record

Document Change Record DCR No.

3. Document Issue / Revision Number [Document Issue]/[Document Revision Number]

4. Page 5. Paragraph 6. Reason for Change

Erreur ! Aucune entrée de table d'illustration n'a été trouvée.

Table 1 Document Status Sheet........................................................................................

1.1 Purpose of the document

1.2 Scope of the system

1.3 Definitions, acronyms and abbreviations

List all external documents referenced in this document

[1] T2K 280 m Conceptual Design Report

1.5 Overview of the document

Provide an overview of the document.

2.1 Product perspective

Describe related external systems and subsystems.

2.2 General capabilities

2.3 General constraints

2.4 User characteristics

Describe who will use the software and when.

2.5 Operational environment

2.6 Assumptions and dependencies

Describe the assumptions upon which the requirements depend.

List all specific requirements, with attributes.

3.1 Capability Requirements

UR-1 [Statement Title]

3.1.1 Data Acquisition

UR-2 Event acquisition rate and system dead-time

4 List of User Requirements

UR-01 [Statement Title]...................................................................................5

You might also like