ArticlePDF Available

Abstract

Many applications within the ATLAS DAQ prototype-1 system have complicated dynamic behaviour which can be successfully modelled in terms of states and transitions between states. Previously, state diagrams implemented as finite-state machines have been used. Although effective, they become ungainly as system size increases. Harel statecharts address this problem by implementing additional features such as hierarchy and concurrency. The CHSM object-oriented language system is freeware which implements Harel statecharts as concurrent, hierarchical, finite-state machines (CHSMs). An evaluation of this language system by the ATLAS DAQ group has shown it to be suitable for describing the dynamic behaviour of typical DAQ applications. The language is currently being used to model the dynamic behaviour of the prototype-1 run-control system. The design is specified by means of a CHSM description file, and C++ code is obtained by running the CHSM compiler on the file. In parallel with the modelling work, a code generator has been developed which translates statecharts, drawn using the StP CASE tool, into the CHSM language. C++ code, describing the dynamic behaviour of the run-control system, has been successfully generated directly from StP statecharts using the CHSM generator and compiler. The validity of the design was tested using the simulation features of the Statemate CASE tool
1983
IEEE TRANSACTIONS ON
NUCLEAR
SCIENCE,
VOL.
45,
NO.
4,
AUGUST 1998
Use
of
Statecharts
in
the Modelling
of
Dynamic Behaviour in the
ATLAS
DAQ
Prototype
-1
P.
Croll’,
P.-Y.
Duval’,
R.
Jones3,
S.
K010s4,
R.F.
Sari’
and
S.
Wheeler’
‘University of Sheffield, Western
Bank,
Sheffield, S10 2TN,
UK
’Centre de Physique des Particules de Marseille, 163 avenue de Luminy, case 907,13288 Marseille cedex
09,
France
3CEFtN, ECP Division, CH-1211 Geneva 23, Switzerland
4Petersburg Nuclear Physics Institute, Gatchina, Leningrad district, 188350 Russia (on leave at CERN)
Abstract
Many applications within the ATLAS DAQ prototype-1
system have complicated dynamic behaviour which can be
successfully modelled in terms of states and transitions
between states. Previously, state diagrams implemented as
finite-state machines have been used. Although effective,
they become ungainly as system size increases. Hare1
statecharts address this problem by implementing additional
features such as hierarchy and concurrency.
The CHSM object-oriented language system is freeware
which implements Hare1 statecharts
as
concurrent,
hierarchical, finite-state machines (CHSMs). An evaluation
of this language system by the ATLAS DAQ group has
shown it to be suitable for describing the dynamic behaviour
of typical DAQ applications. The language is currently
being used to model the dynamic behaviour of the
prototype-1 run-control system. The design is specified by
means of a CHSM description file, and C++ code is
obtained by running the CHSM compiler on the file. In
parallel with the modelling work, a code generator has been
developed which translates statecharts, drawn using the
StP
CASE tool, into the CHSM language. C++ code, describing
the dynamic behaviour
of
the run-control system, has been
successfully generated directly from
S
tP statecharts using
the CHSM generator and compiler. The validity of the
design was tested using the simulation features of the
Statemate CASE tool.
I.
INTRODUCTION
ATLAS is a particle physics experiment under
construction for the Large Hadron Collider (LHC) at
CERN.
The DAQ system foreseen for this experiment will have to
be able to reduce the unprecedented data rates
(-10
GByteh) to a level (-100 Mbyteh) at which interesting
events can be written to mass storage. This must be done
without losing any new or previously unpredicted physics.
In order to meet the challenge, the ATLAS DAQm (Data
Acquisition
/
Event Filter) “prototype-1’’ project
aims
to
produce a fully-functional prototype suitable for evaluating
candidate architectures and technologies for the final
DAQ/EF system of the experiment. The prototype consists
of
a
complete “vertical slice” of the ATLAS DAQ/EF
architecture. It includes all the hardware and software
elements of the data-flow chain, and the control and
monitoring required in an on-line system.
Within the prototype project, the back-end DAQ [l]
encompasses the software needed to configure, control and
monitor the DAQ, but excludes the management, processing
and transportation of physics data.
The run-control system is one of the software
components of the back-end DAQ. It is responsible for
controlling the data-taking activities of acquisition
components throughout the DAQ system. It can send
commands to DAQ components, query or receive status
information from them and provides operators with a means
to act upon the DAQ system.
The ATLAS collaboration has defined requirements for
a
software process and a supporting environment to develop
and modify all ATLAS software
[Z].
CASE (Computer
Aided Software Engineering) tools using suitable object-
oriented modelling methods have been identified as an
appropriate technology for supporting many aspects of this
process.
This paper begins with a summary of the process,
presented in more detail elsewhere
[3,
61, by which suitable
methods and CASE tools for the design of the run-control
system and other DAQ software components were chosen.
An
overview of the chosen CASE tools is given. This is
followed by a more detailed description of the method by
which these tools have been used to achieve and
subsequently verify the high-level design of the ATLAS
DAQ prototype run-control system.
11.
CHOICE OF
METHOD
AND
CASE
TOOLS
The ATLAS experiment will demand software
production on a scale far beyond that previously addressed
in High Energy Physics (HEP). Due to its size, complexity
and foreseen life-time, it is crucial that software is produced
and maintained to the highest possible engineering
standards. A considerable shift from the methods
traditionally used to produce software in
HEP
is required.
Fortunately, advances in computer science and technology
have provided software developers with powerful new
tools
to face this challenge. Object-oriented
(00)
design methods
used in conjunction
with
CASE tools allow the production
of robust, re-usable software, with sufficient flexibility to
meet the changing requirements
of
an HEP experiment. This
section summarises the process by which a suitable
00
method and supporting CASE tools were chosen to design
the run-control and other software systems
in
the DAQ
prototype project.
Many applications within the ATLAS DAQ system,
including the run-control system, exhibit complicated
dynamic behaviour. The system can be successfully
0018-9499
/98$10.00
0
1998
IEEE
1984
modelled in terms of states and transitions between states.
In the past, a number of different methods for modelling
such complex behaviour have been reviewed and/or used.
These methods are Petri nets, Z-Specification and State
Diagrams.
Petri nets offer good concurrent modelling facilities
with
a
graphical representation that has a formal
mathematical equivalence. The basic Petri net suffers by
requiring low-level detail to capture a complete system
model. Analysis of any non-trivial system can suffer
from
state explosion, Le., the search space is an exponential of
the system states. Petri net based CASE
tools,
e.g.
DesigdCPN, handle this through substitution transitions
(hierarchy) and colours (data typing). Experience has
shown
that these tools need considerable skill from a software
engineer plus constraints on the design to make analysis
tractable
[3].
Petri net tools also lacked dependable
commercial support.
Z
is
a
set-based formal method that permits
unambiguous mathematical specification but has no support
for concurrency and like many formal mathematical
methods, does not support graphical simulation.
State diagrams allow the dynamics of a system to be
modelled in terms of system states and transitions between
states. However, modelling large systems becomes ungainly
due to a lack of abstraction. Harel statecharts
[4]
address
this through introducing state hierarchy and concurrency.
Using the
OMT
modelling method
[5]
allows the static
structure to be represented via an object model while Harel
statecharts provide modelling of dynamic behaviour. The
aim
of using CASE tools for diagrammatical representations
and modelling is to allow software developers
to
concentrate on the design aspects rather than
implementation.
When choosing a CASE tool for the design of the run-
control software, the following points
also
had to be taken
into consideration:
It should be possible to generate code automatically
from the design diagrams
to
ensure the maintainability
of the software over several versions.
The run-control system has to run in a heterogeneous
environment. The software developed with the tool will
have to compile and run correctly on different operating
systems, presently Solaris, LynxOS,
HPUX
and
WindowsNT. Hence code developed with the tool
should be portable.
It must be possible to customise the code generation
so
that different languages can be produced for all
elements
of
the model (i.e. not just from the object
model), and in order that differences in compiIers
on
different machines can be taken into account.
It must be possible to integrate generated code with
third-party software.
The tool should be lightweight, not requiring excessive
resources
to
run.
The tool should be easy to learn and to use.
After evaluations of different
CASE
tools
[6],
it
was
decided that the
StP/OMT
(Software through Pictures)
CASE tool
[7]
was
the best overall product satisfying the
above conditions.
Although code generators can be written and integrated
with
StP,
allowing C++ code
to
be generated directly from
the dynamic model, an intermediate step, using the CHSM
object-oriented language system
[8]
has been employed
which greatly simplifies the effort. The CHSM language
system is summarised in the following section.
III.
OVERVIEW
OF
THE
CASE
TOOLS
Since
StP
and its code-generation capabilities are
described in detail elsewhere
[9],
only CHSM will be
described here.
CHSM
is a theoretically-rigorous, object-oriented
language system, built on C++, which implements Harel
statechatts
as
Concurrent, Hierarchical, Finite-State
machines. The language system supports
the
following
statechart concepts:
Hierarchy: child states can be “nested” in parent states,
allowing the parent state to be treated as a “black-box”.
Clusters: logical-exclusive-or state groups eliminate the
need for replicated transitions.
Sets: logical-and state groups eliminate the exponential
increase in the number of states when new states are
added.
Concurrency: sets allow transitions caused by the same
event to occur simultaneously in different parts of the
statechart.
History: entering a cluster enters the child-state that
was last active (as opposed to the default child-state)
Guard conditions: transitions are only made if a pre-
defined condition is true.
Actions: actions
can
be executed when transitions are
made and on entering
or
exiting a state.
Broadcasting: events can be broadcast when a transition
is made.
Implicit broadcasting: events are broadcast every rime
states are entered or exited possibly triggering
transitions in other parts of the statechart.
The above features can be described in a CHSM
description file. This is an ordinary text file consisting of
three sections. The first section contains declarations
required by any C++ code embedded in the rest of the file.
The second is the CHSM description itself and the third
contains optional user code. Guard conditions, transition
and state enter and exit actions are specified in the middle
section of the description file with the necessary C++ code.
The description file is converted to C++ by the CHSM
compiler. The resulting code is compiled and linked with
the CHSM run-time library, the source for which is freely
available. In the CHSM run-time library, states, clusters and
sets are implemented as C++ classes. These classes have
1985
predefined data-members and member-functions. The user
can derive classes from these classes, using C++ inheritance
to add data-members and member-functions. Furthermore,
existing methods, such as state enter and exit functions, can
be overloaded in order to augment their behaviour. This is a
powerful feature allowing C++ classes used in the DAQ
system to inherit their dynamic behaviour from CHSM.
There are several independent groups working on the
DAQ sub-systems. They will need to customise the
controller responsible for their part of the DAQ to perform
the operations specific for their particular component. The
actions which will need to be performed cannot be defined
in advance. A generic statechart is defined using
StP
and
CHSM which the developers use
as
a “template” framework
into which they can add their own specific operations.
Evaluations in the ATLAS DAQ group have proved
CHSM to be a very robust and flexible tool. It is a hybrid
language, where
C++
has been extended with additional
constructs and, as such, it has proved to be quick and easy to
learn. Furthermore, since it is based on
C++,
the resultant
code is easily incorporated with other programs and
modules of the DAQ system. A CHSM code generator has
been integrated with the
StP
tool to allow CHSM
description files to be generated automatically from
statecharts in the tool. The code generated by the CHSM
compiler, as well as the source for the run-time library,
compiles and runs correctly on all the platforms foreseen in
the DAQ system. It has
also
been shown that programs can
be written which successfully combine the CHSM code with
code from other commercial tools to be used in the DAQ
system (e.g. Corba/ILU, X-Window System, Rogue Wave
Tools.h++ C++ class library etc.)
IV.
ARCHITECTURE OF THE
RUN
CONTROL
Due to the size and complexity of the ATLAS
experiment, the run-control system cannot be implemented
as a single program. It is foreseen that the system will
consist of many programs executing on several distributed
computers connected through a network, as is already the
case with the Aleph experiment at
LEP
[lo].
Such a
distributed system reflects the structure of the DAQ itself
and will be implemented
as
a hierarchy of entities called
controllers, each with responsibility for a well-defined
component of the DAQ system. The controller’s state is the
simplified external view of the current working condition of
the component under its responsibility.
Each controller can receive commands from the outside
world. Commands cause a controller to execute actions
which potentially change the state of the controlled
component. The state of the component is published by the
controller to make it “visible” to the outside world. A
controller can also react to local events occurring in the
component under its responsibility. Typically its reaction
will
be to execute some actions and potentially change its
visible state.
The controllers are organised into a hierarchical tree
structure that reflects the general organisation of the DAQ
system itself. The hierarchy is defined
in
a configuration
database which is described in detail elsewhere
[ll].
Each
controller in the tree can have one parent (or superior)
controller and any number of child (subordinate)
controllers. At the top of the tree is a single controller which
represents the overall state of the entire system.
The controllers in the hierarchical tree transmit
messages between each other over a local-area network
(using the
OMG
Corba standard implemented by
ILU
[12])
in order to exchange commands and status information. In
general, commands starting from the human operator are
sent to the overall controller, which forwards them to the
sub-system controllers, who in turn forward them
to
component controllers and
so
on. In this respect commands
flow down from the root of the tree towards the leaves.
Replies, indicating the successful completion or otherwise
of commands and state information, are sent back up the
tree
so
that the human operator is made aware of any change
in the state of the system, or
of
any errors which have
occurred. Any node in the control tree
can
perform actions
on the commands or results of commands it receives.
V.
HIGH-LEVEL
DESIGN OF THE RUN-CONTROL
SYSTEM
The high-level design of the dynamic behaviour of a
single run controller was accomplished using the
StP
CASE
tool. Two statecharts were drawn reflecting different aspects
of a run controller’s behaviour. It is envisaged that every
controller in the hierarchy will be modelled by the same two
statecharts. The “Manager
CHSM’
handles the way in
which a controller interacts with the other controllers within
the run control hierarchy. It also forwards commands it
receives from the operator or parent controller to the second
“generic DAQ controller CHSM”. This CHSM models the
state of the controlled component and will
try
to execute the
forwarded command, possibly causing a change of state.
Once command execution is complete the generic CHSM
reports the success or failure to the manager CHSM which
then takes appropriate action.
In more detail, the generic DAQ controller CHSM
models the sequence of events necessary to take the
controlled apparatus from an
idle
state, where no data are
being taken, to an active, running state where data are being
collected from the apparatus, and back again. The CHSM,
extracted from
StP,
is shown in Figure
1.
State changes are
initiated by commands corresponding to events on this
statechart. These are sent by a human operator and then
propagated
through
the run control system. It is foreseen
that developers of the various controllers will be able to
customise the behaviour of their particular controller by
adding code to implement the required actions within the
generalised template provided by this CHSM.
Referring to Figure
1,
the central
Alive
super-state is
composed of two concurrent states:
DAQActivity,
which
reflects
the current status of data-taking activities and
DAQFuuZt,
which reflects whether or not an error has
occurred in the component being controlled. The human
operator issues commands which correspond to events
in
the
DAQActivity
state. When transitions, caused by these
1986
events, occur, actions are performed which carry out the
necessary operations to take the controlled component from
one state to the next. In the tool, the transitions are labelled
using standard OMT notation in the following manner:
event_name[guard-condition]/action.
The CHSM language
system is used to specify the guard conditions and actions.
On the diagram only event-name is shown for clarity.
I.
reset
Figure
1
:
Simplified generic
run
Controller
CHSM
extracted
from
the
StP/OMT
CASE
tool.
If the action fails for some reason (i.e. the component
being controlled does not respond correctly to the action),
this
can
be signalled to the parent controller by issuing the
DAQerror
event which takes the concurrent
DAQFault
state
to
Bad.
Recovery mechanisms have been envisaged for
three hfferent levels
of
error. Firstly,
if
an
error occurs
when making a transition between two states,
a
mechanism
is foreseen to take the CHSM back to the last error-free
state undoing any actions which were made during the
transition which caused the error. Secondly,
if
the error is
more
serious
and
cannot
be cleared
by
the
above
mechanism, the whole CHSM can be reset, during which,
all allocated resources are reset and freed and the CHSM is.
put back to its initial state. Finally,
if
a
fatal, non-
recoverable error occurs somewhere in the overall run
control system, the whole system can be shut down as
cleanly as possible. Since system integrity cannot be
guaranteed in such a situation, individual controllers cannot
rely on any communication
or
external interaction during
the shutdown.
The Manager CHSM models the interaction
of
the
controller with the other controllers in the run-control
hierarchy. The Manager CHSM, after being ported to
Statemate, is shown in Figure
2.
The port was done in order
to make use
of
Statemate's powerful test facilities (see
section VI). For communication between controllers,
dedicated
ILU
is used for sending commands down the tree
and the back-end DAQ Information Service
E131
for
returning replies up the tree and for making
DAQActivity
states visible
to
outside parties.
I
COMMSMGR
I
I
I
I
!
RECONNECTE
STATECHANGE
SYNCSEND
/
NCSEND
I
II
I
SENDONECMD/
CHILD-
1
11
0
CONNECTED
-
I
RCF
I
I
I
I
I
I
Figure
2
Simplified run controller manager
CHSM
extracted
from
the Statemate CASE
tool.
The main purpose
of
the Manager CHSM is to handle
the initial configuration of a controller when booting, and to
marshal the generic CHSM through transitions when DAQ
control commands are received from the operator or from a
parent controller. This includes forwarding the command to
any children a controller may have-either in synchronous or
asynchronous mode depending on the nature of the action
being carried
out.
During the initialisation and transition
phases, the CHSM is locked
so
that no new commands can
be received.
A concurrent state called
RCFuult
is used to reflect the
status of the run control hierarchy itself. If a controller has a
problem with
any
of
its
children
(e.g.
a
child is dead, not
responding,etc.) the
RCFault
state is set to
Bad.
The
Membership
concurrent state indicates whether the
controller is part of the run control hierarchy
of
controllers.
When
In
the controller will be controlled by its parent
controller; it will be ignored when it is
Out.
This feature
allows
a
controller with a specific problem needing
attention to be isolated without affecting the rest
of
the
system.
A
similar method has been used to design and
implement the
DAQ
supervisor. This is another component
of the run-control system, responsible for the creation and
1987
supervision of all the software elements in the run-control
hierarchy.
VI.
TESTING
THE
HIGH-LEVEL DESIGN
Although the approach taken has allowed a high-level
design of the run control to be created covering all aspects
of the OMT model, there was no simple way in which the
dynamic model could be simulated to test its validity before
implementation.
To
overcome this two different methods of
testing were investigated. Firstly, porting the statecharts to
the Statemate CASE tool and then using its powerful
simulation facilities for animation. Secondly, the CHSM
code generator integrated with
StP
was used to generate a
prototype and then the CHSM run-time library debugger
was used to check the behaviour.
The Statemate data-dictionary editor has been used to
configure the binding of the statechart objects and to create
an
array of objects to show which instantiations need to be
controlled. It can also be used to configure the data
structure,
data
type and usage of an object.
B.
Simulation with Statemate
The dynamic behaviour can be simulated,
allowing
visual observation of the changing transitions and states
through the use of different colours. Before a simulation can
be run the scope of the simulation profile will check the
correctness of the statecharts to detect inconsistencies,
while a completeness check detects redundancy and any
incompleteness in
a
model. Hence, possible violation in
syntax
and semantics, both in a single chart and in
communicating charts, can be detected.
A.
Usage
of
the Statemate
CASE
Tool
C.
Lessons Learnt from Statemate
The Statemate “Magnum” CASE tool
[14]
has been used
as a simulation tool in testing the high-level design in the The approach taken enabled binding of different object
a
set
of
graphical
tools
names by using the instantiation features of Statemate for
for the specification, analysis, design and documentation of simulating
different
statecharts- However,
the
large and complex reactive
systems.
Activity charts provide implementation of the system in a distributed environment
description and Statecharts the behaviour.
all the features of the hierarchy of control have been
simulated and analysed. More experiments are needed to
test the use of the hierarchy of statecharts in the run-control
project.
statemate
a
functional description, Module charts structural and With real hardware devices has Still to be validated. Not
Statemate
aims
to
be
an
indus~al-strength
CASE
and
system, i.e. would it be possible to model the interaction
defined Panel, Plus
and
dynamic
test
between controllers in the hierarchy and not just between
robust
graphical chart editors
and
a
user-
facilities.
An
automatic code generator produces C and
the
statecharts.
ADA directly from the graphical models. Analysis of the
statechart models allows issues
of
reachability, deadlock
Some
benefits
Of
&ltemate
Magnum
in
enhancing
the
and transitions usage to be addressed.
overall software engineering cycle have been observed
during this project. For example, it simplifies modelling of a
system
to
label
a
in
a
statechart,
textual specification, it validates system behaviour, and it
“event[condition]/action”.
Some minor differences in detects
and
eliminates
specification
errors
before
syntax between the CHSM and Statemate statecharts were
implementation.
found during the prototype implementation.
The most helpful feature of Statemate, in this study,
is
Chart
are
its capability to simplify the understanding of operation
available in Statemate, only the Statechart view was used to
clear
animation
of
graphical models.
CASE
tools such
match the existing designs
in
StP
and CHSM. The statechart as
statemate
can
be used
to
show what would happen if
behavioural view describes the system’s behaviour over
multiple
interacting
events
take
place, which
is
time, including the dynamics of activities, their control and
hard
to
conceptualise.
timing behaviour, both the states and modes of the system
and the conditions and events that cause mode and state
changes. The behavioural model provides answers to
questions about causality, concurrency and synchronisation,
which are paramount features for the run-control system.
Statemate
to the CHSM language
complex system, it eliminates ambiguities common in
the
Activity
chart
and
Testing
with
cHsM
The CHSM code generator integrated with
StP
was used
to create C++ code corresponding to the high-level design.
The code was compiled and linked with the CHSM run-time
provides tracing facilities that print output to the screen
including currently active states and information on the
event handling. Using
these
debug features, it was found,
for
instance*
that
the
concurrent
State
in
the
Manager
CHSM,
responsible
for
locking
the
CHSM
when
handling
a
Statemate
incorporates
a
broadcast
mechanism, and time-out and delay operators for specifying
library
in
Order
to
get
a
working
Program*
CHSM
synchonisation
and
timing
Each
element
in
the
statechart has
an
entry
in
the
data
dictionary,
which
can
be used
to
input specific infomation. SQtemate
allows
large
charts to be split into separate hierarchical ones
as
seen
by
the
two
communicating Statechafts,
of
Generic
As
with
programming
absuactions,
this
facility
improves
readability
through
structure
hiding
and
promotes
chart
reuse.
Run Controller
and
RC-FSM-Manager, see Figures
1
and
2.
transition, was not spchronised properly*
in
order to carry out more extensive tests, it has been
necessary to add
a
significant amount of hand-written code
to implement the controller hierarchy.
1988
VII.
CONCLUSIONS
A combination of CASE tools that support statecharts to
create and test the high-level run control design
were
utilised. Harel statecharts were found to be an appropriate
method for modelling the dynamic behaviour of the run
control.
StP
provided the necessary formalism and its code
generation facilities, combined with the CHSM language
system, gave sufficient flexibility to allow third-party
software to be successfully integrated. This enabled the
generated software to
run
in a heterogeneous environment
and allowed each controller in the system to be customised.
The debugging facilities of the CHSM language system,
combined with the simulation facilities
of
Statemate,
allowed testing of the high-level design before embarking
on the detailed implementation. Now that the high-level
design is complete, a prototype run controller has been
created and integrated with third-party software
to
implement communication between controllers and is
currently undergoing thorough testing.
For future work the possibility of automatically porting
the design from
StP
to Statemate is being investigated. For
the current project, the porting was done by hand. One
problem encountered with Statemate is how to simulate the
distributed run controller hierarchy, Although validation for
a single run controller model was achieved, creating a
simulation of the hierarchy proved more difficult, although
this should be possible. This would involve multiple copies
of the run controller statecharts, representing different
processes running on different machines, interacting in a
hierarchy.
Rhapsody, a successor
to
Statemate, is a new CASE tool
launched in May 1997 by i-Logix as an integrated set of
diagrammatic languages for object modelling
[15].
It is still
built around statecharts, but holds promise to overcome
some of the difficulties that have been have encountered.
The plan is
to
investigate the use of Rhapsody in
forthcoming ATLAS TriggerDAQ activities.
VIII.
ACKNOWLEDGEMENTS
We would like to thank Paul J. Lucas for answering
many questions about the CHSM language-system and his
considerable help in porting
the
system
to
WindowsNT. We
would
also
like
to
thank Kivanc
Nurdan
and Louis Tremblet
for
their input on the design of the run controller.
IX.
REFERENCES
ATLAS DAQ Back-end software
-
User
Requirements Document, 30 May 1996.
http://atddoc.cern.ch/Atlas/DaqSoft/document/&aft-1
.h
tml
.
ATLAS Software Development Environment
-
User
Requirements Document, 26 April 1996.
ATLAS
Intemal Note SOFT-NO-034, also available from
h ttp
:
//atlasinfo. cem
.
ch/Atlas/documentation/notes/S
OF
TWARE/note34/asde.html
[3] P.R. Croll, I.E. Jelly and
I.
Gorton, “Software
Engineering Techniques and Tools for High
Performance Parallel Systems”,
IEEB Aim
International Symposium on Parallel
Algoritldkchitecture Synthesis (pAs’95), Japan,
[4]
D. Harel, “Statecharts: A Visual Formalism for
Complex Systems”,
Sci.
Computer
Prog.,
pp. 231-274,
July 1987.
[5] James Rambaugh, Michael Blaha, William Premerlani,
Frederick Eddy, William Lorensen, Object Oriented
Modeling and Design, Prentice
€€all,
199
1.
[6] C. Bee et al., “Applications of an
00
methodology and
CASE
to
a DAQ system”, Proceedings of the
International Conference on Computing in High Energy
Physics 95, World Scientific Publishing, 1996, pp. 678-
686.
[7] Information on
StP/OMT
is
available on
WWW
at:
http://www
.ide.com/Products/StP/StP-OMThtml.
[8]
P.
J.
Lucas,
F.
Riccardi, “CHSM: A Language System
Extending C++ for Implementing Reactive Systems”,
http://www.best.com/-pjl/software.hbnl.
[9] A. Pate1 et al., “Use of Object oriented CASE tools for
Automating the Development of DAQ Software”, to be
published in Proceedings
of
the
10”
IEEE-NPSS Real
Time Conference, Beaune, 1997.
[
101
A.Aimar et
al.,
“Representing system behaviour with
dynamic models and executing them: The new Aleph
finite state machine”, Proceedings of the International
Conference on Computing in High Energy Physics 95,
World Scientific Publishing, 1996, pp. 625-631,
[11]I.
Soloviev et
al.,
“The Persistent In-memory Object
Manager”, to be published in Proceedings of the
10”
IEEE-NPSS Real Time Conference, Beaune, 1997.
[12]A.
Amorim
et
al.,
“Use of Corba in the ATLAS
prototype DAQ’,
IEEE
Trans.
On
Nucl. Science,
vol.
45, No. 4, August 1998.
[13]
M. Caprini et al., “Information service for Atlas DAQ
Prototype
-l”,
ATLAS DAQ Prototype-1 Technical
Note
31.
http: //atddoc .cem
.
ch/Atlas/Notes/03 1/Note03
1
-
1
.htm1
[
141 D. Harel, “STATEMATE? A Working Environment for
Development
of
Complex Reactive System”,
IEEE
Transactions
on
Software Engineering,
pp.
403-414,
April
1997.
[15lD. Harel and E. Gery, “Executable Object Modeling
with Statecharts”,
IEEE
Computer
Magazine,
pp. 31-
42, July 1997.
1995,
pp. 85-91.
... Telelogic Tau [27], Mentor Graphics' BridgePoint [28], Borland Together for Eclipse [29], RSA RealTime, and SmartState [30] are some leading commercial tools that support automated code generation from state machines. On the open source side, FSMGenerator [31], Concurrent Hierarchical State Machine (CHSM) [32], HUGO [33], and FSM Framework offer that support. ...
... A short dcscription oi tlic camponcnts with somc performance test rcsults follows. I' m further inforonnation on the back-end componcnts d e r to [4]. ...
Article
Full-text available
The DAQ group of the future ATLAS experiment has developed a prototype system based on the trigger/DAQ architecture described in the ATLAS Technical Proposal to support studies of the full system functionality, architecture as well as available hardware and software technologies. One sub-system of this prototype is the back-end which encompasses the software needed to configure, control and monitor the DAQ, but excludes the processing and transportation of physics data. The back-end consists of a number of components including run control, configuration databases and message reporting system. The software has been developed using standard, external software technologies such as OO databases and CORBA. It has been ported to several C++ compilers and operating systems including Solaris, Linux, WNT and LynxOS. This paper gives an overview of the back-end software, its performance, scalability and current status
Article
The DAQ group of the future ATLAS experiment has developed a prototype system based on the Trigger/DAQ architecture described in the ATLAS Technical Proposal to support studies of the full system functionality, architecture as well as available hardware and software technologies. One sub-system of this prototype is the back-end which encompasses the software needed to configure, control and monitor the DAQ, but excludes the processing and transportation of physics data. The back-end consists of a number of components including run control, configuration databases and message reporting system. The software has been developed using standard, external software technologies such as OO databases and CORBA. It has been ported to several C++ compilers and operating systems including Solaris, Linux, WNT and LynxOS. This paper gives an overview of the back-end software, its performance, scalability and current status
Data
Full-text available
Article
The goal of this research is the study of a methodology to convert design-level specifications of complex embedded systems to system-level functional tests for direct instrumentation; the general context is industrial end-of-production environment (EOP) and the approach uses official and de facto industrial standards (e.g., Unified Modeling Language, UML) and advanced techniques from academic research. The research suggests process guidelines, exploring the generation of the timed test sequences from a UML model, the translation phases, and addressing the problem of timing and environment creation. A case study of a significantly complex application is provided directly from the industrial world thanks to an agreement between Politecnico’s Testgroup and Magneti Marelli Electronic Systems, research and development site of Venaria Reale, an international leader in automotive applications.
Conference Paper
In this paper, we propose the use of a UML methodology to go from user requirements and specifications to end of production testing of complex embedded systems. We consider behavioral, structural and physical levels building a comprehensive and modular model. The process contains the definition of a set of properties being created and then updated in each phase, and heavily relies on message passing and elaborating facilities to increase both abstraction and descriptive power. Result of the process is test pattern generation using custom ATE commands. We also present and discuss an underdevelopment case study of a significantly complex automotive application
Article
Full-text available
STATEMATE is a set of tools, with a heavy graphical orientation, intended for the specification, analysis, design, and documentation of large and complex reactive systems. It enables a user to prepare, analyze, and debug diagrammatic, yet precise, descriptions of the system under development from three interrelated points of view, capturing structure, functionality, and behavior. These views are represented by three graphical languages, the most intricate of which is the language of statecharts, used to depict reactive behavior over time. In addition to the use of statecharts, the main novelty of STATEMATE is in the fact that it understands the entire descriptions perfectly, to the point of being able to analyze them for crucial dynamic properties, to carry out rigorous executions and simulations of the described system, and to create running code automatically. These features are invaluable when it comes to the quality and reliability of the final outcome
Article
Full-text available
The OKS (Object Kernel Support) is a library to support a simple, active persistent in-memory object manager. It is suitable for applications which need to create persistent structured information with fast access but do not require full database functionality. It can be used as the frame of configuration databases and real-time object managers for Data Acquisition and Detector Control Systems in such fields as setup, diagnostics and general configuration description. OKS is based on an object model that supports objects, classes, associations, methods, inheritance, polymorphism, object identifiers, composite objects, integrity constraints, schema evolution, data migration and active notification. OKS stores the class definitions and their instances in portable ASCII files. It provides query facilities, including indices support. The OKS has a C++ API (Application Program Interface) and includes Motif based GUI applications to design class schema and to manipulate objects. OKS has been developed on top of the Rogue Wave Tools h++ C++ class library
Book
This new book refines, customizes, and extends the general Object Modeling Technique (OMT) methodology for the specific subject matter of database applications. By restricting the scope of coverage, the authors are able to present more focused examples and elaborate upon the appropriate methodological steps. The authors present a uniform treatment that addresses files, relational databases, and object-oriented databases.
Article
We present a broad extension of the conventional formalism of state machines and state diagrams, that is relevant to the specification and design of complex discrete-event systems, such as multi-computer real-time systems, communication protocols and digital control units. Our diagrams, which we call statecharts, extend conventional state-transition diagrams with essentially three olements, dealing, respectively, with the notions of hierarchy, concurrency and communication. These transform the language of state diagrams into a highly structured' and economical description language. Statecharts are thus compact and expressive--small diagrams can express complex behavior--as well as compositional and modular. When coupled with the capabilities of computerized graphics, statecharts enable viewing the description at different levels of detail, and make even very large specifications manageable and comprehensible. In fact, we intend to demonstrate here that statecharts counter many of the objections raised against conventional state diagrams, and thus appear to render specification by diagrams an attractive and plausible approach. Statecharts can be used either as a stand-alone behavioral description or as part of a more general design methodology that deals also with the system's other aspects, such as functional decomposition and data-flow specification. We also discuss some practical experience that was gained over the last three years in applying the statechart formalism to the specification of a particularly complex system.
Article
The RD13 project has evaluated the use of the Object Oriented Information Engineering (OOIE) method during the development of several software components connected to the DAQ system. The method is supported by a sophisticated commercial CASE tool (Object Management Workbench) and programming environment (Kappa) which covers the full life-cycle of the software including model simulation, code generation and application deployment. This paper gives an overview of the method, CASE tool, DAQ components which have been developed and we relate our experiences with the method and tool, its integration into our development environment and the spiral lifecycle it supports.
Book
Object-oriented modelling and design promote better understanding of requirements, cleaner designs and more maintainable systems. Often, books on related subjects rely on programming and coding, forcing readers to think in terms of the computer, and not the application. "Object-oriented Modeling and Design" emphasizes that object-oriented technology is more that just a way of programming. It applies techniques to the entire software development cycle. This volume presents a new object-oriented software development methodology - from analysis, through design, to implementation. Key features of the book include a focus on high-level, front-end conceptual processes of analysis and design, rather than just on the low-level, back-end implementation steps of programming; coverage of the entire development life cycle - analysis, design, implementation without a change of notation at each stage; a presentation of graphical notation and methodology independent of any particular programming language; case studies of industrial object-oriented applications developed by the authors; and examples and exercises that bring out fine points, summary lists of concepts and methodology steps, and almost 300 diagrams.
Conference Paper
This paper considers the current state of software engineering for parallel systems. A review of existing approaches and techniques identifies inadequacies. Recent work on design, verification and automated support is outlined. The next generation of embedded and distributed technologies will compound the problems through increased demand and diversity. This paper discusses the implications for the progression of current techniques into new methods for future software engineering of parallel systems