08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 1 ECAL...
-
Upload
edith-phelps -
Category
Documents
-
view
215 -
download
0
Transcript of 08/04/05 OFF-Detector Workshop Electronics R. Alemany (LIP) Session: Software Architecture 1 ECAL...
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
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
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
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.
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 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.
08/04/05 OFF-Detector Workshop Electronics
5
1. Proposal for the Trigger and Readout Software Architecture
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.
08/04/05 OFF-Detector Workshop Electronics
6
1. Proposal for the Trigger and Readout Software Architecture
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
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 integrityand data quality
monitoring Start ConditionsDB
DCC_RUNNING
TCC_RUNNINGSRP_RUNNING
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm 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)
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
DCC_READY
CCS_READY
LTS_READY
In this example, LTS controls the trigger(mezzanine) card of CCS
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
DCC_RUNNING LTS_RUNNING
In this example, LTS controls the trigger(mezzanine) card of CCS
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
i2o
StartStart
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
CYCLE_FINISHED (after all LA1 fired)
In this example, LTS controls the trigger(mezzanine) card of CCS
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
Stop
DCC_READY
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
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)
In this example, LTS controls the trigger(mezzanine) card of CCS
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
Configure(PC&RT specific for MF
and for S1-C2)
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
DCC_READY
CCS_READY
LTS_READY
In this example, LTS controls the trigger(mezzanine) card of CCS
Monitoring Farm Supervisor
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
DCC_RUNNING LTS_RUNNING
In this example, LTS controls the trigger(mezzanine) card of CCS
StartStart
Monitoring Farm Supervisor
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
i2o
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
ECAL Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
CYCLE_FINISHED (after all LA1 fired)
In this example, LTS controls the trigger(mezzanine) card of CCS
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
i2o
Stop
DCC_READY
… and so on so for …
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
Data integrityand 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 Parameters2. Get Laser Parameters and Pulse Info
(for confirmation)
Configure(RT specific for MF
And for S2-C1)
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
DCC_READY
CCS_READY LTS_READY
Laser Supervisor
LASER_READY
MATACQ Supervisor
ECAL Supervisor
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
i2o
Start
Start
Laser Supervisor
MATACQ Supervisor
ECAL Supervisor
Custom EVB
i2o
i2o
DCC_RUNNING LTS_RUNNING
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 V2OR
LOCAL RC?
DCC Supervisor
CCS SupervisorLocal Trigger Supervisor
Monitoring Farm Supervisor
DB Manager XDAQDataStore
ORACLEMySQLXML
Data integrityand data quality
monitoring
SpyEvents(VME DCC RO)
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
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.
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_PEDESTAL VFE_GAIN_6 string empty MGPA_GAIN_6 may be empty
STD_PEDESTAL VFE_GAIN_12 string empty MGPA_GAIN_12 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
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
1. Trigger and Readout Software Architecture: error/exception handling (RCMS)(notes taken from F. Lelli talk at OLSWG CMS Week 150305)
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?