Project

General

Profile

Run Control Workflow on the DAQ Monitor Server

(2010-07-22, S. Kasahara)
(Last updated 2011-05-19)

This document is a DAQ Monitor Server specific version of the more general [[kab-test-project:Proposed Run Control Flow]] document posted by Kurt Biery
on 2010-05-25 describing the proposed Run Control States and Actions.

The following describes the corresponding State or Action of the DAQ Monitor Server during one of the proposed Run Control State/Actions.

No Resources State

The DAQ Monitor Server application (ndmdaqmonitor) should be started on boot of its host node so that during the NoResources State
the ndmdaqmonitor will already be running. The configuration information given to the ndmdaqmonitor on boot will be
minimal but should include at minimum:

  • Its application name.
    • In normal operation mode, one ndmdaqmonitor will be running and its application name will be ndm000.
  • Its startup message facility configuration.

On startup the DAQMonitor Server application start an NdmDirector which will register
to listen for RC Establish Partition and Detach Partition requests on the NULL Partition.

The Ganglia gmond and gmetad daemons should also be started on boot of the nova daq monitor host node.

Establish Partition Action

ndmdaqmonitor receiving an EstablishPartitionRequest message must also receive:

  • A partition number.

Actions taken by the ndmdaqmonitor:

  • Checks to see if it has already received an EstablishPartitionRequest for the given partition. If so, it will return Error.
  • If the Monitor receives a request for a new partition, spawns a threaded NdmDAQMonitor to handle that partition. The thread will set up the
    RC listeners to listen for commands given to its assigned partition.

Partition Established State

  • With an assigned partition, the spawned NdmDAQMonitor thread is now in a wait state for the next command.
  • The NdmDirector will continue to listen for further EstablishPartitionRequests on the NULL partition. It will also check for threads which have finished having
    received a DetachFromPartitionRequest message.

Load Hardware Configuration Action

(N/A)

Load Connection Configuration Action

(N/A?)

A DAQ Monitor Server thread receiving the LoadConnectionConfiguration request must also receive:

  • A configuration file URI for the connection configuration. This file is expected to be an .xml file. Some examples of connection configuration information
    which the DAQ Monitor Server thread receives:
    • A list of components from which the DAQ Monitor Server thread should expect to monitor on its assigned partition. For each component, the
      information to be sent is: * Host - the component host, e.g. novafarm-01.fnal.gov * Application name - the component application name, e.g. evb001

Connection Configuration Loaded State

  • The thread now as a configured list of components to monitor on its assigned partition.

Make Connection Action

  • Might do something to determine if data is being sent by each of the components on its assigned partition, but at this point does nothing.

Load Run Configuration Action

A DAQ Monitor Server thread receiving the LoadRunConfiguration request must also receive:

  • A configuration file URI for the run configuration. This file is expected to be an .xml file. Some examples of run configuration information
    which the DAQ Monitor Server thread receives:
    • A list of thresholds for each quantity to be monitored.

ConfigureRun Action

A DCM receiving a ConfigureRunRequest will:

Fully Configured State.

The novadaqmonitor has successfully been configured.

Begin Run Action.

The novadaqmonitor receiving a BeginRunRequest message does not need to receive any other information.

Actions taken by the dcmapplication:

  • Begin applying thresholds to incoming data.

Running State.

Threads in a running state will apply configured thresholds to monitored data and report values out of range to the MessageLogger.

Pause Run Action.

The DAQ Monitor changes the state to Paused Run.

Run Paused State.

The DCM stops applying thresholds to monitored data while the run is paused.