Introduction

CODA run-control introduction

The run control component of the JLAB CODA data acquisition system is designed to play the supervisory role in the overall data production environment of the experiment. The run control system is designed to reflect the structure of CODA itself, thus it is composed of separate elements (components) that are likely to be implemented as separate processes running on different machines. This design consistent with the AFECS approach, providing distributed control application entities that collaborate dynamically to satisfy control objectives of the DAQ system. The architecture of the run control can be seen as a hierarchy of AFECS control agents, each with responsibility for a well defined component or part of the DAQ system (EB:Event Builder, ET:Event Transfer, ER:Event Recorder, ROC:Readout Controller, etc.). The AFECS agent encapsulates control/monitoring algorithms, as well as external interface details of the real world component. This provides significant advantages, namely clear separation of the control and application layers of the component, and seamless integration of legacy software components into the run control environment. The agent state is the simplified external view of the current working condition of the CODA component or slow control component of the data production system, under its responsibility. Each agent is capable of receiving control messages from other agents or the outside world. These messages can cause an agent to execute actions which potentially will change the visible state or monitor the state of the component. The agents are organized into a hierarchical tree structures that reflect the basic organization of the DAQ system itself. An agent in the control tree can have only one supervisor agent and can supervise many other agents. At the top of the tree is a single agent, which represents the overall state of the entire online system. Every agent under supervisor agent represents one of the major elements of the CODA data acquisition system.Obviously an agent of a sub-system itself can be a supervisor of the agents responsible for individual sub-components. The distributed nature of the run control system allows for grouping of agents into specialized virtual clusters or domains.
The agents in the hierarchical tree transmit messages between themselves to exchange control commands and status information. In the basic scenario a human operator sends control commands through the graphical interface(GUI) to the supervisor agent, which forwards them to the sub-system agents, who in turn forward them to component representing agents and so on. The result of the control directives are sent back up the tree so that the human operator is made aware of any changes in the state of the system. Any agent in the hierarchy can either perform some actions on the commands or return results of the commands it receives.

 
The CODA DAQ system includes a run-control facility consisting of a back-end run control supervisor and a front-end graphical operator display that connects to the supervisor and controls its operation. The supervisor in turn controls operation of the many CODA components that participate in the run. The latter are defined in run configuration files that the operator chooses at startup. The gui presents the operator with a choice of possible actions that depend on the current state of the run. The supervisor translates the operator choice into appropriate commands to the individual components. Alternatively, limited communication with the supervisor can be performed via command-line scripts.
The supervisor in addition monitors the health and operation of the CODA components and warns the operator or pauses the run if problems are detected.
Users can customize run control operation in a number of ways. The configuration file can specify user-written scripts or processes that get invoked or started at specific points in the run control state machine. These can be as simple as a script that makes an entry in a database at particular transition point, or as sophisticated as a complete state machine for a detector component that responds to run control state transitions and communicates with the run control supervisor (e.g. a HV control state machine).
Finally, a run scheduler component can automate a series of runs with user-specified scripts run between them that change detector parameters, ideal for automating calibration runs.