Note: This page is under development .
Last modified by: JGZ 1/22/1999
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:
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:
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.
A software architecture that meets the requirements enumerated above is shown in the figure below. The architecture consists of the following components:
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.
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.
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.
Operators will be notified by way of the CDS (Epics) Alarm Manager.
Please send comments and suggestions to: John Zweizig