ECAL Trigger and Readout Software architecture/integration

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 Run3. An example of message flow for a Local Run4. List of ECAL DAQ items to be covered for running

the detector in 20075. Conclusions


RCMS V2

DCC Supervisor

CCS Supervisor

Laser Supervisor

TCC Supervisor

TTC Supervisor

Local Trigger Supervisor

SpyEvents

DB Manager

ECAL Supervisor

(VME DCC RO)

XDAQDataStore

ORACLEMySQLXML

MATACQ Supervisor

Custom EVB

Monitoring Farm Supervisor

i2o

Data integrityand 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 HandlersECAL Error Handler

i2oi2o

- MATACQ: special readout and fast pulse analyzer for laser width and intensity measurements to correct the laser lamp degradation with time.

XDAQ V3



3


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


If MATACQ has a way of receiving the TTC info, we could use the CentralEVB (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 onthe 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


DeviceStateConfigure()Start()Stop()Resync()Reset()Clear()ReadStatusRegisters()ReadErrorRegisters()ChangeState()

DCCIdleConfigure()Start()

DCCReadyStop()ReadStatusRegisters()ReadErrorRegisters()

DCCBusy

DCCOutOfSyncResync()

DCCErrorReset()

DCCSupervisorImplements the Interface betweenECALSupervisorand 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


DeviceStateConfigure()Start()Stop()Resync()Reset()Clear()ReadStatusRegisters()ReadErrorRegisters()ChangeState()

TCCIdleConfigure()Start()

TCCReadyStop()ReadStatusRegisters()ReadErrorRegisters()

TCCErrorReset()

TCCSupervisorImplements the Interface betweenECALSupervisorand 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

2. An example of message flow for a Global Run: Configure

RCMS V2

ECAL Supervisor

Configure (KEY)DB Manager XDAQDataStore

ORACLEMySQLXML

Partition Configuration&

Run_Type (PC&RT)

KEY

Device* Supervisor

Configure (PC&RT specific for DEVICE)

1. Plug&Play2. 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

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)


monitoring Start ConditionsDB

DCC_RUNNING

TCC_RUNNINGSRP_RUNNING



9

- Number of LA1- t between LA1- Delay

3. Local Run

RCMS V2OR

LOCAL RC?

DCC Supervisor

CCS SupervisorLocal Trigger Supervisor

ECAL Supervisor


Configure KEY(STD_CALIBRATION)

DB Manager XDAQDataStore

ORACLEMySQLXML

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

3. Local Run: sequence = std_pedestal, 3 cycles (one per gain)

RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

DCC_READY

CCS_READY

LTS_READY




11


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

DCC_RUNNING LTS_RUNNING



monitoring


i2o

StartStart



12


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

CYCLE_FINISHED (after all LA1 fired)



monitoring


Stop

DCC_READY



13

- Number of LA1- t between LA1- Delay


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

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)



monitoring


Configure(PC&RT specific for MF

and for S1-C2)



14


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

DCC_READY

CCS_READY

LTS_READY




monitoring




15


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor


ORACLEMySQLXML



StartStart



monitoring


i2o



16


RCMS V2OR

LOCAL RC?

DCC Supervisor


ECAL Supervisor



ORACLEMySQLXML

CYCLE_FINISHED (after all LA1 fired)



monitoring


i2o

Stop

DCC_READY

… and so on so for …



17

3. Local Run: sequence = std_laser, 4 cycles (2 λ x 2 ½ SM)

RCMS V2OR

LOCAL RC?

DCC Supervisor




ORACLEMySQLXML


monitoring


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 Parameters2. Get Laser Parameters and Pulse Info

(for confirmation)

Configure(RT specific for MF

And for S2-C1)



18


RCMS V2OR

LOCAL RC?

DCC Supervisor




ORACLEMySQLXML


monitoring


DCC_READY

CCS_READY LTS_READY

Laser Supervisor

LASER_READY

MATACQ Supervisor

ECAL Supervisor



19


RCMS V2OR

LOCAL RC?

DCC Supervisor




ORACLEMySQLXML


monitoring


i2o

Start

Start

Laser Supervisor

MATACQ Supervisor

ECAL Supervisor

Custom EVB

i2o

i2o




20


RCMS V2OR

LOCAL RC?

DCC Supervisor




ORACLEMySQLXML


monitoring


i2o

CYCLE_FINISHED

Laser Supervisor

MATACQ Supervisor

ECAL Supervisor

Custom EVB

i2o

i2o … and so on so for …

17/01/05 21

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 monitoringapplications 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

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.

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

Dynamic Software Configuration: Run Type Configuration

SEQUENCE

SEQUENCE_ID SEQUENCE_DESCRIPTION

RUN_TYPE_ID NUMBER_OF_CYCLES

STD_PEDESTAL string STD_CALIBRATION 3

STD_LASER string STD_CALIBRATION 4

SCAN_MEM_TEST_PULSE string SCAN_MEM

SCAN_LASER_POWER string SCAN_LASER_POWER

CYCLE

SEQUENCE_ID CYCLE_ID CYCLE_DESCRIPTION

LASER_CONFIG_ID CCS_CONFIG_ID DCC_CONFIG_ID

STD_PEDESTAL VFE_GAIN_1 string empty MGPA_GAIN_1 may be empty



STD_LASER WAVELENGHT_BLUE_1 string STD_LASER_BLUE_1 FIRST_HALF_SM

STD_LASER WAVELENGHT_BLUE_2 string STD_LASER_BLUE_2 SECOND_HALF_SM

STD_LASER WAVELENGHT_RED_1 string STD_LASER_RED_1 FIRST_HALF_SM

STD_LASER WAVELENGHT_RED_2 string STD_LASER_RED_2 SECOND_HALF_SM

SCAN_MEM_TEST_PULSE SCAN_MEM_TEST_PULSE_0-600

string may be empty SCAN_MEM_PN_GAIN_16 may be empty

SCAN_MEM_TEST_PULSE SCAN_MEM_TEST_PULSE_0-5 string may be empty SCAN_MEM_PN_GAIN_1 may be empty

SCAN_LASER_POWER SCAN_LASER_POWER_0-99 string SCAN_LASER_POWER SCAN_LASER_POWER may be empty

LASER_CONFIGURATION

LASER_CONFIGURATION_ID POWER_SETTING WAVELENGHT OPTICAL_SWITCH

STD_LASER_CONFIG 80 440 ?

STD_LASER_BLUE_1 DEFAULT_VALUE 440 1

STD_LASER_BLUE_2 DEFAULT_VALUE 440 2

STD_LASER_RED_1 DEFAULT_VALUE 709 1

STD_LASER_RED_2 DEFAULT_VALUE 709 2

In the RUN_TYPE table I have already specified that DCC ZSupression and SReadout are disable for this run.

TRIGGER_CONFIG_ID

…………………………

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


• 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

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



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

Pending issues

P5 surface installation:1. How will be the flying DAQ in terms of hardware and software?

ECAL Trigger and Readout Software architecture/integration

Documents

Transcript of ECAL Trigger and Readout Software architecture/integration