\documentstyle[12pt,a4]{article}
\title{Overview of the Eurogam Data Acquisition System}
\author{V Pucknell}
\date{Edition 1.1\\February 1990}
\begin{document}

\begin{titlepage}
{

\hoffset=1truein
\hsize=5.25truein
\vsize=10.25truein
\font\small=cmssbx10 at 14.4truept
\font\medium=cmssbx10 at 17.28truept
\font\large=cmssbx10 at 20.74truept
\hrule height 0pt
\parindent=0pt
%\parskip=0pt
\hskip 3.9truein
\large
EDOC015\par
\vskip .5truein
\large
EUROGAM PROJECT\par
\vskip 1.5truein
\hrule height 2pt
\vskip 20pt
\large
NSF DATA ACQUISITION SYSTEM\par
\vskip .5truein
The Eurogam Data Acquisition System\par
An Overview\par
\vskip 20pt
\hrule height 2pt
\vskip 1truein
\medium
Edition 1.1\par
\vskip 5pt
February 1990\par
\vfill
\medium
NSF Software Systems Group\par
\vskip 5pt
UK Science and Engineering Research Council\par
\vskip 5pt
Daresbury Laboratory\par
\vskip .5truein

}
\end{titlepage}

\maketitle
\section{Introduction}

 The data acquisition and analysis system for Eurogam is
divided into a number of component sub-systems as described
in the block diagram. Each sub-system is a logical component
which performs a self contained function but does not
necessarily  by itself equate to a physical hardware 
component. Each sub-system has a well defined function described
briefly in this document. Further documents define in 
detail the specification of each sub-system and the
software protocols which describe its external interface.

 As long as the external interface is maintained any 
particular sub-system can be developed to take advantage 
of changes in technology without effecting other 
sub-systems. In some cases a number of implementations of
a particular sub-system may exist  to suit the local
requirements of a given laboratory. As long as the 
specification of the sub-system is fully supported 
and the external interface maintained then all other
sub-systems will function without the need for alteration.

 This approach allows a very flexible system to be 
produced which can respond to the changing 
requirements of the experimental program and take advantage 
where appropiate of changing technologies both with 
minimal impact on the system as a whole. In addition
variations on the system can be easily implemented
as required by the host laboratories and the
University collaborators. It should be noted that the 
latter will each require implementations of a subset 
of the system for data analysis.

 In keeping with the nature of the general system approach
the function of specific sub-systems make no statement
about implementation or hardware.
 The block diagram shows the component sub-systems and the
direction of control paths linking the sub-systems. Data may
flow in either direction on a sub-system link but control
is only in the direction indicated.
 
\section{The Sub-Systems}
 
\subsection{The Event Builder [1]}
 This sub-system receives data from the front-end electronics,
constructs complete events in the standard external format and
builds blocks of events for subsequent processing. A number
of streams of data blocks may be generated each containing 
different groups of events in order to simplify or 
improve performance of subsequent processing.

 The sub-system receives control information from the
acquisition control sub-system [6] and outputs event blocks
to the event processing sub-system [2].
 
\subsection{Event Processing [2]}
 This sub-system receives blocks of events from the event builder
sub-system [1] and processes the data in accordance with 
instructions received from the acquisition control sun-system [6].
All or a reconstructed subset of the received data is passed on to
the data storage sub-system [3]. In addition the acquisition 
control sub-system [6] may request sets of the processed data
for monitoring purposes and eventual presentation to the user.
 
\subsection{Data storage [3]}
 This sub-system is required to store event data received from the
event processing sub-system [2] onto permanent storage media. 
While the bulk data is received from the event processing 
sub-system control information which specifies the data
paths and selects the required storage medium plus other
data for storage is received from the acquisition control 
sub-system [6]. 

 The sub-system will handle multiple streams of data 
each directed to a different storage medium.

 For subsequent data analysis the data storage sub-system 
will on demand supply the event processing sub-system [2]
with event data previously stored.

\subsection{Electonics Setup, Control and Diagnostics [4]}
 This sub-system handles the setup of the front-end electronics.
It receives control information from the acquisition control
sub-system [6] and performs all functions necessary to set
data acquisition running.

 An additional function is to provide diagnostics facilities 
both via the acquisition control sub-system and via a
dedicated interface for maintenance of the hardware. Functions
are provided to enable diagnosis of faults and ensure a
short mean-time-to-repair (MTTR).
  
\subsection{Experimental Equipment Control [5]}
 This sub-system controls and monitors experimental equipment
associated with the system. Some items may be closely 
related to the acquisition system and control information
is received from the acquisition control sub-system [6]
while other items are indirectly related and control
information is received from the experimental control
sub-system [7].

 The external interface to this sub-system is required to
be particularly general purpose since the items to be
handled are varied and will change with time.
 
\subsection{Acquisition Control [6]}
 This sub-system coordinates the acquisition functions of the
system. It receives control information from the 
experimental control sub-system [7] and communicates
with the relevent sub-systems [1] - [5] necessary to 
execute the requested task.

 Once data acquisition has been setup by the
experimental control sub-system [7] and is running 
then this sub-system will continue to control 
acquisition of data without need for further input
unless an unusual event occurs which requires action on
the part of the user.

 Requests from the experiment control sub-system [7] for data
for experimental monitoring will be received periodically
and these will be satisified by obtaining the necessary
data from sub-systems [1] and [2].
 
\subsection{Experimental Control and Data Analysis [7]}
 This sub-system handles all user input received from the
graphics sub-system [8]. Input requests associated with
data acquisition are analysed and the appropiate requests 
passed on to the acquisition control sub-system [6] 
for execution. Monitoring of data acquisition and in
particular acquisition of histograms occurs via the
acquisition control sub-system [6] to which 
requests are passed for the required data.

 This sub-system performs all analysis functions on
acquired data (with the exception of the event processing
carried out by [2]) both in real time for the 
current experiment and for post experiment analysis sessions.
It is responsible for storage of all data other than event data
handled on-line by [3].

 Implementation is in a form which allows expansion of
facilities without limit and enables users to easily 
include private functions into the system in a 
consistent manner.

 Control and monitoring of experimental equipment
not directly related to data acquisition will be via
direct communication with the experimental equipment
control sub-system [5].

 All presentation of information to the user and 
interaction with the user will be via a two way 
dialogue with the graphics sub-system [8].
 
\subsection{Graphics [8]}
 The graphics sub-system has a two-way dialogue with the
experimental control sub-system [7]. This dialogue 
describes the graphics functions at a very high level in
terms appropiate to the requirements of the system.
By removing conventional graphical interfaces and libraries
from the data analysis functions we :-

 1) remove the requirement for each and every analysis 
function to include conventional graphics interfaces thus
preventing duplication of effort since may functions
require similar garphical facilities.

 2) Ensure a consistent presentation and user interface
across all functions.

 3) Since major graphical functions (such as histogram 
display and manipulation) need only to be implemented 
once we can afford to expend effort to achieve the
best possible result.

 As with other sub-systems as long as the external interface
is maintained the graphics sub-system can be changed 
without effect on the rest of the system.
 
\subsection{Communications [9]}
 The communications lines within the system are considered 
to be off sufficient importance to warrant being
classified as a separate sub-system.
In fact it is expected that some of the communications 
lines will change with time to take advantage of
improving technologies. At any time not all 
communications lines need to be of the same 
technology. The purpose of a communications line
is to move data from point to point and as long as this
is achieved by any given technology then we can replace
that line without effecting the rest of the system.

 The external interface to the communications
sub-system is technology independent while all 
interfaces and protocols which must be dependent on the
technology are internal to the sub-system.
\end{document}