1 / 14

Run Control and Conditions DB

Run Control and Conditions DB. CMS CPT Week, CERN 18 April 2002 G. Maron INFN – Laboratori Nazionali di Legnaro. Run Control and Monitor System. The Run Control and Monitor System (RCMS) provides the user interface to the CMS DAQ. RCMS main tasks:

saxton
Télécharger la présentation

Run Control and Conditions DB

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Run Control and Monitor System • 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 Trigger UI Event Builder Internet Intranet Event Filter RCMS RCMS UI UI DCS Computing Services UI RCMS Context

  3. RCMS Logical Layout UI UI 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 RCMS Session Manager Services Sub-System Controller Sub-System (Daq)Resources

  4. RCMS Block Diagram Security Service UserDB ConfDB Resource Service • 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 UI Info&Mon Service LogDB UI Session Manager UI Services Connection Run Bkkpng Job Ctrl Problem Solver Sub-System Controller RCMS Sub-System (Daq)Resources

  5. Session Manager and Sub-Systems UI UI UI RCMS Session Manager Services Services Services Connection EVB Ctrl TRG Ctrl CS Ctrl DCS Ctrl EVF Ctrl RU Builder FED Builder Mu Cal Glbl TRG Sub-System EVF Sub-System EVB Sub-System DCS Sub- System CS Sub- System

  6. Sessions example UI UI UI UI UI UI RCMS Services Session Manager-B Session Manager-A Services Services Connection EVB Ctrl TRG Ctrl CS Ctrl DCS Ctrl EVF Ctrl RU Builder FED Builder Mu Cal Glbl TRG Sub-System EVF Sub-System EVB Sub-System DCS Sub- System CS Sub- System

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

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

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

  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. A step forward Resource Service Security Service Info&Mon Service Job Ctrl UI UI Session Manager GUI Session Manager Problem Solver Sub-System Ctrl Servlet Containers = web services DataMover Service UDDI DCS GTW Service WSDL SOAP 2 1 Conditions DB Srvc Event Ctlg Srvc WebCam Service Sub-System XDAQ Resources • Clients looking for services, query first the UDDI server to discover the location of the service and then access to it • 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

  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 Events DB Calib. const. geometry Detectors Evnt Ctlg DB Conditions DB Trigger Run Conditions Rec. Prog. DAQ "run number" 25 (from t1 to t2)

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

  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

More Related