SVT Run Control Xin Wu

1
SVT Run ControlXin Wu

• CDF Run Control framework
• 3 basic parts
• Front-End Readout code C code run on crate CPU
• Run Control packages Java code run on DAQ
  computers
• Databases hardware, run, trigger, calibration
• 3 basic independent processes
• Front-end, Run Control, Resource Manager
• Messaging mechanism between processes
• SmartSockets
• Database access mechanism
• JDBC connections

2
CDF Run Control Scheme

SmartSockets API

SmartSockets API
Resource Manager
SmartSockets (SS)
Resources Manager process
Messenger
Crate Tasks
JDBC Connections
Front-end process
not yet implemented? necessary?
3
Partitions

• Partition is used to identify a Run Control
  process for the purpose of detector hardware
  resource allocation
• in general a RC process requires a Trigger
  Supervisor and there are 8 TS available, only 8
  partitions can be active at the same time
• predefined partitions (1-8) stored in Hardware
  Database
• software partition is possible when TS is not
  needed
• Resource Manager server manages allocation of
  partitions
• Static methods are provided for interacting with
  the server via SS, eg.
• ResMgr.getAllPartitions view status of all
  partitions
• ResMgr.requestPartition request a partition
• ResMgr.requestPartition close a partition
• Once a partition is granted, the user name and
  process ID is registered in the Hardware Database
• It was proposed that SVT crates should NOT be
  split in different partitions

4
Resources

• Resource refers to a detector component
• primary resources
• crates (eg, /frontEnd/svt/tracking/00,
  /frontEnd/svt/fitter/00)
• composite resources (components)
• a set of crates or components (eg, /frontEnd/svt)
• A primary resource can only be booked (owned) by
  one partition
• A partition can only book free primary resources
  in a composite resource
• so SVT will be a special case?
• Resource Manager server manages allocation of
  resources
• Static methods are provided for interacting with
  the server via SS, eg.
• ResMgr.bookResource book a resource
• ResMgr.releaseResource release a resource
• ResMgr.getBookedResouces view booked resources

5
Readout Configuration and Readout List

• Readout configuration specifies the clients
  managed by a state manager
• readoutConfig stores a list of clients (mostly
  crates)
• can be filled by partition configuration files
  (eg partitionltgt.cfg)
• or by RunConfiguration for specific run type
• readoutConfig centrally handles acknowledgments
  from clients
• is an AckListener known to the state manager
  messenger
• Readout list specifies the readout parameters of
  a client (crate)
• When a stateManager performs a cold/warm start,
  readout lists are send to its clients by the
  messenger
• a readout list can come from database or a file
  
• the subject of the ss message is
• /partition-ltgt/readoutlist/ltcratenamegt
• the message type can be general or crate type
  specific
• ReadoutList_MessageType, DiracReadoutList_
  MessageType
• the message body is a ReadoutList object packed
  by daqmsg

6
Front-End Code

• 3 pieces of C code
• implementation code
• local run control FER_imp.c
• board level tasks ADMEM_imp.c, TDC_imp.c, ...
• crate level tasks QIECALIB_imp.c,
  COTCALIB_imp.c, ...
• messenger interface code
• interface between local run control and actual
  messaging mechanism
• FER_mess.c
• messenger implementation code
• Smartsockets implementation FER_smart.c
• All three pieces are compiled as one library and
  loaded into crate CPU memory upon crate startup

7
Front-End Messaging

• Upon startup of a crate, the messenger task,
  FER_messagener(), is spawn
• set state into IDLE, partition number into -1
• set up local message queues (msgQ) for error,
  warning, message, ...
• setup Smartsockets messaging by calling
  FER_smartInitMS()
• set server name (b0dau30) and project name
  (CDF_DAQ)
• connect to server
• setup subject callbacks for some subjects
• /setPartiton/ltnodenamegt, //command/ltnodenamegt,
  //readoutlist/ltnodenamegt, ...
• setup default subject callback
• go into an infinite loop to
• process incoming messages
• send out monitoring, warning and error messages
  

8
Front-end Process

board implementations
RC message
FER_imp (local run control)
Callbacks
ack
SmartSockets (SS)
messages
Sendders
Local msqQs
infinite loop
Front-end process
9
CDF Run Control process

• User interface is rcGUI
• has several stateManagers
• DaqGUI, QIECalibGUI, ...
• each with its own transition model
• Only one stateManager can be active at a
  time
• has access to static methods of ResMgr that
  communicate with the Resource Manager server
  via SS
• With rcGUI, one can
• (de)activate a stateManager
• select a partition and book resources for an
  active stateManager
• control an active stateManager

10
QIECalibGUI and COTClibGUI
11
State Managers

• A state manager manages state transitions for a
  Run Control process
• different types of run have different state
  managers
• DAQ daqStateManager
• calibrations COTCalibStateManager,
  QIECalibStateManager
• tests COTTestStateManager
• common features provided by abstract classes
• StateManagerGUI extends stateManager
• abstract public void DrawGUI()
• stateManager extends FiniteStateMachine
• abstract public void setupStateAndTransitions()
• a specific state manager should implement methods
  
• setupStateAndTransitions() specifies state
  transition model
• DrawGUI() draws state transition model on the
  GUI
• transitions are handled by method
  doTransition(Transition T) in the class
  FiniteStateMachine

12
State Manager Messenger

• a state manager communicates with its clients via
  its messenger
• each stateManager has its own messenger
• a messenger knows the current
• partition number from current RunConfiguration
• clients list from current readoutConfig
• a messenger
• provides interface to SmartSockets
• use publish-subscribe messaging, project CDF_DAQ
  
• uses daqmsg package to pack messages
• keeps a list of processes that listen to
  acknowledgments (AckListener)
• provides a method sendTransitionMessage() for
  sending commands
• subject (destination) of transition message
  within a partition
• /partition-ltpartition numbergt/command/ltdestination
  gt
• runs a thread to receive acknowledgments using SS
  Callback and distribute them to all AckListeners

13
daqmsg

• A package providing utilities to simplify
  messaging
• DaqMsg an abstract class using Java reflection
  to pack and unpack DAQ messages (numbers,
  strings, objects, structures, ...) in
  SmartSockets specification
• provides methods to pack DaqMsg to TipcMsg (ss
  message) and unpack TipcMsq to DaqMsg
• creates SS message type (structure, grammar)
  according to the message
• message type number using predefined integer
  values
• DaqMsgBase.java, FerMessages.java

14
Run Configuration

• Run Configuration specifies general run time
  parameters
• runNumber, creationTime, processId, userName,
  partitionId, runSET, ...
• runSet stores run parameters for a specific run
  type, default sets stored in run database
• runType, nEvents, tsMode, l2Mode, crateSets, ...,
  

15
High Level Questions

• Can SVT crates be split in different partitions?
• No. (P1)
• Robin or Smartsockets?
• Smartsockets everywhere. (P3)
• Do we need a SVT Control middle man?
• Maybe not. (P2)
• Do we need to have remote control of SVT during
  the run?
• Where to run SVTSPY? Workstation or crate CPU
• Default on workstation (P5)
• Can we agree that all crate CPU tasks written in
  C?
• Is SVTSPY an independent process? How to pass its
  results?
• ...

16
Do we need a SVT Control middle man?

• Pros
• was thought necessary to run SVT without DAQ
• independent SVT system level tasks (eg. SVTSPY,
  error handling)
• possible SVT expert intervention on SVT itself
• possible to use the same process for debugging
• parallel development of software with Run control
  
• do what we want for implementation
• state manager, GUI, remote access, SS vs. Robin
• no need for local run control on crate CPU
• Cons
• SVT is an exception of the CDF DAQ system, danger
  to be isolated
• potential confusion who starts SVT Control?
• probably need to directly access databases
• need more software development effort,
  duplication
• ...

17
Implications with and without SVT Control

• Implications with a SVT Control
• SVT Control is one of the clients of Run Control
• Only SVT Control can book SVT crates from
  hardware database
• SVT Control can access trigger database for maps
• Run Control does not know the detail
  configuration of SVT
• Implication without a SVT Control
• SVT crates are clients of Run Control
• some SVT system functions need to be inserted
  into Run Control
• SVT message types, database access, tables
  downloading, table version checking, ...
• more logical to run SVTSPY on crate CPUs

18
SVT Front-end code

• board specific front-end code independent of SVT
  control or not
• provided by board experts
• need local run control in case of no SVT Control
• template from standard crate
• 3 implementations svt_tracking, svt_merger,
  svt_fitter
• messenger implementation in case of no SVT
  Control
• stand one should be modified for SVT
• messenger implementation in case of a SVT
  Control
• can write our own
• large maps and tables downloading?
• version checking mechanism?
• monitoring and error handling code?

19
SVT front-end implementation

• What actions should be taken by boards and SVT
  system upon state transition command?
• cold_start, warm_start, activate, end, abort,
  pause, resume, halt, recover, run, shutdown,
  download
• reaction to other messages
• setPartition, readoutList, ...
• How to implement down-loading only one set of
  table?

20
Practical Issues

• How to divide up software writing?
• eg. in case of no SVT Control
• Individual board implementations (C code)
• local run control local messenger (C code)
• insertion of SVT functions into Run Control
  (Java)
• Are Run Control framework stable enough to start
  writing SVT code?
• Who are interested in writing code?
• How to proceed?

21
Agenda on run control discussion

• Morning
• brief summary of current CDF Run Control
  framework Xin
• present an initial list of issues concerning run
  control Xin
• brief discussion of the list All
• present an initial list of database related
  questions Xin
• discussion on the database All
• presentation of CDF Run Control framework Frank
• Afternoon
• discussion on the run control All