Big Picture User Experience
User alarm limits should obey existing alarm deadbanding configuration
Detailed Description
After configuring user alarms using the “user hi” and “user lo” functionality, alarms are being generated without consideration for the alarm level deadband configured for the point.
For example:
A user high alarm configured at 100 will ring into alarm at 100, and will clear at 99.
This results in chattering of the user alarm, and modifying the deadband value does not affect this.
A high alarm (not a user alarm) configured at 200 with a deadband of 15 will ring into alarm at 200, and will not clear until the value drops down to 185.
Reducing nuisance alarms is a key part of our CRM thought leadership.
The operator chooses the user-alarm limits they desire, and the administrator sets the alarm-level deadband.
The operator does not require the ability to set the alarm-level deadband.
Acceptance Criteria
User-alarm limits obey the alarm-level deadbands configured for the point.
Business Value
A top initiative for MidStream to be the leading SCADA CRM provider for pipeline operators. Using user-alarms today could increase false alarms, which is undesirable.
Target Version
Version for this feature: TBD
Version the customer is on or consuming: OASyS 2018 SP3 (Pembina)
Version being targeted by project or future opportunity: ES2023+
Customer, Project, and Deadline Details
Customers (names/projects) that will consume this: All. Pembina was first to request it for 2018 SP4.
Deadlines and Commitments: None.
Commercial and/or Contractual Impacts: None.
Customers System / Architecture
Size: Small, Med, Large
Topology: Single site, Multi Site, and Enterprise
Any Unique configuration to note?: no
Has this functionality been delivered before?: Was in their previous (7.6?) system.
Out of Scope
No other changes - just obey the existing alarm-level deadbands.
Assumptions
This is a minor change.
Dependencies
None.
PSR - Performance, Scalability, Resilience
What aspects are important (or assumed) for this feature? alarm reduction
What if there are 10,000 of these? Every point will evaluate these limits
How quickly is this expected to react/respond? same as now
Does this impact failover / mode switch? no
Is this assumed to have performance impact, or not? no
NFR - Non-Functional Requirements
None.
Risks/Mitigations
None.
Architecture Review
No.
Do we need a SPIKE?
No
Links
PMFR: http://tcjira.aveva.com/browse/PMFR-365
T-Shirt Estimate: T-Shirt 1760306.
Class 5 Estimate: .
Implementation: .
