# Interface to the Experiment

BTeV presents a very large scale and complex online environment. The
configuration management and fault tolerance of the triggering farms
represent a significant computing portion of this environment, but it is
not the complete picture. Other facets include the trigger code itself,
the data acquisition system and run control environment, and detector
monitoring (ie, pressures, temperatures, high voltages, etc.). This ITR
work represents a *component* of the overall online environment, not
global master.

The configuration management and fault tolerance of the trigger farms
must interface to the experiment specific code on several fronts
experiment interfaces including:

-   run management.

> A *run* is the overall concept of preparing to and acquiring data for
> a certain period of time. Run control is the overseeing software that
> manages a run. Under normal data taking conditions a run is reading
> out the full detector for some length of time, generally in terms of
> hours. Some successive runs may have identical configurations that
> simply require triggers to be re-enabled, while others may require
> large reconfiguration and re-downloading of various constants and a
> different suite of application programs.
>
> An added complication is that multiple runs may happen parallel that
> are using different parts of the detector. This is especially true
> during the commissioning phase of the experiment. It is not yet of
> some of the parallel runs will need to share pieces of hardware,
> specifically the L1 trigger system.
>
> Another feature of run control is the global state manager for the
> online environment. Each run is started by passing through various
> states. The first run after a power up requires the most state
> transitions, additional runs may require fewer as some state
> transitions may already be satisfied.
>
> The experiment "run control" would like to treat the trigger
> processing farms as black boxes, issuing a single state change request
> and receiving a single acknowledgement/status back. This also implies
> that error and status information generated by the black boxes needs
> to be propagated to the global run manager, which will determine if
> the run should be aborted/cancelled.

-   Persisant storage (resource management, run history)

> Particular run configuration history (what hardware participated,
> versions of trigger algrothims used, number of events processed, etc)
> require permanent storage into the experiment's run history database.
>
> The current hardware configuration needs to be accessible to
> experiment written software. This can be by using a shared database or
> replicating the data between two stores.

-   User interface/diagnostics

Runs have a human interface. They are started, stopped, and monitored by
operators. The experiment needs access to the configuration, status, and
error information to interface to the control room GUIs.

Diagnostics and status information at each level of the fault tolerant
system must be provided to the experiment to trace and diagnose the
inevitable hardware/software/integration that occur throughout the life
of the experiment.

-   Application code

The application code will have status and error information. Can it use
the same underlying infrastructure that is built into the fault tolerant
system?