Log In
Home
12/06/2021
Offline
If an alarm is not based on an underlying input value, but instead based on an instantaneous one-shot event, what is the most appropriate OPC UA alarm type to model this as?
05/30/2017
Offline
Alarms are state machines. If you do have a process with a persistent state then you do not have an alarm.
Simple events are what you need to use in your case.
That said, if the one-shot event is actually a notification that something went from a normal state to alarm state then you would have a Discrete Alarm. i.e. TripAlarmType:
The TripAlarmType is a specialization of the OffNormalAlarmType intended to represent an equipment trip Condition. The Alarm becomes active when the monitored piece of equipment experiences some abnormal fault such as a motor shutting down due to an overload condition.
12/06/2021
Offline
The underlying condition is modelled with a state machine, so there is a persistent state in a sense, because when the one-shot event occurs our alarm (i.e. the machine alarm, as opposed to OPC UA alarm) will enter a latched state which requires a user to acknowledge/reset it.
What confuses me about the TripAlarmType is that because this type is a DiscreteAlarmType, and the DiscreteAlarmType states:
The DiscreteAlarmType is used to classify Types into Alarm Conditions where the input for the Alarm may take on only a certain number of possible values (e.g. True/False, running/stopped/terminating).
I was then wondering what discrete values are for the trip event where there is no underlying discrete set of values?
So to take the motor shutting down fault example, I guess the discrete inputs could be "OK" and "Overload"?
To give you an example from our system, if a series of items are being inspected on a conveyor belt, there are two pack sensors, one at the start and one at the end of the belt. If a pack is seen entering the system, but then goes missing and not seen at the second sensor (e.g. because somebody has removed it from the belt), that is an alarm that requires attention from the user, but there is no underlying discrete set of values - it's a one-shot occurrence.
05/30/2017
Offline
that is an alarm that requires attention from the user, but there is no underlying discrete set of values - it's a one-shot occurrence.
The class of conditions you are describing are off-normal discrete alarms where the discrete states are "normal" and "not-normal".
12/06/2021
Offline
So this would basically be mapping the InputNode of the OPC UA alarm to the latched state of the underlying machine alarm, correct?
The InputNode documentation states:
The InputNode Property provides the NodeId of the Variable the Value of which is used as primary input in the calculation of the Alarm state.
And while it's technically true that the latched state of the underlying alarm is the "primary input" for the OPC UA alarm, I don't think it makes a lot of sense when looking at the system as a whole (as a user would): in my example, isn't the "primary input" into the alarm state the occurrence of the missing pack?
05/30/2017
Offline
The InputNode Property provides the NodeId of the Variable the Value of which is used as primary input in the calculation of the Alarm state. If this Variable is not in the AddressSpace, a NULL NodeId shall be provided. In some systems, an Alarm may be calculated based on multiple Variables Values; it is up to the system to determine which Variable’s NodeId is used.
The InputNode does not make sense for every Alarm. Set the value to NULL if there is no suitable variable. But conceptually the "missing pack" event is an OffNormalAlarm. You could not detect this conditions if you did not have sensors that allowed you to infer a problem.
1 Guest(s)
Usage Policy