ECAL Trigger and Readout Software architecture/integration

1. ECAL Trigger and Readout Software architecture/integration • Contents: • 1. Proposal for the Trigger and Readout Software • Architecture • An example of message flow for a Global Run • An example of message flow for a Local Run • List of ECAL DAQ items to be covered for running the detector in 2007 • 5. Conclusions R. Alemany (LIP) Session: Software Architecture

2. Device Error Handlers ECAL Error Handler 1. Proposal for the Trigger and Readout Software Architecture RCMS V2 ECAL Error Handler Data integrity and data quality ORACLE MySQL XML TCC Error Handler TCC Supervisor DB Manager XDAQDataStore DCC Error Handler ECAL Supervisor Local Trigger Supervisor DCC Supervisor LTS Error Handler SpyEvents (VME DCC RO) CCS Supervisor TTC Supervisor Laser Supervisor i2o CCS Error Handler SRP Supervisor Custom EVB i2o SRP Error Handler MATACQ Supervisor i2o Monitoring Farm Supervisor XDAQ V3 - Local Trigger: CCS (mezzanine) trigger card; H4 scintillator trigger system; etc • MATACQ: special readout and fast pulse analyzer for laser width and intensity measurements • to correct the laser lamp degradation with time.

3. 1. Proposal for the Trigger and Readout Software Architecture • ECAL Supervisor is the brain of the system. It is, however, an empty brain until it gets all the information from the DB. • ECAL Supervisor is the interface between the RCMS and the ECAL Trigger and Readout system. It dispatches RC Commands to the Device Supervisors, and it receives states from the Device Supervisors. It propagates the overall status to the RCMS. • Device Supervisor is the interface between the ECAL Supervisor and the Device Drivers. • Device Supervisor implements the state machine of the corresponding device. • Whenever is possible, errors are handled (a la XDAQ) by the corresponding Device Error Handler. If the error cannot be solved at this level, it gets propagated to the ECAL Error Handler and, if cannot be solved there, then it is reported to the RCMS error handler system. R. Alemany (LIP) Session: Software Architecture

4. 1. Proposal for the Trigger and Readout Software Architecture • If MATACQ has a way of receiving the TTC info, we could use the Central EVB (Event Builder). • If Calibration runs are performed out of Global runs, but under the responsibility of the shift crew, we should think about implementing a completely automatic procedure for it: RC gives the KEY, ECAL Supervisor takes care of the rest. An example is given later. • Device Supervisor state machine: The state of the Device Supervisor depends on the state of the OD devices it controls (max. 3). It maintains a state object (an instance of a DeviceState subclass) that represents the current state of the set of OD modules. DeviceState is an abstract class that represents the states of the devices. It declares an interface common to all classes that represent different devices operational states. Subclasses of DeviceState implement state-specific behavior: DCCIdle, DCCReady, DCCOutOfSync, etc. The software puts all the behavior associated with a particular state into one of those objects. Because all state-specific code lives in a concrete state subclass, new states and transitions can be easily added by defining new subclasses. When a Device Supervisor object receives requests from other objects, it responds differently depending on its current state. R. Alemany (LIP) Session: Software Architecture

5. DCCSupervisor Implements the Interface between ECALSupervisor and the DCC driver xdaq::Application DeviceState Configure() Start() Stop() Resync() Reset() Clear() ReadStatusRegisters() ReadErrorRegisters() ChangeState() DCCReady Stop() ReadStatusRegisters() ReadErrorRegisters() DCCIdle Configure() Start() DCCOutOfSync Resync() DCCError Reset() 1. Proposal for the Trigger and Readout Software Architecture Abstract class that represents the states of the devices. It declares an interface common to all classes that represent different devices operational states. Subclasses of DeviceState implement state-specific behavior. DCCBusy

6. TCCSupervisor Implements the Interface between ECALSupervisor and the TCC driver xdaq::Application DeviceState Configure() Start() Stop() Resync() Reset() Clear() ReadStatusRegisters() ReadErrorRegisters() ChangeState() TCCReady Stop() ReadStatusRegisters() ReadErrorRegisters() TCCIdle Configure() Start() TCCError Reset() 1. Proposal for the Trigger and Readout Software Architecture Because all state-specific code lives in a concrete state subclass, new states and transitions can be easily added by defining new subclasses.

7. ORACLE MySQL XML DB Manager XDAQDataStore Configure (KEY) Partition Configuration & Run_Type (PC&RT) KEY Configure (PC&RT specific for DEVICE) DEV_READY SRP_READY 1. Plug&Play (6U VME64x) 2. Compare Plug&Play info with DB info* 3. If (step 2 OK) build devices 4. If (devices successfully built) Configure SRP 2. An example of message flow for a Global Run: Configure RCMS V2 ECAL Supervisor ECAL Error Handling Device* Supervisor SRP Supervisor Device Error Handling SRP Error Handling 1. Plug&Play 2. Compare Plug&Play info with DB info** 3. If (step 2 OK) build devices 4. If (devices successfully built) Configure CCS & FE * Device = CCS, DCC, TCC ERROR ** Mainly check SERIAL_NUMBER, otherwise BUILD_DEVICE table is not valid.

8. Data integrity and data quality monitoring Start Conditions DB DCC_RUNNING TCC_RUNNING SpyEvents SRP_RUNNING (VME DCC RO) 2. An example of message flow for a Global Run: Start RCMS V2 DB Manager ECAL Supervisor DCC Supervisor CCS Supervisor TCC Supervisor SRP Supervisor R. Alemany (LIP) Session: Software Architecture

9. Configure KEY (STD_CALIBRATION) Configure (PC&RT specific for DCC and for S1-C1) Partition Configuration & Run_Type (PC&RT) Configure (PC&RT specific for LTS and for S1-C1) Configure (PC&RT specific for CCS and for S1-C1) Configure (PC&RT specific for MF and for S1-C1) 3. Local Run Run_type = STD_CALIBRATION, Sequence 1 (S1): STD_PEDESTAL  3 cycles (one per gain) (C1-C3) Sequence 2 (S2): STD_LASER  4 cycles (2 λ x 2 ½ SM) (C1-C4) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor - Number of LA1 - t between LA1 - Delay Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

10. DCC_READY LTS_READY CCS_READY 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

11. Data integrity and data quality monitoring DCC_RUNNING Start Start LTS_RUNNING SpyEvents (VME DCC RO) i2o 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

12. Data integrity and data quality monitoring Stop DCC_READY CYCLE_FINISHED (after all LA1 fired) SpyEvents (VME DCC RO) 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

13. Data integrity and data quality monitoring Configure (RT specific for DCC and for S1-C2) Configure (RT specific for LTS and for S1-C2) Configure (RT specific for CCS and for S1-C2) SpyEvents (VME DCC RO) Configure (PC&RT specific for MF and for S1-C2) 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor - Number of LA1 - t between LA1 - Delay Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

14. Data integrity and data quality monitoring DCC_READY LTS_READY CCS_READY SpyEvents (VME DCC RO) 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Monitoring Farm Supervisor Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

15. Data integrity and data quality monitoring DCC_RUNNING Start Start LTS_RUNNING SpyEvents (VME DCC RO) i2o 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

16. Data integrity and data quality monitoring Stop DCC_READY CYCLE_FINISHED (after all LA1 fired) SpyEvents (VME DCC RO) i2o 3. Local Run: sequence = std_pedestal, 3 cycles (one per gain) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor … and so on so for … Monitoring Farm Supervisor In this example, LTS controls the trigger (mezzanine) card of CCS R. Alemany (LIP) Session: Software Architecture

17. Data integrity and data quality monitoring Configure (RT specific for DCC and for S2-C1) Configure (RT specific for LTS and for S2-C1) Configure (RT specific for CCS and for S2-C1) Configure (RT specific for Laser and for S2-C1) SpyEvents (VME DCC RO) Configure (RT specific for MF And for S2-C1) 3. Local Run: sequence = std_laser, 4 cycles (2 λ x 2 ½ SM) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Laser Supervisor MATACQ Supervisor • Configure for Laser is a two steps command: • Set Laser Parameters • Get Laser Parameters and Pulse Info • (for confirmation) Monitoring Farm Supervisor R. Alemany (LIP) Session: Software Architecture

18. Data integrity and data quality monitoring DCC_READY CCS_READY LTS_READY SpyEvents LASER_READY (VME DCC RO) 3. Local Run: sequence = std_laser, 4 cycles (2 λ x 2 ½ SM) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Laser Supervisor MATACQ Supervisor Monitoring Farm Supervisor R. Alemany (LIP) Session: Software Architecture

19. Data integrity and data quality monitoring Start Start DCC_RUNNING LTS_RUNNING SpyEvents (VME DCC RO) i2o i2o i2o 3. Local Run: sequence = std_laser, 4 cycles (2 λ x 2 ½ SM) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Laser Supervisor Custom EVB MATACQ Supervisor Monitoring Farm Supervisor R. Alemany (LIP) Session: Software Architecture

20. Data integrity and data quality monitoring CYCLE_FINISHED SpyEvents (VME DCC RO) i2o i2o i2o 3. Local Run: sequence = std_laser, 4 cycles (2 λ x 2 ½ SM) RCMS V2 OR LOCAL RC? ORACLE MySQL XML DB Manager XDAQDataStore ECAL Supervisor DCC Supervisor Local Trigger Supervisor CCS Supervisor Laser Supervisor Custom EVB MATACQ Supervisor … and so on so for … Monitoring Farm Supervisor R. Alemany (LIP) Session: Software Architecture

21. 4. List of ECAL DAQ items to be covered for running the detector in 2007 • 1. DCC-CCS-TCC-SRP Software integration. (on going) • 2. TTC integration. (software provided centrally,coming in the next months) • 3. TRG&RO Software – RCMS integration. (to be done) • 4. TRG&RO Software – RCMS – DCS integration. (to be done) • 5. Monitoring: based on the On-Line Monitoring Infrastructure • (OMI) and COSINE. ECAL should provide the following monitoring • applications based on this Software Requirements Specification: • Device error counters and status registers monitoring. • DCC data integrity monitoring (Trigger Towers, Trigger • Primitives, SRP flags). • SLB Synchronization histograms processing. • TPG quality checking histograms. • Xtal data quality monitoring (pulse shape distributions, phase • monitoring). • 6. Local DAQ definition. (on going) • 7. Data base: equipment, construction, configuration, conditions. (on going) • 8. TTC/TTS partitioning. (to be done) Lot of work already done (DCC, SLB, TCC). Post Doc (Milan) recently joint to work on the GUI and histograms/ tables definition OMI: TriDAS Software Requirements Specification On-Line Monitoring Infrastructure Version 2.1 (29 Jul 04) by J. Gutleber.

22. 5. Conclusions • We should pursue a software development that profits from all the available Central tools. • Lot of work still to be done, but we are achieving a good understanding of our needs. • This year is our milestone to get the software ready. Then, later developments will be done with the spirit of achieving better and better software in terms of stability, performance, scalability and maintenance. • ECAL Databases are not an issue anymore. • ECAL Monitoring won’t be an issue soon. • We are many people working for the ECAL software: M. Cerutti, P. Paganini, J. Gilly, at least 2 people from CEA/Saclay (SRP), E. Vlassov, N. Almeida, P. Musella, A. Ghezzi, R. Alemany. And we count on the help from Central DAQ group and J. Bourotte. R. Alemany (LIP) Session: Software Architecture

23. Dynamic Software Configuration:Run Type Configuration In the RUN_TYPE table I have already specified that DCC ZSupression and SReadout are disable for this run. TRIGGER_ CONFIG_ID … … … … … … … … … …

24. 1. Trigger and Readout Software Architecture: error/exception handling (XDAQ)(notes taken from L. Orsini talk at OLSWG CMS Week 150305) • XDAQ provides tools for: • - error detection • - error notification • - error reporting • Errors/exceptions can be • detected in a particular portion • of code • - either the exception is handled • and recovered locally • - or the exception must be • notified to an external entity • for handling • - finally an exception that cannot • be handled is reported to the user • Errors/exceptions handling use cases: • - single thread, synchronous • - multi-threads, asynchronous • - multi-processes, synchronous • - multi-processes, asynchronous • Programming approaches: • - single thread, synchronous • try{…} catch() {…} • - multi-thread, asynchronous • error processor and callback pattern • - multi-processes, synchronous • SOAP call with Fault reply • - multi-processes, asynchronous • error notification message • An error/exception is characterized by: • - an identifier (What has happened) • - an originator (Who and where) • - a time (When) • - the context ( Who is in charge of • handling)

25. 1. Trigger and Readout Software Architecture: error/exception handling (XDAQ) • Uniform error message format: • - error schema already proposed for exchanging error messages • among CMS users • - schema can be mapped to SOAP (currently), i2o (will follow), • combined used of different transports (future) • - Format: • => Compulsory information: identifier, notifier, date/time • and context • => Optional: severity, message (open format), recursive • definition for nested errors and multiple error • collection • Support for qualified error (user defined schema) • - Possibility to plug a user defined errors, e.g Tracker, ECAL, RC, XDAQ, etc. • - Capability to use other industry standard formats e.g CBE by IBM

26. 1. Trigger and Readout Software Architecture: error/exception handling (XDAQ)

27. 1. Trigger and Readout Software Architecture: error/exception handling (RCMS)(notes taken from F. Lelli talk at OLSWG CMS Week 150305)

28. TDC Pending issues • 867: • Timing (TDC) EVB needed for TDC and DCC. • Monitoring to get pedestals and timing: • Most likely Alessio work will not be ready for 867; • Back up solution: H4 monitoring program. • H4: • Who will develop the Local Trigger Supervisor for H4, to take into account the scintillators? • How the EVB of the DCC and Trigger data will be done? • DCU (CCS) Supervisor: • Who is going to develop this application? • Where the DCU data will be analysed: @XDAQ side, @DCS side? • How the data will be analysed? • How the data will be shipped to DCS? R. Alemany (LIP) Session: Software Architecture

29. Pending issues • P5 surface installation: • How will be the flying DAQ in terms of hardware and software? R. Alemany (LIP) Session: Software Architecture