У крупных компаний редко возникает задача создать систему мониторинга с нуля. Чаще приходится дорабатывать уже существующую инфраструктуру: добавлять сигналы, подключать новые объекты и решать проблемы, которые раньше никто не предполагал.
В этой статье расскажем о двух подобных кейсах на совсем разных площадках: телеком-оператора и пассажирского перевозчика.
Введение
С компанией ЦОДУМ наши читатели уже знакомы — ранее мы рассказывали о нескольких их внедрениях. Сегодня компания использует типовые программно-аппаратные комплексы (ПАК) собственной разработки, которые адаптирует под задачи заказчиков.
В основе ПАК — контроллер Wiren Board 7 с модулями ввода-вывода в зависимости от конфигурации объекта. На контроллер установлен софт Smart DCIM от ЦОДУМ.
Кейс №1: телеком
У заказчика — крупного телеком-оператора — уже работала система мониторинга с поддержкой SNMP-трапов.
Почему выбрали именно SNMP
Для крупных инфраструктур важны не столько возможности нового оборудования, сколько стоимость его интеграции. Если система мониторинга уже принимает SNMP-уведомления, логичнее использовать существующий механизм, чем внедрять новый протокол обмена. В этом случае изменения затрагивают только уровень сбора сигналов, а система верхнего уровня продолжает работать без доработок.
Что такое SNMP-трапы
SNMP-трап — это уведомление, которое устройство самостоятельно отправляет в систему мониторинга при наступлении определенного события. В отличие от обычного опроса по SNMP, когда сервер периодически запрашивает состояние оборудования, трап отправляется сразу после изменения состояния.
Например, если сработал автоматический выключатель, открылась дверь шкафа или пропало питание, контроллер формирует SNMP-трап и передает его в систему мониторинга. Это позволяет практически мгновенно узнать о событии, не дожидаясь очередного цикла опроса.
В эксплуатации находилось более 150 объектов, построенных в разные годы и оснащенных оборудованием различных поколений. Со временем возможностей существующей системы стало недостаточно, поскольку значительная часть дискретных сигналов ей не обрабатывалось. Заказчику требовалось организовать контроль состояния дверей, шкафов, окон, автоматических выключателей, цепей питания и других инженерных систем.
Задачу сформулировали просто: преобразовать дискретные сигналы в SNMP-трапы и передавать их в существующую систему мониторинга.
Источники дискретных сигналов подключили к модулям WBIO-DI-WD-14. При изменении состояния контролируемого входа ПАК формирует SNMP-трап и передает его в систему верхнего уровня. Особенность решения заключается в том, что для каждого сигнала можно задать текстовое описание, которое передается в составе SNMP-трапа.
В качестве примера рассмотрим интеграцию дизель-генераторной установки (ДГУ). От одной ДГУ снимают множество сигналов: пустой топливный бак, открытая дверь, сработавший автоматический выключатель в щите, открытая дверца щита, протечка, состояние жалюзи, аккумуляторов и окна... Источники сигналов подключают к дискретным входам ПАК.
ПАК подключают к сети передачи данных оператора (вопросы организации связи между оборудованием и защиты каналов связи находятся в зоне ответственности специалистов заказчика) и задача решена.
Поскольку решение использует стандартные SNMP-трапы, ПАК легко интегрируется в существующую инфраструктуру и совместим с любыми системами мониторинга, которые поддерживают SNMP.
А если SNMP-трап потеряется?
Классические SNMP-трапы передаются по UDP и не предусматривают подтверждения доставки. Если пакет потеряется в сети, отправитель об этом не узнает.
На практике эту проблему обычно решают не на уровне протокола, а на уровне архитектуры системы. В проекте ЦОДУМ каждое событие одновременно отправляют на два адреса системы мониторинга, что снижает вероятность потери уведомления. Кроме того, система мониторинга контролирует наличие периодических служебных сообщений (heartbeat). Если они перестают приходить, это само по себе считается событием и указывает на возможную проблему со связью или работой устройства.
Такой подход не гарантирует доставку каждого отдельного SNMP-трапа, но позволяет своевременно обнаружить потерю связи и существенно повысить надежность мониторинга.
После внедрения сигналы с площадок начали поступать в централизованную систему мониторинга в унифицированном виде за счет единых названий сигналов.
Дополнительные фото
Кейс №2: пассажирский перевозчик
Следующим клиентом стала компания, которая занимается пассажирскими перевозками. На конечных станциях маршрутов транспортные средства должны отмечаться в системе, для чего используется специальное оборудование. К нему подведены питание и канал связи.
Основная проблема заключалась в том, что без отметки транспорт не имеет права выйти на линию. А канал связи с сервером работал нестабильно. При отсутствии связи было невозможно удаленно определить причину: отключилось питание на площадке, или возникла проблема на стороне оператора связи. Чтобы разобраться в ситуации, приходилось отправлять инженера на объект, и каждый такой выезд увеличивал затраты.
Дополнительную сложность создавало каналообразующее оборудование, которое периодически зависало. Требовалась возможность его перезапуска по питанию, что, как правило, восстанавливало работоспособность.
Такие устройства существуют уже давно
Задача собрать дискретные сигналы с объекта и передать их в систему мониторинга давно не является уникальной. Для этого существуют специализированные устройства — удаленные модули ввода-вывода (remote I/O) и шлюзы мониторинга.
Большинство таких устройств умеют принимать сигналы от «сухих контактов», контролировать состояние дискретных входов и отправлять уведомления по SNMP. Например, аналогичные решения выпускают AKCP, Advantech, Moxa, HW group и другие производители промышленного оборудования.
На практике различия между такими решениями обычно заключаются не в самой возможности отправлять SNMP-трапы. Гораздо важнее, насколько устройство можно адаптировать под конкретную инфраструктуру: использовать принятую у заказчика систему именования сигналов, реализовать локальную логику обработки событий, обеспечить резервирование каналов связи или выполнить необходимые действия при возникновении аварий.
Для решения этих задач также использовали ПАК, но уже с расширенной функциональностью. В отличие от первого решения он не ограничивается передачей событий в систему мониторинга, а выполняет действия непосредственно на площадке.
Основная задача комплекса — определить причину пропадания связи и попытаться восстановить ее без выезда на объект. При потере основного канала система сразу пытается передать уведомление через резервный канал связи. Затем она проверяет наличие электропитания с помощью модуля WBIO-DI-HVD-16 и при необходимости перезапускает каналообразующее оборудование через реле WB-MR3LV/I. Все выполненные действия и их результаты также передаются в систему мониторинга.
Для работы на площадке предусмотрели локальный интерфейс. Через него инженер может посмотреть текущее состояние системы и историю событий. В диспетчерской используют карту объектов, на которой отображается общее состояние площадок. При необходимости оператор может перейти к конкретному ПАК и получить подробную информацию.
В качестве резервного канала используют мобильный Интернет. В контроллер Wiren Board устанавливают GSM-модем, через который поднимается защищенное соединение с сервером системы мониторинга Smart DCIM. На самом контроллере работает клиент Smart DCIM.
Дополнительные фото
Заключение
Оба проекта были реализованы на одной аппаратной платформе Wiren Board, однако решали принципиально разные задачи.
В одном случае требовалось интегрировать большое количество дискретных сигналов в уже существующую систему мониторинга без изменения ее архитектуры. В другом — организовать удаленную диагностику объектов и выполнять простые управляющие действия непосредственно на площадке.
На рынке есть готовые SNMP-шлюзы и удаленные I/O-модули для таких задач. Решение ЦОДУМ отличается возможностью адаптировать ПАК под задачи самых разных объектов.
