Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Alarms]: Alarms should consider multiple states to flag actual alarm state #8649

Open
Chsudeepta opened this issue Jan 29, 2025 · 0 comments

Comments

@Chsudeepta
Copy link
Contributor

Issue Description

As an instrument scientist I would like to see that the system understands that different alarm states can be combined in some cases to get the real alarm situation. For example, in case of multiple temperature sensors, while one sensor is expected to be lesser than the threshold and the other is more than the threshold, but it errors out because it considers the one lesser than the limit as in error (but it is exactly how it was needed to be)

Similarly some IOCs start up with inappropriate alarm limits for the instrument they’re used on, e.g. the TPG300 pressure gauge considers “under-range” on the Pirani sensors as an error when this is a perfectly normal situation on RIKENFE

How & Where?

  • Various instruments

Reproducible (Yes/No)?

Yes

Additional Information

  1. We need to collate which IOCs need such special consideration
  2. We need to see whether same PVs but in different IOCs of same type can be at all combined together - that is technical feasibility of such a behaviour

Acceptance Criteria

  1. Minimal set of PVs are identified which need combinatorial logic to determine "real" alarm state.
  2. Technical feasibility of such an implementation is established may be by means of a POC.
  3. The approach is defined and new ticket is created for implementation if it is feasible.
@Chsudeepta Chsudeepta changed the title [Alarms]: Don't show alarms for transient issues [Alarms]: Alarms should consider multiple states to flag actual alarm state Jan 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant