Developer Guide¶
The Watcher CSC is implemented using ts_salobj.
The fundamental objects that make up the Watcher are rules and alarms. There is a one to one relationship between these: every rule contains one associated alarm. It is the logic in a rule that determines the state of its alarm.
Each rule monitors messages from remote SAL components (or, potentially, other sources).
Based on that logic the Watcher sets the severity of the associated alarm.
Rules are instances of subclasses of BaseRule
.
There are many such subclasses.
Each alarm contains state, including the current severity, whether the alarm has been acknowledged, and the maximum severity seen since last acknowledgement.
Alarms are instances of Alarm
.
Other Classes¶
Model
manages all the rules that are in use.
It is the model that uses the watcher configuration to construct rules, construct salobj remotes and topics and wire everything together.
The model also disables rules when the Watcher CSC is not in the ENABLED state.
In order to reduce resource usage, remotes (instances of lsst.ts.salobj.Remote
) and topics (instances of lsst.ts.salobj.topics.ReadTopic
) are only constructed if a rule that is in use needs them.
Also remotes and topics are shared, so if more than one rule needs a given Remote, only one is constructed.
Since rules share remotes and topics, the rule’s constructor does not construct remotes or topics (which also means that a rule’s constructor does not make the rule fully functional).
Instead a rule specifies the remotes and topics it needs by constructing RemoteInfo
objects, which the Model
uses to construct the remotes and topics and connect them to the rule.
TopicCallback
supports calling more than one rule from a topic.
This is needed because a salobj topic can only call back to a single function and we may have more than one rule that wants to be called.
Rules are isolated from each other in two ways, both of which are implemented by wrapping each remote with multiple instances of RemoteWrapper
, one instance per rule that uses the remote:
A rule can only see the topics that it specifies it wants. This eliminates a source of surprising errors where if rule A if uses a topic specified only by rule B then the topic will only be available to rule A if rule B is being used.
A rule can only see the current value of a topic; it cannot wait on the next value of a topic. That prevents one rule from stealing data from another rule.
Writing Rules¶
Contributing¶
lsst.ts.watcher
is developed at https://github.com/lsst-ts/ts_watcher.
You can find Jira issues for this module using labels=ts_watcher.
Python API reference¶
lsst.ts.watcher Package¶
Functions¶
|
Get a key for a filtered topic wrapper. |
|
Get a rule class given its name. |
|
Compute the key unique to a topic. |
Run the Watcher CSC. |
|
|
Write data and wait for it to be processed by the topic callback. |
Classes¶
|
A Watcher alarm. |
|
Check one kind of ESS data, e.g. |
|
Base class for filtered field wrappers. |
|
Base class for watcher rules. |
A sequence of field wrappers. |
|
|
Track a field of an ESS telemetry topic, with a particular sensor name. |
|
Topic wrapper that caches data by the value of a filter field. |
|
A filtered field wrapper for an array field, with metadata indicating indices of interest. |
|
|
|
A mock OpsGenie service to support Watcher escalation in unit tests. |
|
A mock PagerDuty service to support Watcher escalation in unit tests. |
|
A mock SquadCast service to support Watcher escalation in unit tests. |
|
Watcher model: constructs and manages rules and alarms. |
|
Base class for watcher rules that poll for data. |
|
Information about a remote SAL component. |
|
Simple access to the current value of a specified set of topics. |
Raised by BaseRule's constructor if the rule is disabled. |
|
|
Compute severity for a rule that involves one float value with multiple threshold levels. |
|
Call rules and/or wrapper callbacks when a topic receives data. |
|
The Watcher CSC. |
Class Inheritance Diagram¶
lsst.ts.watcher.rules Package¶
Classes¶
|
Monitor ATCamera dewar temperatures and vacuum. |
|
Monitor the system clock of a SAL component using the |
|
Check the dew point depression. |
|
Monitor the summary state of a CSC. |
|
Monitor the heartbeat event from a SAL component. |
|
Check the humidity. |
|
Monitor HVAC SAL topics for any alarming states. |
|
Monitor the summary state of the two MTAirCompressor instances. |
|
Check that the MT camera cable wrap is following the camera rotator. |
|
Monitor the MTDome azEnabled event for any alarming states. |
|
Monitor the MTDome capacitor banks for any alarming states. |
|
Monitor the actuator force error of main telescope M2 is out of the normal range. |
|
Monitor M1M3 mirror temperature. |
|
Monitor the mirror temperature of main telescope M2 is out of the normal range. |
|
Monitor MTMount azimuth. |
|
Monitor the main telescope M2 is out of the closed-loop control. |
|
Monitor the tangent link temperature of main telescope M2 is out of the normal range. |
|
Monitor the total force and moment of main telescope M2 is out of the normal range. |
|
Monitor the main telescope vibration event based on the rotator detection. |
|
Check for something being too hot, such as hexapod struts. |
|
Monitor the PDUs for signs of a power outage. |
|
Monitor the status of the ScriptQueue. |
|
Monitor the presence of telemetry from a SAL component. |
|
Check for low pressure. |
Class Inheritance Diagram¶
lsst.ts.watcher.rules.test Package¶
Classes¶
|
A test rule that transitions through a specified list of severities, repeatedly. |
|
A minimal test rule that has no configuration and no remotes. |
|
A test rule that transitions through a specified list of severities, repeatedly, when manually triggered by test code. |