Triggers & Trigger Control

Note: This page is under development .

Last modified by: JGZ 1/22/1999


Requirements


Triggers describe unusual events detected by the monitor application programs. The event may be from any of the following sources:

The Trigger Manager is a sub-system of the Data Monitoring Environment that encodes the triggers and routes them to all appropriate trigger handling components e.g. a meta-Database, an operator alarm screen or an operations expert system). The requirments on the Trigger manager are the following:


Trigger Generation


I would like to propose a model of the trigger generation process. A schematic description of the model is shown below:

Within this framework, trigger generation is broken up into five stages. Stages denoted as rectangles are data stages. The only processing associated with them is accessing or building descriptors of the data. The stages denoted as circles are correspond to computational stages that transform the data and/or make decisions. The five stages are:

  1. Collect or access the raw input data. The raw input data are typically a single channel from a single frame, although in some cases several channels may be needed or frames may be merged.
  2. Transform the data into a representation that will be used by the trigger.  The transformation may use data from channels other than the principal channel listed in the input section (for ...) and may result from the composition of several elemental transformations. Examples of useful transformations are
  3. The transformed data are assumed to constitute a series that can be defined by a few standard parameters and a list of (float) data. This can represent a time series, a frequency series (Fourrier coefficients) or a histogram.
  4. The transformed data series scanned by a detector function. The detector function generally compares the transformed series elements, its integral, variance or other property to a threshhold.
  5. if the property under test surpasses the threshhold, a trigger is generated. The trigger is idenfied by a unique trigger ID and by trigger result data such as:

The boxes below each stage contain a list of the data needed to describe the processes or the data that forms the stage. Note that the descriptors for the calculational stages are static, i.e. they are independent of the input data, describing only the processing function and its static parameters.

This model is not meant as an implementation specification, i.e. I don't expect every monitor process to first transform data and then run a function called det() to generate the trigger. Nevertheless, it is sufficiently general that any monitor can be described within the framework. If nothing else, an arbitrary function can be put into the detection phase, leaving a trivial transformation stage. The purpose of separating the transformation from the detection phase is that in many cases, the transformed data are important for interpreting the trigger. The output of the transformation thus defines the data that will be stored with the trigger report and can be used for further characterization or analysis of the trigger.

It is tempting to break down the detection step further to a scalar "badness factor" calculation followed by a comparison to one or more limits. This would allow the description of the trigger threshold parameter and result values to be formalized. The disadvantage to this decomposition is that it is difficult to decouple a time-varying function calculation from a threshold sensing without passing essentially all the input data.


Architecture


A software architecture that meets the requirements enumerated above is shown in the figure below. The architecture consists of the following components:

Trigger Generation API

The Trigger Generation API encodes a description of each stage of the trigger generation process described in the model above. A description of each stage is optionally created as an object. The objects are then collected together into a trigger object for and sent off as XML to the event anager.

Trigger Broker

The Trigger Broker has three major resposibilities. They are:

The Trigger Broker receives all triggers from the Data Monitor Applications and routes them to one or more destinations based on the trigger type and a routing table managed by the trigger broker. In the future, certain combinations of (nearly) coincident triggers will be selected for sending to one or more expert system for immediate analysis.

Trigger Logging

Triggers will be logged to the meta-Database. The logging will be performed by the LDAS Event Controller via an as yet undefined protocol. Trigger objects will be serialized into XML objects before they are sent to the Event Manager.

Operator Notification

Operators will be notified by way of the CDS (Epics) Alarm Manager.

Trigger Control Interface


Please send comments and suggestions to: John Zweizig