![](bg2.png)
The TDAQ s/w is providing framework and API
used by other ATLAS groups to develop s/w pieces
which are all together compose the s/w running the
ATLAS trigger and data-acquisition system at the
experiment pit. Therefore, the proper s/w release
development, deployment and maintenance policy is
important to guarantee the smooth evolution of the
s/w from the integration stage to the deployment and
patching on the running system.
The s/w is made available to users in forms of
regular s/w releases. The requirements for the s/w
development model and s/w releases are listed
below:
− support of h/w platforms and compilers
used in ATLAS
− support of debugging
− support for different programming
languages and s/w tool-kits: C/C++, Java,
Python, IDL, Qt
− support of external s/w, integration with
ATLAS-wide and CERN-wide s/w
− support for remote installation
− support for patching
The development environment provided to users
should support the model of developing a package or
set of packages against a particular release.
Releases must be installed on a shared file
system (AFS, managed by CERN IT) for the testing
and development, made available for download for
the remote institutes and test labs and finally be
installed for the use at ATLAS pit for data-taking.
Before being released, a stage of integration and
testing of the s/w is necessary to guarantee the
quality and functionality of the s/w.
Still being in the development stage, the s/w was
actively used for integration with ATLAS
subdetectors and for commissioning the system at
the test beams (Gadomski, 2006).
To conclude, the s/w release model and tools
must provide the functionality and flexibility which
allow the development of TDAQ s/w, its testing and
validation, the deployment for remote labs and
institutes, the integration with the ATLAS
experiment production s/w, and finally the
maintenance of the s/w through the years of the life
of the experiment.
2 S/W RELEASE MODEL
2.1 Definitions
Package: an independently developed piece of s/w
providing some well-defined functionality in form of
libraries, applications and data files. Normally there
may be few developers contributing to a package.
Typically the source code of a Package resides in a
separate area in a code repository (e.g. SVN, see
Section 3.1).
Version Tag: a reference in the code repository
which uniquely defines some version of a package.
Usually it has a form of <package>-MM-VV-PP.
Platform: a combination of h/w and s/w tags which
identifies the type of binaries to be built. For
instance: i686, Linux slc5, gcc43, debug, profiled. A
release is build for a number of platforms (Section
3.2.2).
Release: a set of tagged packages built together for a
number of platforms, providing some well defined
and documented functionality for end users and
made available for distribution. It is a way in which
all efforts of developers of many packages is
exposed to users in a common structure.
2.2 Release Policy and Live Cycle
The release policy should provide a good balance
between moving the s/w forward and keeping it
stable for end users. Two types of releases are
foreseen by the model: major releases and minor
releases. Major releases may contain important
changes in the architecture of s/w, new functionality
and API changes in packages, database schema
changes and other similar changes which require
some actions from end users.
Minor releases may contain some internal
changes which do not require code changes at user's
side.
In addition, a patching schema is foreseen, where
a particular problem may be fixed by a binary patch
to a package in the release which is already deployed
to the system.
In the last years when the major development
was done, 2-3 major releases per year were
produced, and each one may be followed by 1-2
minor releases. In the present condition, when the
release is used for data-taking in ATLAS pit, no
major changes in s/w is possible, and all
maintenance and implementation of new required
features is made via the patching mechanism which
is described in more details in Section 4.
SOFTWARE RELEASES MANAGEMENT IN THE TRIGGER AND DATA ACQUISITION OF ATLAS
EXPERIMENT - Integration, Building, Deployment, Patching
221