Controls Group - Generic Alarm 6.47
Tue, 2020-02-25 16:57 — Martin Perlot
From the Controls Group,
Edits and profiles for Generic Alarms. Note that Alarms are a frequent requirement in device profiles, and support for these DGNs is effectively a prerequisite for Level Two and many Level Three profiles.
| Attachment | Size |
|---|---|
| 6.47 Generic Alarm.docx | 326.28 KB |
| 6.47 Generic Alarm_v2.docx | 326.72 KB |
In these generic alarm
In these generic alarm revision we added byte 5 - device instance to the status message as a way to identify the alarm condition if the device has multiple instances using the same alarm. However it appears this was not implemented on the command DGN. Shouldn't we be able to acknowledge these alarm instances independently?
Good catch, Austin. Byte 5
Good catch, Austin. Byte 5 in the Command should be Device Instance. I'm sure the new administrator will be much better than I ever was at catching these things.
The Controls Group has
The Controls Group has submitted an updated profile.
Also, should there be a way
Also, should there be a way to enable/disable full time monitoring?
The Full Time Monitoring is a
The Full Time Monitoring is a message from the sensor or alarm device to the UI device (e.g. buzzer) to say, "If I go offline, assume the worst!"
Now, there may be multiple UI devices, so even if one or more devices don't really need to work in this fail-safe mode, it likely isn't safe to assume that all the UI devices in the system shouldn't. At least, no such circumstance came up in discussion. If you can imagine a circumstance where a global change in how an alarm should be treated during operation (turning on and off the fail-safe mode), we can revisit the issue.
-----
As to whether the alarms remain in Section 7.6 or get moved entirely into the main text, that will be left to the new Administrator unless members care to direct otherwise. For the most part, the committee has chosen to give the Administrator broad authority regarding the format of the document, as well as freedom to clean up minor ambiguities and mistakes. I don't believe that the committee has ever made any specific directions regarding the organization or format, but of course it's entirely within the committee's power to do so. In my opinion, I would prefer to see the Alarms in the device sections rather than Section 7, as it is makes it much easier to keep it in synch with the rest of the text.
Is section 7.6 going to be
Is section 7.6 going to be present in the application layer anymore? It seems that alarms are going to be included in section 6 along with the DGNs so not sure if they need to also be included in section 7.6?
An Addition to
An Addition to GENERIC_ALARM_STATUS
-------------------------
Byte 6, Bits 2 to 3: Alarm for Logging (uint2)
00b - Do not log alarm now.
01b - Alarm should be logged for statistical or forensic purposes.
In general, this flag should be set only on the initial triggering of the alarm. In subsequent reports of the same alarm, this should be set to 00b, until such time as the alarm has reset and triggered again.
Byte 6, 4 to 5: Alarm for User Notification (uint2)
00b - Do not notify user.
01b - User notification required.
In general, at least one of these two flags - Alarm for Logging and/or Alarm for User Notification, should be set.
-------------------------
Justification:
These data items clarify whether an alarm is meant primarily for data collection (e.g. to obtain statistics about device performance or usage, or to allow analysis of past events) or for user interaction. Of course, some alarms may have both flags set.