GAS - A General Application Server
Paper: 127
Session: B (talk)
Speaker: Mora de Freitas, Paulo, Ecole Polytechnique, Palaiseau
Keywords: monitoring systems, portability, control systems, data acquisition systems, wide-area networking
GAS - A General Application Server
H. Delchini [1], J. Gilly[2], J.F. Huppert[1], P. Mora de Freitas[2],
M. Punch [3], M. Rivoal [1]
[1] L.P.N.H.E - Paris VI
[2] L.P.N.H.E - Ecole Polytechnique
[3] L.P.C. - College de France
Abstract
The HEP community often deals with an heterogeneous distributed architecture
when building data acquisition systems. Typically, a master central mainframe
or workstation controls slave processors, which in turn control the various
sub-detectors, all connected by the TCP/IP protocol.
The master should be able to start remote tasks on slaves and to send slow
control parameters commands in safe way. Remote readout tasks collect data,
keep it in local slave data storage or pipe it to the master. Monitoring
tasks running anywhere else must access and display sampled collected data
to control quality and detector conditions.
When developing the CAT(1) Data Acquisition System, particular attention was
paid to highly modular, open, and portable design. This led us to develop
and implement the General Application Server (GAS), a portable and
general architecture for HEP acquisition systems structured around GAS control
and data clients.
A controller client on host A, typically dealing with a sub-detector, looks
for a free GAS running on host B. If found, the client takes control over
this GAS and commands the start up of a task on host C. Typically host C is near
to sub-detector hardware and the task is able to control it and collect its data,
but A, B and C can even be on the same machine.
The controller client commands the remote task by sending it statements. A statement
is a printable free-format ASCII stream passed to the task that sends back a free-
format acknowledgement. The GAS doesn't care about message contents, and simply passes
them on. Tasks can also send asynchronous out-of-band messages to the controller,
typically alarms.
If the task on host C starts up successfully, the client controller stores in the
GAS a free-format configuration buffer to be propagated to later data client
connections. Via the GAS, control clients can also send "on-the-fly" messages to
data clients.
Data clients on hosts A, B, C, D,... search through the attached GASs to find that
which is connected to the desired service. When the client finds it, it receives a
copy of the configuration buffer from the GAS; it is then able to ask the GAS to
send it specific data samples.
This model bring us a highly-modular and open design. The GAS implementation and
protocol are completely application-invariant and re-usable, controller and data
clients developments are fully independent. To comply with POSIX portability
standards, TCP/IP services and platform-independent data representation are the
key choices. Thus, the GAS starts the remote task using standard Remote Shell
protocol, communicates with it via standards stdin/stdout/stderr channels and
so on.
The CAT data acquisition system is now running and has been in operation since
Summer 96. This first GAS model implementation is LabVIEW embedded, and is thus
portable on all LabVIEW platforms (Mac, PC, SUN and HP). A second implementation
in standard C-ANSI code should be running from December 96. A Java/HTML
interface is being considered.
(1) the Cerenkov Imaging Telescope of the CAT experiment (Cerenkov Array at
Themis) in the French Pyrenees.