При обслуживании системы мониторинга часто проверяют отдельные датчики: нагревают датчик температуры, размыкают контакт двери, отключают контролируемое питание или имитируют протечку. Если состояние входа изменилось и отобразилось в интерфейсе контроллера, тест обычно считается успешным.
Однако исправный датчик ещё не гарантирует, что при реальной аварии ответственный специалист своевременно узнает о событии. Между обнаружением события и получением уведомления работают контроллер, настроенная логика, сеть передачи данных, сервер мониторинга, почтовый или мобильный оператор, а также устройство самого получателя.
Отказ или неправильная настройка любого из этих компонентов может сделать всю систему мониторинга фактически неработоспособной, несмотря на корректные показания датчиков. Поэтому проверять необходимо не отдельные устройства, а полный сценарий обработки события.
Полный путь прохождения события
Работа системы начинается с возникновения события на объекте: повышения температуры, исчезновения электропитания, появления воды, задымления или открытия двери шкафа.
Датчик фиксирует изменение параметра и передаёт сигнал контроллеру. Контроллер обрабатывает полученные данные, сравнивает их с заданными порогами или состояниями и запускает настроенный сценарий.
В зависимости от архитектуры контроллер может самостоятельно отправить Email или SMS, передать SNMP Trap, переключить реле либо направить данные на сервер мониторинга. Центральная система регистрирует полученную информацию, отображает её оператору и запускает дополнительные механизмы оповещения или эскалации.
Полный путь прохождения события показан на схеме ниже.
Рис. 1. Полный путь прохождения события в системе мониторинга.
Каждый этап этой цепочки должен быть проверен отдельно. Изменение состояния датчика подтверждает только исправность самого датчика и входа контроллера, но не всей системы мониторинга.
Что необходимо проверять
Тест следует начинать с имитации реального события. Для датчика двери можно физически открыть дверь, для контроля электропитания — безопасно отключить контролируемую линию, а для температурного мониторинга — изменить температуру в допустимых пределах либо временно скорректировать порог срабатывания.
После этого необходимо убедиться, что контроллер правильно определил новое состояние. В интерфейсе должно измениться значение датчика или дискретного входа, а событие должно получить корректный статус.
Далее оценивается работа логики. Недостаточно увидеть изменение параметра: контроллер или сервер мониторинга должен распознать аварийное состояние и запустить предусмотренный сценарий. Если используется задержка срабатывания, гистерезис или несколько связанных условий, необходимо проверить их фактическое выполнение.
Затем следует убедиться, что информация успешно передана дальше по цепочке.
При централизованной архитектуре информация о событии должна поступить в центральную систему мониторинга и корректно отобразиться с правильным временем, названием объекта и уровнем критичности. Если используется автономный контроллер, следует убедиться, что он самостоятельно сформировал и отправил предусмотренное уведомление.
После передачи информации необходимо подтвердить доставку сообщения или выполнение автоматического действия. Письмо должно появиться в почтовом ящике, SMS — поступить на телефон, SNMP Trap — быть принят системой мониторинга, а реле — фактически изменить своё состояние.
После завершения проверки необходимо проконтролировать восстановление нормального режима. Система должна зафиксировать нормализацию параметра, вернуть исполнительные выходы в предусмотренное состояние и при необходимости отправить уведомление о восстановлении.
Где может возникнуть отказ
Отказ может возникнуть практически на любом этапе обработки события. Датчик может быть исправен, но подключён к неверному входу. Контроллер может получать данные, но не запускать сценарий из-за неправильного порога, отключённого правила или ошибки в логике.
Передача события может прекратиться после изменения сетевых настроек, адреса сервера, VLAN или правил межсетевого экрана. Email-уведомления могут перестать отправляться после смены SMTP-сервера, пароля или сертификата. SMS не будут доставляться при отсутствии связи с оператором, блокировке SIM-карты или недостаточном балансе.
Даже успешно сформированное сообщение не всегда достигает нужного сотрудника. Адрес электронной почты мог измениться, письмо могло попасть в спам, а указанный номер телефона — больше не использоваться. Поэтому запись об отправке в журнале контроллера нельзя считать окончательным подтверждением работоспособности.
Рис. 2. Возможные точки отказа при прохождении события.
Проверка резервных механизмов
Если используются несколько каналов оповещения, каждый из них необходимо тестировать отдельно. Наличие Email и SMS само по себе не обеспечивает резервирование: оба канала могут зависеть от одного интернет-соединения, маршрутизатора или источника питания.
Следует проверить поведение системы при недоступности основного канала связи. Например, будет ли отправлено SMS при отсутствии доступа к SMTP-серверу, продолжит ли контроллер выполнять локальную логику при потере связи с центральной системой и сработает ли реле независимо от доступности сети.
Отдельного внимания требует резервное электропитание. При отключении основной линии должны сохранять работоспособность не только датчики и контроллер, но и коммутаторы, маршрутизаторы, GSM-модемы и другие компоненты, необходимые для доставки события.
Когда проводить проверку
Полный сценарий необходимо проверить сразу после монтажа и первоначальной настройки системы. В дальнейшем такое тестирование следует повторять после изменения порогов, логики, списка получателей, сетевых параметров, каналов оповещения, конфигурации сервера мониторинга или прошивки контроллера.
Кроме того, проверку следует выполнять после обслуживания инженерного оборудования, замены датчиков, переноса кабелей, смены SIM-карты или почтового сервиса. Даже если изменения напрямую не связаны с мониторингом, они могут затронуть питание, сеть или физическое подключение оборудования.
Для действующих объектов необходимо установить периодический регламент. Частота зависит от критичности инфраструктуры, однако тестирование должно проводиться достаточно регулярно, чтобы изменения в сети, учётных записях и составе ответственных сотрудников не оставались незамеченными до возникновения реальной аварии.
Результаты рекомендуется фиксировать: указывать дату, проверенный сценарий, время появления события, способ уведомления, фактического получателя и обнаруженные отклонения. Такой журнал позволяет подтвердить корректную работу системы и контролировать устранение выявленных проблем.
Типичные ошибки
Наиболее распространённая ошибка — считать успешным тест, при котором изменилось только состояние датчика в интерфейсе контроллера. Это не подтверждает выполнение логики и доставку уведомления.
Другая проблема — использование программных тестовых сообщений вместо имитации физического события. Проверка отправки Email или SMS подтверждает работу отдельного канала, но не затрагивает датчик, вход контроллера, пороги и сценарии обработки.
Нередко тестируется только основной канал оповещения. Резервный при этом может годами оставаться неисправным и не сработать в момент отказа основной связи.
Ещё одна типичная ошибка — отсутствие повторного тестирования после изменений. Замена почтового сервера, сетевого оборудования или ответственного сотрудника воспринимается как отдельная административная задача, хотя фактически меняет всю цепочку обработки аварийного события.
О работоспособности системы мониторинга можно говорить только тогда, когда исправно функционирует вся цепочка обработки события — от его обнаружения до получения уведомления или выполнения автоматического действия.
Полноценный тест должен начинаться с имитации физического события и завершаться подтверждением доставки сообщения, срабатывания исполнительного устройства и корректного восстановления нормального состояния.
Регулярное тестирование полного сценария позволяет выявить ошибки в настройках, проблемы каналов связи и устаревшие данные получателей до того, как произойдёт реальная авария.
Для подбора оборудования и проектирования системы мониторинга инженерной инфраструктуры можно обратиться к специалистам «Алентис Электроникс».
Отдел продаж: sales@alentis.ru
Pre-sale-консультации: pre-sales@alentis.ru
Техническая поддержка: support@netping.ru