В обмене данными при обработке алармов и событий применяются специальные типы объектов. Их отличие заключается в отклике на событие, который представляет собой переход в заданное заранее состояния с указанными критериями. Событие способно запускать заданные действия или может просто регистрироваться, например, в журнале работы или алармов. Событие также может представлять собой состояние, которое запускает аларм, который требует подтверждения пользователя.

В BACnet существуют два механизма создания алармов и событий.

Первый — внутренняя сигнализация. Он зависит от внутренних свойств объекта, которые составляют основу мониторинга события или аларма.

Второй механизм — алгоритмическая сигнализация. Сигнализация на основе правил в функциональном отношении сложнее, т. к. основана на объекте дополнительной регистрации событий.
 

Драйвер BACnet на «КАСКАД Цифра» может принимать сигналы об алармах (UnconfirmedEventNotification, ConfirmedEventNotification) от устройства BACnet. В настоящее время драйвер BACnet поддерживает только внутреннюю сигнализацию, т. к. на настоящий момент объекты с EventEnrollment не поддерживаются.

В данном разделе описывается правильная обработка аларма BACnet в «КАСКАД Цифра», включая его квитирование. Конечно, пользователь также имеет возможность обычным способом считывать Event_State и настраивать конфигурационный элемент обработки алармов на прием в элемент точки данных. В этом случае обработка алармов происходит независимо от устройства BACnet и только в «КАСКАД Цифра».

• Необходимые условия приема алармов BACnet
• Объект внутренней сигнализации
• Класс уведомлений
• Сопоставление алармов BACnet и «КАСКАД Цифра» «КАСКАД Цифра»
• Информация об алармах BACnet
• Содержание дополнительных значений алармов
• Квитирование алармов
• Информация о квитировании
• Связь между классами уведомлений (NOC) классами алармов «КАСКАД Цифра»
• Сопоставление приоритета аларма для драйвера BACnet
• Общий запрос аларма

Необходимые условия приема алармов BACnet

Для приема алармов/событий BACnet в соответствующих объектах BACnet должны присутствовать налдежащие настройки. Для внутренних алармов следует учитывать два объекта. Превый — объект, поддерживающий внутреннюю сигнализацию (например, объект аналоговых входных данных — BACnet_AI). Второй — объект класса уведомлений (NOC — Notification Class object). Далее описываются настройки, касающиеся алармов.

Объект внутренней сигнализации

В этом объекте соответствующий события должны быть разрешены путем изменения соответствующего свойства Event_Enable property. События (TO_OFFNORMAL, TO_FAULT и TO_NORMAL) могут быть разрешены по-отдельности. Для правильной работы с «КАСКАД Цифра» не допускается разрешать, к примеру, только TO_OFFNORMAL, без TO_NORMAL. Потому что в этом случае «КАСКАД Цифра» будет получать входящие алармы, но не будет получать исходящие алармы. В таблице ниже приводится список других доступных настроек.

TO_OFFNORMAL	TO_FAULT	TO_NORMAL	Описание
0	0	0	События не принимаются
1	0	1	Принимаются только события OFFNORMAL.
0	1	1	Принимаются только события FAULT.
1	1	1	Принимаются события OFFNORMAL и FAULT.

Кроме того, должен быть задан правильный объект класса уведомлений через свойство Notification_Class. Свойство должно указывать на действующий объект класса уведомлений.

Класс уведомлений

В связанном объекте класса уведомлений драйвер должны быть добавлен в список получателей, т. к. устройство BACnet отправляет уведомления только получателем из этого списка. Для резервированного проекта «КАСКАД Цифра» оба драйвера BACnet на 2 серверах также должны быть добавлены в список. Класс уведомлений определяет приоритет BACnet для событий, а также необходимость квитирования алармов. В свойстве Recipient_List пользователь может выбрать, какие службы использовать: неподтвержденные или подтвержденные, либо задать интервалы времени, когда получатели будут доступны. Дополнительную информацию см. в разделе «BACnet_NOC» в справке к приложению BACnet (<путь_КАСКАД>\BACnet_<version>\help).

Сопоставление алармов BACnet и «КАСКАД Цифра»

Для обработки алармов BACnet в «КАСКАД Цифра» нужны два правильно настроенных конфигурационных элемента: _address (адрес периферии) и _alert_hdl (обработка алармов).

В конфигурационном элементе _address выбирается, по какому элементу точки данных передается аларм. Для сопоставления используется обычный адрес периферии со свойством Event_State. Для приема режим этого адреса должен быть переключен на Alarm (Аларм).

Рисунок. адрес периферии BACnet со свойством Event_State

Для внутренних алармов в свойстве Event_State допускается только режим приема Alarm (Аларм).

Второй необходимый конфигурационный элемент — это элемент _alert_hdl. Он должен быть настроен на тот же элементы точки данных (свойство Event_State), что и конфигурационный элемент _address. Этот конфигурационный элемент _alert_hdl должен относиться к типу многоэкземплярных (информацию о многоэкземплярных алармах см. в п. Обработка алармов для многоэкземплярных алармов).

Информация об алармах BACnet

Информация в полученном уведомлении о событии может быть следующей:

Information field (Информационное поле)	Описание
Идентификатор процесса	Это значение, заданное в свойстве класса уведомлений Recipient_List. В настоящее время это значение не проверяется в «КАСКАД Цифра» при получении уведомления о событии. Однако важно, чтобы для квитирования аларма использовалось то же значение. Поэтому необходимо, чтобы идентификатор процесса, заданный в Recipient_List, совпадал с тем, который использует драйвер для квитирования (запись processIdentifier в файле config).
Initiating Device Identifier (Инициирующий идентификатор устройства)	Часть адреса периферии. Определяет, на кокой элемент точки данных направляется аларм.
Event Object Identifier (Идентификатор объекта события)	Часть адреса периферии. Определяет, на какой элемент точки данных направляется аларм.
Класс уведомлений	Не сопоставляется «КАСКАД Цифра».
Метка времени	Этой меткой времени аларм запускается в «КАСКАД Цифра», если это время, а не номер последовательности.Метка времени необходима для последующего квитирования.
Priority	В «КАСКАД Цифра» приоритет задается в классе аларма. Поэтому между приоритетом BACnet и классами алармов «КАСКАД Цифра» существует сопоставление (см. раздел «Сопоставление приоритета аларма» ниже). С помощью этого сопоставления, в зависимости от приоритета BACnet, выбирается нужный класс алармов «КАСКАД Цифра». Исходный приоритет BACnet сопоставляется _alert_hdl.._add_value_3.
Event Type (Тип событий)	Тип событий зависит от типа объекта. Он сопоставляется атрибуту аларма _alert_hdl.._add_value_6. Этот параметр указывает, какой тип события был получен, это может быть, к примеру, изменение-битовой-строки (0), изменение-состояния (1), изменение-значения (2).В зависимости от типа события, разные дополнительные данные о событии сопоставляются дополнительным значениям (см. раздел «Содержимое дополнительных значений алармов» ниже).
Message Text (Текст сообщения)	Сопоставляется с _alert_hdl.._add_value_2.
Notify Type (Тип уведомления)	Это может быть ALARM, EVENT или ACK_NOTIFICATION. Информация для внутреннего использования в целях включения, выключения или квитирования аларма.В «КАСКАД Цифра» нет разницы между типами уведомлений ALARM и EVENT. Оба обрабатываются одинаково. Аларм издается для обоих типов.ACK_NOTIFICATION квитирует аларм «КАСКАД Цифра».
AckRequired (Требуется квитирование)	Этот параметр определяет, требует ли событие квитирования.Это параметр только для внутреннего использования.
From State (Состояние «из»)	Это параметр только для внутреннего использования.
To State (Состояние «в»)	Задать для элемента точки данных _original.._value адрес свойства Event_State.Это поле содержит текущее значение свойства Event_State. Оно также записано в _alert_hdl.._add_value_1.Например, для двоичных входных данных новое состояние события может быть OFFNORMAL.
Event Values (Значения событий)	Значения событий зависят от объекта, отправки аларма и типа событий BACnet.Эти значения сопоставляются атрибуту _add_values, как описано в следующем разделе «Содержание дополнительных значений алармов»).

Подтверждение для ConfirmedEventNotification производится в драйвере автоматически. У пользователя нет возможности непосредственного подтверждения.

Содержание дополнительных значений алармов

С помощью обработки алармов для многоэкзеплярных адармов можно хранить различные параметры событий по дополнительным значениям и возвращать их (информацию по дополнительным значениям см. в п. Дополнительные значения, а по атрибутам конфигурационного элемента для дополнительных значений см. _alert_hdl). Текущие сопоставления приведены в следующей таблице:

Атрибут (типа config _alert_hdl)	Значения событий BACnet
_add_value_1	Текущее значение Event_State
_add_value_2	Сообщение о событии BACnet
_add_value_3	Приоритет BACnet
_add_value_4	Зарезервировано
_add_value_5	Зарезервировано
_add_value_6	Тип события BACnet (значение этого поля определяет, как должны интерпретироваться указанные ниже поля)
_add_value_7	OUT_OF_RANGE: флаги состоянийCOMMAND_FAILURE: флаги состоянийCHANGE_OF_STATE: флаги состоянийUNSIGNED_RANGE: флаги состояний
_add_value_8	OUT_OF_RANGE: значение вне диапазонаCOMMAND_FAILURE: значение командыCHANGE_OF_STATE: тип изменения состоянияUNSIGNED_RANGE: значение вне диапазона
_add_value_9	OUT_OF_RANGE: зона нечувствительностиCOMMAND_FAILURE: значение обратной связиCHANGE_OF_STATE: новое значение состоянияUNSIGNED_RANGE: пусто
_add_value_10	OUT_OF_RANGE: превышение предельного значенияCOMMAND_FAILURE: пустоCHANGE_OF_STATE: пустоUNSIGNED_RANGE: превышение предельного значения

Квитирование алармов

Квитирование алармов в этом разделе означает надлежащее квитирование в системе BACnet. Это значит:

Аларм квитируется в «КАСКАД Цифра», если он квитирован на устройстве. Поэтому состояние квитирования на устройстве и в «КАСКАД Цифра» должны соответствовать.

Конечно, пользователь может разделить квитирование в BACnet и «КАСКАД Цифра» средствами настройки. В этом разделе описываются различные проблемы, которые следует учитывать в отношении квитирования.

В обычном случае аларм квитируется напрямую в «КАСКАД Цифра», это означает, что интерфейс пользователя отправляет сообщение в менеджер событий «КАСКАД Цифра» для квитирования аларма. Если квитирование должно происходить также и в устройстве, в устройство сначала должно быть отправлено сообщение. И, если драйвер получит подтверждение от устройства о том, что аларм был квитирован, он будет квитирован и в «КАСКАД Цифра». For the latter case alert classes have been defined for external acknowledgement. Чтобы включить классы алармов, задайте следующую запись в файле config:

[driver]

driverAckClassPrefix = «BACnet»

Эта запись сообщает интерфейсу пользователя не квитировать напрямую аларм с префиксом класса алармов «BACnet», а задать специальную внутреннюю точку данных драйвера, которая позволит отравить сообщение с квитанцией на устройство BACnet.

Информация о квитировании

Для квитирования аларма драйверу нужна информация об аларме. Эта информация хранится в идентификаторе AlertID, который дарйвер использует для идентификации алармов. AlertID используется драйвером во внутренних целях, и пользователю он не нужен.

В службе есть некоторая информация для квитирования, приведенная в следующей таблице. Элементы, выделенные жирным, должны соответствовать друг другу для уникальной идентификации уведомлений о событиях. Если этот параметр не будет совпадать в точности, устройство издаст ошибку «Inconsistent Parameter» (Нарушение целостности параметра), и квитирования не произойдет.

Идентификатор процесса квитирования	Идентификатор процесса в телеграмме квитирования должен соответствовать идентификатору процесса в уведомлении. Это означает, что идентификатор процесса в списке получателей в NOC должен соответствовать идентификатору процесса в драйвере.
Event Object Identifier (Идентификатор объекта события)	Берется из соответствующего адреса периферии.
Состояние квитирования события	Значение состояния события.
Метка времени	Должна быть исходной меткой времени аларма. Исходная метка времени также может быть порядковым номером.
Источник квитирования	Пользователь, выполняющий квитирование (используется стандартное значение BACnet API).
Время квитирования	Время квитирования аларма (используется стандартное значение BACnet API).

Связь между классами уведомлений (NOC) классами алармов «КАСКАД Цифра»

В BACnet NOC определяет модель состояния аларма. В «КАСКАД Цифра» модель определяется по классу аларма (см. _alert_class (класс аларма)). Эти модели не независимы. Поэтому для правильной обработки алармов они должны быть настроены соответственно. В BACnet NOC существуют свойства priority и Ack_Required. Свойство Ack_Required определяет, какое преобразование (TO_OFFNORMAL, TO_FAULT, TO_NORMAL) должно быть квитировано, а какое нет. BACnet NOC и класс аларма «КАСКАД Цифра» зависят друг от друга.

Сопоставление приоритета аларма для драйвера BACnet

На настоящий момент класс аларма «КАСКАД Цифра» наследуется из приоритета BACnet. Сопоставление может быть задано в панели Alarm priority mapping (Сопоставление приоритера аларма), пункт System management (Управление системой) -> BACnet -> BACnet Alarm priority mapping (Сопоставление приоритетов алармов BACnet). При правильном сопоставлении приоритета аларма «КАСКАД Цифра» приоритет аларма будет соответствовать приоритету BACnet.

ПРИМЕЧАНИЕ

Чтобы вкладка «BACnet» была видимой в управлении системой, подпроект BACnet должен быть предварительно интегрирован в проект «КАСКАД Цифра». Дополнительную информацию см. в разделе «Встраивание и настройка библиотеки объектов» в BACnet.chm в <путь_КАСКАД>/BACnet_<версия>/help/.

Рисунок. сопоставление приоритетов алармов BACnet

Это сопоставление происходит в точке данных драйвера и сохраняется в элементе внутренней точки данных _Bacnet_<номер драйвера>.Config.AlarmPrioMapping. Если сопоставление было задано для устройства BACnet (элемент точки данных _BacnetDevice.AlarmPrioMapping) в панели конфигурации драйвера BACnet, оно используется в первую очередь. В противном случае применяется сопоставление, заданное в драйвере. Оба элемента точки данных типа dyn_string, а формат хранимого сопоставления имеет вид:

Priority1 AlertClass1

Priority2 AlertClass2

Priority3 AlertClass3

…

Это значит, что AlertClass1 «КАСКАД Цифра» используется для приоритетов BACnet от Priority1 до Priority2 — 1 и т. д. Последний диапазон простирается до самого большого значения свойства BACnet — 255.

Не каждый тип квитирования «КАСКАД Цифра» может использоваться для настроек свойства NOC Ack_Required, или он не имеет смысла, если необходимо достичь ожидаемого поведения. В следующей таблице приводится обзор комбинаций настроек для свойства NOC Ack_Required и типов квитирования «КАСКАД Цифра». В этой таблице показано только преобразование TO_OFFNORMAL. То же самое касается преобразования TO_FAULT.

	Без квитирования	Удаление квитированием	Аларм «CAME» квитируется	ВХОДЯЩИЙ или ИСХОДЯЩИЙ требует квитирования	ВХОДЯЩИЙ и ИСХОДЯЩИЙ квитируются по отдельности
AckRequired:TO_OFFNORMAL =0TO_NORMAL =0	OK	Не разрешается	OK	OK	OK
AckRequired:TO_OFFNORMAL =1TO_NORMAL =0	Не разрешается	Не разрешается	Не разрешается	Частично разрешается	OK
AckRequired:TO_OFFNORMAL =0TO_NORMAL =1	Не разрешается	Не разрешается	Не разрешается	Частично разрешается	OK
AckRequired:TO_OFFNORMAL =1TO_NORMAL =1	Не разрешается	Не разрешается	Не разрешается	Не разрешается	OK

Квитирование алармов BACnet происходит на панели алармов и событий в «КАСКАД Цифра» Alert and event panel. Таким образом, аларм должен быть видимым и квитируемым для того чтобы быть квитированным в устройстве. Например, не допускается использовать Не квитируемый в «КАСКАД Цифра» тип аларма, если аларм BACnet ожидает какого-либо квитирования. В этом случае неквитированные преобразования остаются в устройстве.

Тип При квитировании удаляется не должен использоваться, т. к. он не соответствует модели аларма BACnet, при которой алармы никогда не поступают на квитирование.

Режим ВХОДЯЩИЙ допускает квитирование не должен использоваться для алармов, требующих квитирования в устройстве, т. к. в устройстве аларм все равно требует квитирования в случае, если аларм уже ушел.

Тип ВХОДЯЩИЙ или ИСХОДЯЩИЙ требует квитирования должен использоваться в тех случаях, когда для одного преобразования в устройстве требуется квитирования, т. к. если будет квитировано другое преобразование в «КАСКАД Цифра», аларму будет удален в «КАСКАД Цифра», а в устройстве останется неквитированный аларм. Это происходит потому, что устройства BACnet не могут квитировать тип «ВХОДЯЩИЙ или ИСХОДЯЩИЙ», а только «ВХОДЯЩИЙ», «ИСХОДЯЩИЙ» или «ВХОДЯЩИЙ и ИСХОДЯЩИЙ».

ПРИМЕЧАНИЕ

В случае сочетания режима класса аларма «ВХОДЯЩИЙ или ИСХОДЯЩИЙ требует квитирования» и класса уведомлений BACnet «AckRequired: TO_OFFNORMAL=1, TO_NORMAL=0» может случиться так, что алармы не будут квитироваться в устройстве, если они квитированы в неправильном порядке (ИСХОДЯЩИЙ прежде чем ВХОДЯЩИЙ).
Этого можно избежать, задав запись alarmExternAckFirst=1 в файле config в разделе [bacnet]. Благодаря этой записи, преобразование, требующее внешнего квитирования, будет квитироваться первым. Это гарантия квитирования в устройстве. Однако рекомендуется задавать эту запись только в случае, если это сочетание действительно необходимо в проекте.

В общем случае не допускается применять параметр Acknowledge old alarms (Квитировать старые алармы) в классе алармов «КАСКАД Цифра», т. к. старые алармы не могут квитироваться в устройстве BACnet.

Общий запрос аларма

Важная проблема, которая возникает при сопоставлении алармов BACnet и «КАСКАД Цифра», состоит в синхронизации состояния аларма в конкретных точках. Например, если драйвер потерял подключение к устройству, и после его восстановления должен быть правильно указано состояние аларма.

С этой целью драйвер использует службу GetEventInformation для получения состояния аларма в подобных случаях. Служба GetEventInformation используется потому, что возвращает всю необходимую информацию об устройстве. Получение состояния аларма далее называется общим запросом событий. В ходе общего запроса событий драйвер синхронизирует состояние аларма между устройством и «КАСКАД Цифра». Это означает, что все алармы, существующие только в «КАСКАД Цифра», а не в устройстве, удаляются, а при наличии алармов в устройстве, но не в «КАСКАД Цифра», они выпускаются в «КАСКАД Цифра». Если состояние аларма не отличается, ничего не происходит.

Драйвер выполняет автоматический общий запрос событий в следующих случаях:

• Подключение к устройству;
• Переключение резервирования

Общий запрос также запускается вручную на устройстве через элемент точки данных _Bacnet_Device.Command.GQ. Поэтому в элементе точки данных должно быть указано правильное значение (см. Описание внутренней точки данных).

Если служба GetEventInformation не поддерживается устройством, драйвер попытается использовать службу GetEnrolmentSummary и, если она тоже отсутствует, он использует GetAlarmSummary. Обе альтернативы имеют некоторые недостатки по сравнению с GetEventInformation. Они описываются далее.

GetEnrolmentSummary

Эта служба требует повторного запуска для получения списка активных условий. Сначала считываются все неквитированные алармы, а затем все алармы в состоянии ACTIVE. Так происходит потому, что служба не может получить все активные и неквитированные алармы за один вызов. Затем, чтобы заполнить всю необходимую для синхронизации алармов информацию, драйвер должен считать свойства Event_Time_Stamps и Acked_Transitions.

GetAlarmSummary

Эта служба возвращает только все активные алармы и работает только для алармов типа Notify_Type. Поэтому объекты не должны иметь события типа Notify_Type, т. к. иначе служба GetAlarmSummary не вернет активных алармов. Более того, она не возвращает неквитированные состояния, если текущее состояние — NORMAL. По этим причинам служба GetAlarmSummary — плохая альтернатива для синхронизации состояний алармов и бывает поолезна в редких практических случаях.