1. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 1 ECAL Trigger and Readout Software architecture/integration Contents: 1.Proposal for the Trigger and Readout Software Architecture 2.An example of message flow for a Global Run 3.An example of message flow for a Local Run 4.List of ECAL DAQ items to be covered for running the detector in 2007 5.Conclusions

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

3. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 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.

4. 08/04/05 OFF-Detector Workshop Electronics 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.

5. 08/04/05 OFF-Detector Workshop Electronics 5 1. Proposal for the Trigger and Readout Software Architecture DeviceState Configure() Start() Stop() Resync() Reset() Clear() ReadStatusRegisters() ReadErrorRegisters() ChangeState() DCCIdle Configure() Start() DCCReady Stop() ReadStatusRegisters() ReadErrorRegisters() DCCBusy DCCOutOfSync Resync() DCCError Reset() DCCSupervisor Implements the Interface between ECALSupervisor and the DCC driver xdaq::Application 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.

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

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

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

9. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 9 - Number of LA1 -  t between LA1 - Delay 3. Local Run RCMS V2 OR LOCAL RC? DCC Supervisor CCS Supervisor Local Trigger Supervisor ECAL Supervisor Monitoring Farm Supervisor Configure KEY (STD_CALIBRATION) DB ManagerXDAQDataStore ORACLE MySQL XML Partition Configuration & Run_Type (PC&RT) Configure (PC&RT specific for DCC and for S1-C1) Configure (PC&RT specific for CCS and for S1-C1) Configure (PC&RT specific for LTS and for S1-C1) In this example, LTS controls the trigger (mezzanine) card of CCS 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) Configure (PC&RT specific for MF and for S1-C1)

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

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

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

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

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

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

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

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

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

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

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

21. 17/01/0521 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) OMI: TriDAS Software Requirements Specification On-Line Monitoring Infrastructure Version 2.1 (29 Jul 04) by J. Gutleber. 4. List of ECAL DAQ items to be covered for running the detector in 2007 Lot of work already done (DCC, SLB, TCC). Post Doc (Milan) recently joint to work on the GUI and histograms/ tables definition

22. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 22 5. Conclusions 1.We should pursue a software development that profits from all the available Central tools. 2.Lot of work still to be done, but we are achieving a good understanding of our needs. 3.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. 4.ECAL Databases are not an issue anymore. 5.ECAL Monitoring won’t be an issue soon. 6.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.

23. 23 Dynamic Software Configuration: Run Type Configuration SEQUENCE SEQUENCE_IDSEQUENCE_ DESCRIPTION RUN_TYPE_IDNUMBER_ OF_CYCLES STD_PEDESTALstringSTD_CALIBRATION3 STD_LASERstringSTD_CALIBRATION4 SCAN_MEM_TEST_PULSEstringSCAN_MEM SCAN_LASER_POWERstringSCAN_LASER_POWER CYCLE SEQUENCE_IDCYCLE_IDCYCLE_ DESCRIPTION LASER_CONFIG_IDCCS_CONFIG_IDDCC_CONFIG_ID STD_PEDESTALVFE_GAIN_1stringemptyMGPA_GAIN_1may be empty STD_PEDESTALVFE_GAIN_6stringemptyMGPA_GAIN_6may be empty STD_PEDESTALVFE_GAIN_12stringemptyMGPA_GAIN_12may be empty STD_LASERWAVELENGHT_BLUE_1stringSTD_LASER_BLUE_1FIRST_HALF_SM STD_LASERWAVELENGHT_BLUE_2stringSTD_LASER_BLUE_2SECOND_HALF_SM STD_LASERWAVELENGHT_RED_1stringSTD_LASER_RED_1FIRST_HALF_SM STD_LASERWAVELENGHT_RED_2stringSTD_LASER_RED_2SECOND_HALF_SM SCAN_MEM_TEST_PULSESCAN_MEM_TEST_PULSE_0- 600 stringmay be emptySCAN_MEM_PN_GAIN_16may be empty SCAN_MEM_TEST_PULSESCAN_MEM_TEST_PULSE_0-5stringmay be emptySCAN_MEM_PN_GAIN_1may be empty SCAN_LASER_POWERSCAN_LASER_POWER_0-99stringSCAN_LASER_POWER may be empty LASER_CONFIGURATION LASER_CONFIGURATION_IDPOWER_SETTINGWAVELENGHTOPTICAL_SWITCH STD_LASER_CONFIG80440? STD_LASER_BLUE_1DEFAULT_VALUE4401 STD_LASER_BLUE_2DEFAULT_VALUE4402 STD_LASER_RED_1DEFAULT_VALUE7091 STD_LASER_RED_2DEFAULT_VALUE7092 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) 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 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) XDAQ provides tools for: - error detection - error notification - error reporting 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

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. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 28 Pending issues 867: 1.Timing (TDC) EVB needed for TDC and DCC. 2.Monitoring to get pedestals and timing: Most likely Alessio work will not be ready for 867; Back up solution: H4 monitoring program. TDC H4: 1.Who will develop the Local Trigger Supervisor for H4, to take into account the scintillators? 2.How the EVB of the DCC and Trigger data will be done? DCU (CCS) Supervisor: 1.Who is going to develop this application? 2.Where the DCU data will be analysed: @XDAQ side, @DCS side? 3.How the data will be analysed? 4.How the data will be shipped to DCS?

29. 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 29 Pending issues P5 surface installation: 1.How will be the flying DAQ in terms of hardware and software?