Presentation made at the Real Time Conference, Santa Fe, New Mexico 14-18 June 1999The Event Builder and Distribution System (EBDS) is a component of the data-acquisition architecture of the ALICE experiment at CERN. The purpose of the EBDS is to dispatch the sub-events originated in the detector front-end electronics to the processors of the Event Filter Farm, where the full events are assembled.For the design of the EBDS, we use the Real-time Object-Oriented Modelling method (ROOM), which was chosen because of its powerful modelling paradigm, well suited to this type of application. The use of ROOM is aided by the ObecTime Developer tool set, which fully supports the method and covers all the aspects of the development cycle, from analysis to code generation. Fast prototyping and simulation bring a new perspective to the designer, who can advance by gradual refinements.We describe how ROOM has been used to design a model of both the EBDS and its environment, and the results obtained from the simulation. We also review the experience acquired with ROOM and the ObjecTime tool, and indicate what benefits and obstacles we encountered.<P

Carena, W

Divià, R

Van de Vyvre, P

Vascotto, Alessandro

CERN Document Server

The use of ROOM in the design of data-acquisition software componentsW. Carena, R. Divià, P. Vande Vyvre and A. Vascotto (for the ALICE collaboration)CERN, CH 1211 Geneva 23, SwitzerlandAbstractThe Event Builder and Distribution System (EBDS) is acomponent of the data-acquisition architecture of the ALICEexperiment at CERN. The purpose of the EBDS is to dispatchthe sub-events originated in the detector front-end electronicsto the processors of the Event Filter Farm, where the fullevents are assembled.For the design of the EBDS, we use the Real-time Object-Oriented Modeling method (ROOM), which was chosenbecause of its powerful modeling paradigm, well suited to thistype of application. The use of ROOM is aided by theObjecTime Developer tool set, which fully supports themethod and covers all the aspects of the development cycle,from analysis to code generation. Fast prototyping andsimulation bring a new perspective to the designer, who canadvance by gradual refinements.We describe how ROOM has been used to design a modelof both the EBDS and its environment, and the resultsobtained from the simulation. We also review the experienceacquired with ROOM and the ObjecTime tool, and indicatewhat benefits and obstacles we encountered.I.  INTRODUCTIONThe ALICE experiment [1] will be performed at the LHCmachine, currently under construction at CERN. The purposeof the experiment is the study of the quark–gluon plasmacreated in high-energy nuclear collisions. The ALICE detectoris specialized in the detection of heavy-ion nucleus–nucleusinteractions.The ALICE data-acquisition (DAQ) architecture is basedon parallel streams of data, as shown in Figure 1. L2 TriggerPDSGDCGDCGDC GDCSwitch EDMLDC LDC LDC LDC LDCTimeProjectionChamberInnerTrackingSystemPhotonSpectrometerRORCRORCRORCFEDCFEELDCParticleIdentificationDDLEBLL1 TriggerTDLSwitchSTLBusyClearFEEFEEFEEFEEPDS PDS PDSMuonTrackingChambersRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCRORCFEDC FEDC FEDC FEDC FEDCFCLL0 TriggerFEEFEEFEEFigure 1: ALICE data-acquisition architectureThe data generated in the detector are transferred throughabout a hundred optical links. The data are received in theFront-End Digital Crates (FEDC) by the Read-Out ReceiverCards (RORC), which are buffer memories capable of storingseveral fragments of events. The Local Data Concentrators(LDC) in the FEDC are embedded processors that collect theevent fragments and construct the sub-events, which are thensent over the network to one of the Global Data Collectors(GDC). The GDCs are processors as well: their role is to puttogether all the sub-events, build the full events and send themto the recording system. The GDC will also have analysis,filtering and storage functions.The expected data rates are about 100 Mbyte/sec on eachof the parallel streams, for an aggregate bandwidth of2.5 Gbyte/sec.The network linking LDCs and GDCs is based on widelyused standards and off-the-shelf commercial components. Weexpect the performance of the Local Area Networktechnology available in 2005 (startup of the experiment) to beadequate to our requirements and affordable.II.  EVENT BUILDING AND DISTRIBUTION SYSTEMThe problem of building events is always present in data-acquisition systems with parallel streams of data. The sub-events coming from different machines must be transferred toa place where the full event can be assembled. In the ALICEdata-acquisition architecture there is not a single object thatcan be identified as the event builder [2]. The responsibilityfor building the events is rather distributed among severalprocessors and processes. The LDCs send the sub-events of agiven event to the same GDC. The network links all themachines together, thus allowing all the GDCs to be accessedby all the LDCs (see Figure 2).Local Data Concentrator(LDC)Global Data Collector(GDC)NetworkLocal Data Concentrator(LDC)Local Data Concentrator(LDC)Local Data Concentrator(LDC)Event DestinationManager (EDM)Figure 2: Interconnections between LDCs, GDCs and EDMHowever, as far as the event building is concerned, thenetwork has only a passive role, which consists of dispatchingthe sub-events to their destination. The decision on thedestination is made elsewhere, in the way described below.A process called Event Destination Manager (EDM)maintains a list of available GDCs and periodically sends it tothe LDCs. The GDCs inform the EDM of their availability,according to their load. The LDCs use the list of availableGDCs to establish the event destination. Each GDC list has ascope of validity referred to a range of event numbers. All thecomponents of the EBDS process are synchronized throughthe event number.The EBDS as a whole provides the following functions:x Synchronization of the LDCs on the choice of thedestination GDC.x Back pressure from the GDCs to the LDCs in case ofGDC congestion.We are confronted here with a system that has thefollowing features:x There are real-time constraints, since it is necessary tokeep up with the data flow.x It involves inter-process communication and theestablishment of transactions protocols.x The algorithm used to determine the choice of thedestination contains some heuristic elements.All these features suggest that it is important to make asimulation of the system during the design phase.Furthermore, it would not be easy to adapt a hard-wiredimplementation to all the possible parameters and algorithmsthat we want to test. We therefore made, in 1997, a study ofseveral major software design methods [3].III.  THE CHOICE OF ROOM AS DESIGN ANDSIMULATION METHODWe eventually chose ROOM [4]. The aspects of ROOMthat appeared to us particularly attractive are the following:x The development process is based on the creation and thegrowth of models. The models capture our requirementsand our view of the expected behavior. A fully-grownmodel eventually behaves as the target system, and ittherefore becomes the system.x The operational approach eliminates semanticdiscontinuities. There is a single set of modelingabstractions that are used throughout the developmentprocess, from analysis to design and implementation.x A tool set exists (ObjecTime Developer [5]), whichsupports all the features of the method. In particular itprovides:x A simulation run-time system that allows evenincomplete models to be executed. This fosters anincremental and iterative development process andfast prototyping.x Code generation in C++.x A target run-time system where the developedapplication can run. The tool provides the visibilityof the target process. Many platforms and operatingsystems are supported.x There were indications of a convergence between ROOMand the Unified Modeling Language (UML) [6]. TheUML was going to adopt ROOM to extend its formalismto real-time processes.IV.  THE ROOM PARADIGMSROOM is a method specific to the real-time domain,designed to handle the concepts of timeliness, dynamicstructure of objects, reactiveness, concurrency anddistribution.The main paradigm used in the ROOM models is that ofactive objects, called actors, which communicate among themby exchanging messages (called signals).The ROOM developer may use two distinct abstractionlevels in his model, for which two different notations will beused:x The schematic level, which uses the ROOM graphiclanguage.x The detailed level, in which a traditional programminglanguage may be used, such as C++.A ROOM model may be developed and made to growalong three independent dimensions:x The structure, which represents the static topologicalaspects of the system. It describes the system componentsand their relationships in term of communication (portsand bindings) and containment (actor decomposition).The representation is made by graphs, as shown inFigure 3.Figure 3: Structural view of a modelx The behavior, which represents the dynamic aspects ofthe system. It describes how the system changes overtime. The representation is made by finite-state machines,as shown in Figure 4.Figure 4: Behavioural view of a modelx The inheritance, which represents the class hierarchy. Itconcerns the classes rather than the instantiated objects. Itallows abstraction and re-use of models.V. THE EBDS ROOM MODELA ROOM model of the EBDS has been made using theObjecTime tool set. It consists of two distinct parts.The first part, called the EBDS environment, constitutesthe simulation environment  used to test the EDM. It  includesa trigger generator, a number of LDCs and a number ofGDCs. The trigger generator sends triggers to a number ofLDC actors. The LDCs generate events and dispatch them tothe GDCs. The LDCs contain three actors: the eventgenerator, the event dispatcher and the event sender. Thedecision on where to send the event is taken by the dispatcher.The second part is the EDM itself. It is made of an actorthat keeps track of the status of the GDCs and periodicallyupdates a status table. The update of the tables demandssynchronization between the EDM and the event dispatchersin the LDCs.The model has been built and then exercised in simulationmode. It has revealed a number of defects in the protocol,which have been rectified.Currently, we have split the model, leaving the EDMseparated from the EBDS environment. The environmentcontinues to run in simulation mode, while the EDM runs intarget mode on a remote machine, as a normal application.Therefore, we now have a powerful tool that allows us to testalgorithms and system performance.VI.  EXPERIENCE WITH ROOM AND OBJECTIMEWe have used the ROOM method with the ObjecTime toolset for several months, over the last two years, to design andsimulate an application of sizeable dimension.The whole idea to work on a model from the verybeginning, and to be able to execute the model - even ifpartially developed - is extremely attractive, especially in thefield of high-energy physics data-acquisition systems. In adevelopment environment, where the requirements are oftenfuzzy and change occasionally, the possibility to work ongraphical models and to make prototypes at an early stage isvery welcome.A.  Strong pointsThe ROOM paradigms confirmed that they are extremelypowerful to make models in a well-defined domain ofapplication, namely the real-time domain. We do not thinkthat ROOM could be applied to other domains (e.g. physics-event reconstruction or analysis): this is not the ambition ofthe ROOM authors either.The only slight inconsistency in the language, if any, is thefact that incoming and outgoing signals belong to differentabstraction levels. While incoming messages are implicitlyprocessed at the schematic level, when they trigger a statetransition, outgoing signals must be explicitly generated in thecode at the detailed level.The ObjecTime toolkit is well made. It covers all theaspects of ROOM and gives access to all the features of thegraphical language. The notation used matches exactly the onedescribed in the manifesto book [4]. Due to the inherentcomplexity of ROOM, the notation is quite complicated andsometimes difficult to master.The toolkit is very robust, even though it happened tocrash or hang occasionally.The toolkit provides a lot of facilities to manage themodels in a collaborative team environment. Parallelconcurrent versions (called updates) may be developed from acommon baseline (called context). Eventually, various updatesmay be merged into a new context. Each user owns aworkspace that preserves his own window configuration andany other settings he/she may have established.The simulation environment is very powerful. It gives a lotof visual hints of the course of model execution. It allowssetting of break-points and trace-points, and enteringmessages on a logbook. It is possible to inspect variables andalmost all the aspects of the simulated model.B.  Weak points in target modeThe target mode gives the same sort of facilities as thesimulation mode; unfortunately a  model that runs happily inthe simulation run-time system (SimulationRTS) is notguaranteed to run as well in the target run-time system(TargetRTS). Sometimes the tool crashes when using theTarget Observability capability if the model contains errorsand the application loses contact with the tool.In order to run on distributed systems, models must besplit by hand. Separated models must be built for each targetprocessor.The bindings between actors running on different targetsmust be converted into a special kind of communication calledservice access/provision point (SAP/SPP). This is normallydedicated to interconnecting different logical layers of themodel. In other words, the communication between differenttarget processors is confined to the client/server paradigm.The implementation of SAP/SPP over TCP/IP sockets iscurrently limited to the exchange of textual messages (ASCII-encoded), which may be highly inefficient for bulk data.Moreover, there is a number of unfortunate inconsistenciesbetween the SimulationRTS and the TargetRTS that must betaken into account, such as the indexing of multipleinstantiated actors, differences in the routines for handlingsimulated time and real time, and different  time formats.Some visual hints change  when you run in TargetRTS, suchas the messages appearing in the inject port’s Trace window.C.  Other weak pointsThere are in ObjecTime a number of minorinconveniences, which do not seem to affect the overall goodimpression of the tool set; still, they make life a little morecomplicated for the designer. Here are a few of them.The original human interface is neither instinctive nor userfriendly. The use of buttons and menus in the windowdecoration is most unnatural. Things are a bit better since theyhave introduced the Microsoft Windows look and feel inversion 5.2 of the tool set.The tool set provides its own window management withinits main window. Windows are very widely used for anyentity you require to see; therefore, while you work, moreand more windows are stacked on top of one another.Unfortunately, the concepts of inheritance and containmentare not propagated to the windows; therefore, the user mustmanually close windows one by one in order to tidy up acluttered screen.There is no graphical indication of the status of SAPs andSPPs. Since SAPs and SPPs are necessary in a distributedenvironment, substantial features of the model do not appearin the graph, making it much less self-explanatory.The remnants of an early proprietary language (RPL)appear here and there. You are not expected to learn it, butyou cannot ignore it altogether, since some native classes aredefined using the RPL and this will affect the derived class.When inspecting the variables at run time, the RPL will cometo the surface again.The run-time error messages are often obscure, in bothworking modes.The built-in statistic tools available are rather poor.VII.  CONCLUSIONSWe have used ROOM and the ObjecTime toolkit for thedevelopment of the Event Builder and Distribution System ofthe ALICE experiment. We have found ROOM to be a usefuldevelopment method for projects having a strong real-timeconnotation. The paradigms adopted by ROOM are verypowerful to succinctly capture the features of the models.ObjecTime is a complete and robust development tool,notwithstanding some annoying awkwardness.  VIII. REFERENCES[1] ALICE collaboration, Technical Proposal, CERN/LHCC95-71, 1995.[2] H. Beker, W. Carena, R. Divià, P. Vande Vyvre, A.Vascotto, ALICE Event Building and Distribution System- User Requirements Document, ALICE internal noteINT-96-10, 1996.[3] M. Macowicz, ALICE Data Acquisition System Control:Assessment of methods and tools for the development,ALICE internal note INT-98-02, 1998.[4] B. Selic, G. Gullekson, P. T. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994.[5]  ObjecTime User Guide, ObjectTime Limited, 340 MarchRoad, Kanata, Ontario, Canada K2K 2E4.[6] J. Rambaugh, I. Jacobson, G. Booch, The UnifiedModeling Language Reference Manual, Addison-Wesley,1999.

Use of ROOM in the design of data-acquisition software components

Abstract

Similar works

Full text

Available Versions

CERN Document Server