1. Gaetano Maron, CPT week, CERN, 18 April 2002 1 Run Control and Conditions DB CMS CPT Week, CERN 18 April 2002 G. Maron INFN – Laboratori Nazionali di Legnaro

2. Gaetano Maron, CPT week, CERN, 18 April 2002 2 Run Control and Monitor System RCMS Internet Intranet Internet Intranet UI The Run Control and Monitor System (RCMS) provides the user interface to the CMS DAQ. RCMS main tasks: –configuring all the elements in the daq system –monitoring their performance –displaying the status of the daq components –identifying malfunctioning and provide recovery mechanism RCMS Trigger Event Builder Event Filter DCS Computing Services UI RCMS Context

3. Gaetano Maron, CPT week, CERN, 18 April 2002 3 RCMS Logical Layout UI Session Manager Services Sub-System Controller Sub-System (Daq)Resources RCMS UI RCMS is composed of 3 types of elements: –Session Managers –Sub-System Controllers –Set of Services Run Session –the hardware and software needed to operate a physics or test run with the entire or a partition of the CMS apparatus. Multiple Run Sessions may coexist and run concurrently Every activated run session has the own Session Manager that is in charge to: –handles comm. with the users have joined the session –handles comm. with the sub- systems via sub-system controller

4. Gaetano Maron, CPT week, CERN, 18 April 2002 4 RCMS Block Diagram SECURITY SERVICE (SS) –It provides login and authentication procedures to RCMS enabling data encryption when needed RESOURCE SERVICE (RS) –It manages the elements of the DAQ system: configuration of the components Session and Partition mngm Information and Monitor System (IMS) –It collects all the information originated from the sub-systems. Information is cataloged as: Messages: –Errors –Generic –Resource Status Change Monitor JOB CONTROL (JC) –It starts, monitor and kill the software infrastructure of the RCMS PROBLEM SOLVER (PS) –It uses the information provides by IMS to catch severe malfunctions of the apparatus and try to fix them Sub-System (Daq)Resources Security Service Resource Service Info&Mon Service Job Ctrl Problem Solver Sub-System Controller Services Connection Session Manager RCMS UI UserDB ConfDB LogDB Run Bkkpng

5. Gaetano Maron, CPT week, CERN, 18 April 2002 5 Session Manager and Sub-Systems Session Manager UI Services Connection Services Services EVB Ctrl CS Ctrl TRG Ctrl DCS Ctrl EVF Ctrl FED Builder CS Sub- System Glbl Mu Cal DCS Sub- System EVB Sub-System TRG Sub-System EVF Sub-System RCMS RU Builder

6. Gaetano Maron, CPT week, CERN, 18 April 2002 6 Sessions example Session Manager-A UI Services Connection Services Services EVB Ctrl CS Ctrl TRG Ctrl DCS Ctrl EVF Ctrl FED Builder CS Sub- System Glbl Mu Cal DCS Sub- System EVB Sub-System TRG Sub-System EVF Sub-System RCMS RU Builder Session Manager-B UI

7. Gaetano Maron, CPT week, CERN, 18 April 2002 7 RCMS prototype Internet XML - http Internet XML - http Sub-System XDAQ Resources Security Service Resource Service Info&Mon Service Job Ctrl Problem Solver Sub-System Ctrl XML/SOAP over http protocols Session Manager RCMS UI GUI UserDB ConfDB LogDB Run Bkkpng UI GUI Servlet Container Apache TomCat XML:DB + mySQL FSM XDAQ Adapter FSM

8. Gaetano Maron, CPT week, CERN, 18 April 2002 8 Resource Service Implementation Example Java Servlet Resource Service Servlet Java client XML XML:DB REL DB Java Objs XML Parser (Castor) XML Parser (Castor) C++ client XML Parser html client XML Parser http XML Resource Subscribing Handler Still alive heartbeat Session, Partition management Available Resources Partition Data Base Software Data Base New Node subscribe request ping all the Registered nodes Sessions, Partitions definition Session, Partition Setup Manual Resources Handler CONFIG DB

9. Gaetano Maron, CPT week, CERN, 18 April 2002 9 Information and Monitor System (IMS) Example Resource Status Change Message Logger (DB) State logger Monitor - History DB Message Filtering and Dispatcher Messages Monitor Info System State Display Error Statistics Alarm Display Monitor Systems Client Subscriber IMS Servlet XML:DB Filter Engine XPath based subscriber 1 subscriber n JAXM XML message Soap Message Client Subscriber XDAQ Nodes

10. Gaetano Maron, CPT week, CERN, 18 April 2002 10 XML:DB XML DBs represents a new technology to store XML documents pro: –Well defined API –No need to map XML schema to other data structures –A lot of flexibility through the semi-structured nature of XML. This is especially valuable when we have very complex XML structures that would be difficult or impossible to map to a more structured DB. con: –Performances Some benefits working with a RDBMS (XML:DB as interface, then automatic xml schema to relat. tables conversion). Characteristics –The server is accessible through easy to use HTTP and XML-RPC interfaces and supports the XML:DB API for Java/http programming. –the search engine supports Xpath (Xlink when available) queries. Links: –http://www.xmldb.org –http://exist.sourceforge.net –http://ozone-db.org –http://xml.apache.org/xindice News from Oracle9i Release 2

11. Gaetano Maron, CPT week, CERN, 18 April 2002 11 Problem Solver Info&Mon Service Resource Service A step forward Sub-System XDAQ Resources Security Service Job Ctrl Sub-System Ctrl Servlet Containers = web services SOAP Session Manager Session Manager UI GUI UDDI The single servlet container describes the services they offer by means of the Web Service Description Language (WSDL) and then publish it to the Universal Description Discovery and Integration (UDDI) registries Clients looking for services, query first the UDDI server to discover the location of the service and then access to it 1 2 WSDL DataMover Service DCS GTW Service Conditions DB Srvc Event Ctlg Srvc WebCam Service

12. Gaetano Maron, CPT week, CERN, 18 April 2002 12 Conditions DB Usually (e.g. Babar) Conditions DB is meant to store: –geometry, detector alignments –calibration constants –time dependent parameters, under which the experimental events are taken and that are necessary for the reconstruction and analysis of the raw data the stored conditions are time based (time stamp) –Babar has a resolution time of 1 second If we agree on the general principle that – all changes in any detector, daq or trigger components are logged at all times –only severe errors lead to stop the system (e.g. system efficiency less than X%) Then, the Conditions DB should also contains (at least pointers to) parameters describing the time behavior of the daq and the trigger systems –off-liners should be able to easily extract the needed view (detectors, daq, triggers) to reconstruct properly a given set of events, possibly using same API and same query languages Detectors Trigger DAQ Conditions DB Run Conditions geometry Calib. const. Events DB Evnt Ctlg DB Rec. Prog. "run number" 25 (from t1 to t2)

13. Gaetano Maron, CPT week, CERN, 18 April 2002 13 DT Chmbr Mini Crate ROS FED FRLC FED Builder RU EVM RU Bld BU EVF Allarms on det condts Trends Statistics TDC errs chip T buff ovfl alignment buff ovfl. alignment links status rates links status appl status perf x port error rate rates error rates buffer occup appl status rate error rate bufff occup appl status perf x port error rate Session Manager DCS Ctrl EVF Ctrl EVB Ctrl RUB Ctrl FEDB Ctrl rates rej rate appl status Run Condition errors, status, parameters over/under thrs, etc. Conditions DB Off-line DB Time StampCondition geometry calibration constants PVSS/EXT DB Information Service detector conditions daq&trigger conditions + monitor ? trigger conditions + monitor Run Conditions

14. Gaetano Maron, CPT week, CERN, 18 April 2002 14 Conclusions To avoid to stop the data taking when no severe errors occure, the online system has to track any changes in the run conditions set and make them available to the reconstruction procedures. A way to do this is to reflect these changes - in some way - in the conditions DB Data conversion procedure to map the online DB schemas to the Conditions DB schemas will be probably necessary In this context XML (and the associated XSLT) could play an important role So we are interested to: –understand how the conditions DB evolve (both in the data modelling and in the technologies) –share experiences in this filed with the offline group –agree on an effective architecture –setup testbeds and perform testbenches