View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005675 | 10000-009: Alarms and Conditions | Spec | public | 2020-05-29 11:50 | 2022-04-26 16:54 |
Reporter | Jeff Harding | Assigned To | Paul Hunkar | ||
Priority | high | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Fixed in Version | 1.05.02 RC1 | ||||
Summary | 0005675: Usability of Alarm Suppress and Disable in a distributed system | ||||
Description | The suppression and disable functionality defined in part 9 described in clause 7 leaves a lot of questions as to how it should work across vendor servers. My use case is an IO Application represented by one UA Server providing flow and pressure measurements and a separate UA Server representing a Function Block Execution Engine providing a Pump Object. When the pump is stopped I want to suppress the low flow and low pressure alarms in the IO Server. If I try to apply the original Alarm Group approach to suppression I can see how this can be implemented. In this case the HasAlarmSuppressionGroup References target a remote AlarmGroup in the Execution Engine which allows the IO Application to subscribe to the state of the Alarm Group Members (PumpStoppedAlarm in this case) allowing the IO Application to manage its own state. (See Figure 1 in the attached pdf). Now If I try to apply the state based approach to suppression it seems like the Suppress and UnSuppress Methods would need to be used since the references are from the StateMachine toward the Alarms to be suppressed. With the references flowing from the Pump the IO would have no way to know they are expected to participate in the suppression logic. I am assuming the 2 UA server are from different vendors so no vendor magic possibility. (See Figure 2 in the attached PDF). Is this what was intended by the design? | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Commit Version | |||||
Fix Due Date | |||||
|
From UA meeting - after longer discussion - need to explain how suppression works (internal in application), We have an Alarm group for suppressing alarms based on a group of alarms (an alarm can suppress a group of alarms) - which can be used, but only if an alarm - need to add the ability to suppress an alarm not by an Alarm but by a boolean (or some state of a variable) - so Alarm groups should be extended to allow additional items not just an Alarm to trigger - then when a distribute state happens it can be monitored (not just via a call) - i..e when a boolean goes to a value - it suppress the alarm. (could be as simple as the active state is really just a boolean - could be any other boolean) |
|
Extended the definition of AlarmGroup for AlarmSuppressionGroup to allow BaseDataVariables with a datatype of Boolean |
|
Agreed to changes edited in telecon. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-05-29 11:50 | Jeff Harding | New Issue | |
2020-05-29 11:50 | Jeff Harding | Status | new => assigned |
2020-05-29 11:50 | Jeff Harding | Assigned To | => Paul Hunkar |
2020-05-29 11:50 | Jeff Harding | File Added: AlarmSuppressionExamples.pdf | |
2020-06-02 00:35 | Jeff Harding | Project | 10000-005: Information Model => 10000-009: Alarms and Conditions |
2020-06-16 06:09 | Paul Hunkar | Note Added: 0012324 | |
2022-04-26 05:23 | Paul Hunkar | Status | assigned => resolved |
2022-04-26 05:23 | Paul Hunkar | Resolution | open => fixed |
2022-04-26 05:23 | Paul Hunkar | Fixed in Version | => 1.05.02 |
2022-04-26 05:23 | Paul Hunkar | Note Added: 0016625 | |
2022-04-26 16:54 | Jim Luth | Status | resolved => closed |
2022-04-26 16:54 | Jim Luth | Fixed in Version | 1.05.02 => 1.05.02 RC1 |
2022-04-26 16:54 | Jim Luth | Note Added: 0016643 |