Data acquisition, control and monitor · 2019. 6. 19. · S.C. CMS-TriDAS RCS: Data Acquisition Systems Based on the CMS online software framework (XDAQ, RCS) and commercial products

Data acquisition, control and monitorData acquisition, control and monitor

S. Cittolin CERN/EP-CMDJCOP workshop 5-6 June 2002

Overview

Controls in CMS

Subsystems summary

CMS specific and general issues

Conclusion

S.C. CMS-TriDAS 5-juin-02 2

DAQ requirements and design parametersDAQ requirements and design parameters

Crossing rate 40 MHz

Event size ~ 1 MbyteDetector Channels Control Ev. Data (bytes)Pixel 60000000 1 GB 50000Tracker 10000000 1 GB 750000Preshower 145000 10 MB 50000ECAL 85000 10 MB 100000HCAL 14000 .1 MB 50000Muon DT 200000 10 MB 10000Muon RPC 200000 10 MB 5000Muon CSC 400000 10 MB 90000Trigger 1 GB 16000

Max LV1 Trigger 100 kHzReadout network 1 Terabit/sHigh Level Trigger ~ 5 TeraFlop

Online rejection 99.9997%System dead time ~ %

Detectors


8-fold DAQ system8-fold DAQ systemD

ata

to S

urf

ace

DA

Q s

lice


Subsystems, TDR baseline design (MY-GE)Subsystems, TDR baseline design (MY-GE)

TPG Trigger Primitive GeneratorRTP Regional Trigger ProcessorLV1 Level-1 Trigger ProcessorGTP Global Trigger ProcessorTTC Timing, Trigger Control sTTS synchronous Trigger Throttle SystemaTTS asynchronous Trigger Throttle SystemFES FrontEnd SystemFED FrontEnd DriverFEC FrontEnd ControllerD2S Data to SurfaceRU Readout UnitBU Builder UnitFS Filter SubfarmEVM Event ManagerRM Readout ManagerBM Builder ManagerEVB Event BuilderRCN Readout Control NetworkBCN Builder Control NetworkCSN Computing Service NetworkDCN Detector Control networkDSN DAQ Service NetworkDCS Detector Control SystemRCS Run Control System

Dat

a to

Su

rfac

e

x 8

syst

ems

RU

Bu

ilder

Filt

er F

arm

s


Experiment controlsExperiment controls

Run Controls:Configure and operate all local/global data taking sessionsMonitor and protect the measurements and the data flow

Detector Controls:Setup and monitor the detectors and the environmentMonitor and protect the apparatus equipment

S.C. CMS-TriDAS

RCS: Data Acquisition SystemsBased on the CMS online softwareframework (XDAQ, RCS) and commercialproducts (DBs, SOAP, XML, e-tools etc.)-Run Control and Monitor-Local/Global DAQ systems-FrontEnd Electronics Configuration-Readout Electronics Configuration-PC clusters and applications control-Local/Remote Data Archive-Run Condition Data Base-Configuration Data Base

DCS: Classic ControlBased on industry standards (PLC,field buses, PVSS and JCOP tools)-Racks/Crates power-HV/LV supplies-Cooling and environment-Gas and fluids-Central supervision-Alarms, history data base-External system communication-Detector Securities

RCS and DCS main domainsRCS and DCS main domains

Detector specific monitoring tasksUser applications mainly based on XDAQ with direct interfaces withlocal/central DCS systems-On detector electronics sensors (temperatures, currents, …)-FrontEnd electronics test and commissioning procedures-Calibration (source, LED, Laser) sessions


Detector&equipment control (DCS systems)Detector&equipment control (DCS systems)

Detector subsystems-HV/LV-Fluids and environment-Cooling-Racks/Crates-Temperatures-Infrastructures-Test systems (Laser, LED,alignment camera etc..)

Detector securities (DSS)-Temperature-Gas-Radiation

Experiment supervision-DCS Resources handling-Alarm and loggings-History data base-External systemscommunication.

Supervisor structure etc.

TPG Trigger Primitive GeneratorRTP Regional Trigger ProcessorLV1 Level-1 Trigger ProcessorGTP Global Trigger ProcessorTTC Timing, Trigger Control sTTS synchronous Trigger Throttle SystemaTTS asynchronous Trigger Throttle SystemFES FrontEnd SystemFED FrontEnd DriverFEC FrontEnd ControllerD2S Data to SurfaceRU Readout UnitBU Builder UnitFS Filter SubfarmEVM Event ManagerRM Readout ManagerBM Builder ManagerEVB Event BuilderRCN Readout Control NetworkBCN Builder Control NetworkCSN Computing Service NetworkDCN Dtector Control networkDSN DAQ Service NetworkDCS Detector Control SystemRCS Run Control System


LOCAL (VME)

GL

OB

AL

Slin

k-64

Detector data taking (DAQ systems)Detector data taking (DAQ systems)

Local DAQ- VME/PCI FED data acquisition- Test beam DAQ systems- Test and Calibration readout- Online passive readoutGlobal DAQ- Main DAQ data streamRun Control and Monitor- Supervision of all data taking operations- DAQ resource and partition handling- Readout subsystems configuration- Data flow monitoring- DCS communication

CMS-TriDAS. 5-juin-02 9

Frontend Readout Systems


DAQ partitioning

TTC and Trigger partitions. The TTC system consists of 32 partitions accessing 32 unconnected sets of FEDs. TheGTP can handle concurrently up to 8 different combinations of the 32 TTC partitions. These combinations are calledtrigger or DAQ partitions and are identified by a trigger type.

For a given trigger type only the associated FEDs are fired. The event fragment assignation to DAQ slice by the FRLscan be programmed in two modes corresponding to the two main ways of implementing DAQ partitions in CMS.

TTC and Trigger partitions. The TTC system consists of 32 partitions accessing 32 unconnected sets of FEDs. TheGTP can handle concurrently up to 8 different combinations of the 32 TTC partitions. These combinations are calledtrigger or DAQ partitions and are identified by a trigger type.

For a given trigger type only the associated FEDs are fired. The event fragment assignation to DAQ slice by the FRLscan be programmed in two modes corresponding to the two main ways of implementing DAQ partitions in CMS.

Mode 1) FED-RU builder partition. TheFRL logic sends the event fragments to aDAQ slice according to a commonswitching rule using for example the BXnumber. The EVM of each DAQ slice,using the trigger type contained in the GTPrecord, broadcasts the read command onlyto the RUs associated to that trigger type.All active DAQ slices result partitioned inthe same way.

Mode 2) FED-DAQ slice partition. Eachset of FED-FRLs associated to a givenTTC partition (trigger type) is programmedto send the event fragments always to thesame DAQ slice. Moreover the FRL of theGTP is programmed to send the trigger infoto the DAQ slice associated with its triggertype. The receiving EVM is thenprogrammed to broadcast read commandsonly to the RUs subset corresponding tothe prefixed trigger type

Mode 1) FED-RU builder partition. TheFRL logic sends the event fragments to aDAQ slice according to a commonswitching rule using for example the BXnumber. The EVM of each DAQ slice,using the trigger type contained in the GTPrecord, broadcasts the read command onlyto the RUs associated to that trigger type.All active DAQ slices result partitioned inthe same way.

Mode 2) FED-DAQ slice partition. Eachset of FED-FRLs associated to a givenTTC partition (trigger type) is programmedto send the event fragments always to thesame DAQ slice. Moreover the FRL of theGTP is programmed to send the trigger infoto the DAQ slice associated with its triggertype. The receiving EVM is thenprogrammed to broadcast read commandsonly to the RUs subset corresponding tothe prefixed trigger type


FrontEnd configuration and monitorFrontEnd configuration and monitor

Detector specific systemsThe detector frontend systems include the access to the innerreadout electronics, the power regulators, the programmablelogics, the sensors to read currents, temperatures etc..Special requirements (radiation resistance, power,infrastructure, etc..) imposed detector specific solutions.

-Data links and interfaces-Programmable Logic (FPGA,..) controls-Sensors readout (separate or embedded with data path)-Calibration and test procedures

The configuration data set are often very large and thecollected data (temperature and currents) are datacomplementary of the measurement instead controlparameters. All Detector Safety Units make use of dedicatedand wired sensors


Frontend Control Systems


Pixel: Large configuration data sets. Hostile environment, continual reload of pixelthresholds. Security (temperature, radiation, LV)Tracker: Large configuration data sets. Important commissioning and testsessions. Hostile environment, continual resets and resynchronization. Security(temperature, cooling, radiation, LV)ECAL: Large data sets. Frequent calibration sessions. Detector control data(temperature, currents etc) accessible only via data path. Trigger linkssynchronization and local logic programming. Large number of monitoringparameters. Security (temperature, cooling, radiation, LV)HCAL: Frequent local calibrations (Source, Laser, LED), Custom power supplyEMU: Processing elements subject to radiation perturbation. Frequent logic andcode reload. Security (temperature, Gas, LV). Develop communication betweenlocal controller and PVSSDT: The same than EMU. Alignment Develop communication between cameracontroller and PVSS. Serial links for control access. Trigger links synchronizationand local logic download.RPC: Trigger links synchronization and local logic download.

Hardware: recommendation for common temperature and radiation (wired) sensorsPVSS communications generic : Instruments (GPIB), advanced data displayCMS specific : Detector controllers (FEC, processors, etc), Online software (XDAQ) PVSS -Data Bases interfacing: Experiment configuration, Run condition, Equipment History DB…..

Detector specific control issuesDetector specific control issues


Online software framework (CMS XDAQ and RCMS)-Local/Global DAQ systems-Local/Global Run Control-Detector specific electronics system configuration and monitoring-Job&Application control-Data taking monitoring and calibration-Local/Remote mass storage and data bases

DCS subsystem and supervision (PVSS and JCOP supported tools)-Classic detector slow control (Racks/Crates, HV/LV, Cooling, Gas, Security)-Generic DCS framework (exploiting industrial H/S implementations)-Experiment detector controls supervisory levels-Centralized functions (Alarms, History, Security)

Common features between the two systems:-XDAQ-PVSS interface (based on native PVSS API)-Access to external data bases for run conditions and experiment configurationboth from XDAQ and PVSS

Summary I. DAQ and DCS frameworksSummary I. DAQ and DCS frameworks


Summary II. DCS systems and PVSS in CMSSummary II. DCS systems and PVSS in CMS•DCS must be (TC point of view):-robust, versatile, maintainable and common between sub-systems-partitionable, scalable, configurable for different operating/shutdown conditions-able to seamlessly incorporate DSS available for the first sub-systems now for beam-tests/SX and in spring 2005 for UX. DSS able to function fully-independently of dataacquisition independent of custom software subject to frequent revision (or un-maintainable)•Continue JCOP support. PVSS MUST be used (by all subdetectors) for classical slowmonitoring & control of sub-detector environment and operating parameters gas & fluidflows,volts,temp, rack, crates etc(PVSS, will NOT be used : to control configuration of the front end electronics, to controlfarms and applications etc..)•Control of locally acquired (calibration or test) data (taken with standard front-endelectronics) has to be examined case by case (eg HCAL and TK are very different!problems) but, in general:both functions are the domain of the CMS custom DAQ (usingXDAQ framework and Run Control)•The PVSS - XDAQ interface will be supplied and maintained by the CMS DAQ group•Basic detector control MUST be able to operate independently of DAQ and maintain(among other states) a “ready for data-taking” condition. ….but...•Test beam and local DAQ systems are based on XDAQ and RCS. The recommendedtest-beam DAQ configuration provides a slow acquisition via VME-PCI and this provides thefunctionality in the final DAQ system of spying on the data-stream to extract monitoring data.(Near continuous local running to maintain fine control tuning & calibration could be a featureof operation periods). After local analysis, instructions for fine correction of operatingconditions can be passed to PVSS through the XDAQ - PVSS interface


•The JCOP framework should be delivered according to the agreedschedule and the maintenance of it’s components assured.

•Extension of framework to include HCAL HV power supply

•Since we consider PVSS to handle also non DCS alarms, the alarmhandling of PVSS would have to be improved/changed in a way whichallows this in terms of performance and alarm handling implementation

•The way the user interfaces are implemented in PVSS does not allowfor an easy integration with other user interfaces nor is it widely systemindependent. To achieve a uniform visualization a more openimplementation would be necessary

•Data presentation tools should be easily embedded in PVSS applications

•Since data storage in CMS will be based on databases, the databaseconnectivity of PVSS has to be improved to allow for an easy access ofPVSS data as well as a simple export of those

CMS JCOP/PVSS requirementsCMS JCOP/PVSS requirements

Documents

Data acquisition, control and monitor · 2019. 6. 19. · S.C. CMS-TriDAS RCS: Data Acquisition Systems Based on the CMS online software framework (XDAQ, RCS) and commercial products