Most appropiate type for an alarm that represents an instantaneous event|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Most appropiate type for an alarm that represents an instantaneous event
Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
1
05/17/2022 - 12:48
sp_Permalink sp_Print

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?

Avatar
Randy Armstrong
Admin
Forum Posts: 1579
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
05/17/2022 - 16:20
sp_Permalink sp_Print sp_EditHistory

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.

https://reference.opcfoundatio…../#5.8.23.4

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
3
05/18/2022 - 02:42
sp_Permalink sp_Print

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.

Avatar
Randy Armstrong
Admin
Forum Posts: 1579
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
4
05/18/2022 - 03:29
sp_Permalink sp_Print sp_EditHistory

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”.

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
5
05/18/2022 - 03:57
sp_Permalink sp_Print

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?

Avatar
Randy Armstrong
Admin
Forum Posts: 1579
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
6
05/19/2022 - 03:44
sp_Permalink sp_Print

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.

Avatar
EG
Member
Members
Forum Posts: 35
Member Since:
12/06/2021
sp_UserOfflineSmall Offline
7
05/19/2022 - 04:01
sp_Permalink sp_Print

Thanks Randy. Makes sense now.

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 44
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1445
Posts: 4889