Часто задают вопросы:«Зачем использовать решения IoT, если есть открытые системы ИТ-мониторинга Zabbix, Nagios? Эти системы давно умеют собирать и что-то показывать по TCP/IP протоколу. Достаточно всех перевести на IP адресацию.» Попробуем ответить, насколько это сложно/просто технически, дорого/дешево по затратам. Приведу одну аналогию к нашей теме.
На деловую встречу приезжают русский, китаец, француз, немец, перс и араб. Никто не разговаривает на других языках. Но проблему коммуникации надо как-то решать. Просчитаем варианты:

  • первый вариант очевиден, нанять 5 переводчиков, которые знают один общий язык.
  • второй вариант, найти одного полиглота, который знает все необходимые языки.

Очевидно, что первый вариант проще, но дороже. Второй дешевле, но сложнее, придется поискать такого полиглота. Дальше представим, что деловая встреча расширяется и есть необходимость в переводе других языков. Первый вариант становится просто «золотым», его стоимость растет пропорционально дополнительным языкам, как с точки зрения управления всеми переводчиками, так и стоимости их услуг (явная проблема с масштабированием задачи, история про Вавилонскую башню это подтверждает). Второй вариант практически неизменен, полиглоту чуть подняли ставку, но бизнес-конструкция не меняется (хорошо масштабируемое решение).

Все системы ИТ-мониторинга требуют TCP/IP и MAC адрес объекта мониторинга. Если устройство не из мира TCP/IP, его необходимо будет оснастить «переводчиком», и на сегодня это одна из основных проблем таких систем как Zabbiz или Nagios.
Платформы IoT решают проблему связи с не IP-устройствами за счет средств из архитектурного слоя «Connectivity && Normalization»(см. ссылку), в котором работают «полиглоты». Обычно, это специализированные контроллеры, либо встроенные протоколы IoT, поддерживаемые самими объектами мониторинга. У систем ИТ-мониторинга такой архитектуры нет. Nagios и Zabbix поддерживает распределенный мониторинг, при котором расставляются прокси-сервера , либо программные агенты, которые обеспечивают связь с сервером по протоколу SNMP, либо по проприетарному протоколу системы. Для того, чтобы агенты начали взаимодействовать с не IP-устройствами, придется разрабатывать для них «переводчики» и дорабатывать сервер по поддержке конфигураций и средств администрирования таких переводчиков. Это наиболее очевидная проблема, которая потребует затрат на различные шлюзы/мосты/преобразователи к различным HVAC системам и разработки кода для Zabbix.
Конечно, нет не решаемых проблем. Вот пример, как проблему мониторинга электро-счетчика решила итальянская компания Systematica, которая решила использовать сервер Zabbix (Using-Zabbix-in-an-IoT-Architecture_F.Fantoni.pdf). Компания создала специализированный контроллер, который поддерживает протокол modBus, а на стороне Zabbix создала шаблоны мониторинга с modBus командами для считывания данных с объектов мониторинга. Это типовой вариант использования Zabbix в решениях IoT и можно сделать первые выводы:

  1. Если строить мониторинг климата (поддержка протоколов ModBus, BackNet, Lora), электрики (ModBus, дискретные реле, контакторы), ИБП по RS-232 порту и т.д. с использованием систем ИТ-мониторинга, придется вложится в «переводчиков». На примере презентации, компания разработала ModBus hardware module и Modbus Zabbix loadable module (слайд 23). Чем больше таких устройств, тем больше будет затрат. Для IoT платформ такой проблемы нет, либо она существенно проще, поскольку не требует никаких изменений на уровне серверов.
  2. Zabbix не поддерживает адресацию ModBus протокола, и настройка мониторинга modBus совместимых устройств требует знания реализации протокола конкретного устройства. На примере презентации (слайд 24,25), подключаются 4 одинаковых счетчика (ID 1-4), у которых структура регистров ModBus одинакова. Но, если потребуется использовать счетчик другого производителя, у которого другая структура регистров ModBus, то придется использовать отдельный ModBus hardware module с другим IP-адресом, для которого будет реализован требуемый набор команд для счетчика другого вендора. Для IoT платформы такой проблемы в принципе не существует. Достаточно указать только номер порта, и на уровне Connectivity && Normalization контроллер подключит нужный набор команд для нового счетчика. Очевидны в Zabbix и косвенные проблемы такой ситуации: а) разбираться в командах ModBus ИТ-специалисту (например: «/dev/ttyS1 9600 N»,9,0x1518,3,l,1,0 - означает получить параметр ActivePower) на практике не реально; б) в конечном итоге, в зависимости от количества типов устройств и количества параметров, шаблоны их настроек превратятся в огромную «мусорку» команд, для поддержки которой потребуются не только ИТ-специалист, но и инженеры по каждому из устройств.

Теперь, давайте поднимемся на слой выше и рассмотрим реализацию архитектуры обработки данных (Processing && action management).

  1. IoT платформа реализует централизованный механизм ведения правил и распределенное их выполнение. Для архитектуре Zabbix и Nagios такой возможности просто не предусмотрено. В Zabbix все элементы управления (триггеры, корреляции, удаленные команды) инициируются и выполняются сервером. Почему это проблема для Zabbix среды приведу на примере: На объекте происходит сбой входного электропитания. В сценарии реагирования, должен запуститься ДГУ и система бесперебойного питания. В случае с IoT платформой, такой сценарий будет реализован на объекте его контроллером, и для этого серверу не нужна связь с контроллером, он уже все управляющие действия сделал заблаговременно. В случае с Zabbix, удаленные команды должны быть инициализированы со стороны сервера по мере срабатывания тригера и события. Вроде тоже неплохо, но есть одна не решаемая проблема - связь с сервером при сбое электропитания прервалась и сервер ничего не знает об этой ситуации.
  2. Типовые задачи управления для IoT систем, связанные с управлением объектов по расписанию для Zabbix-подобных систем потребуют разработку отдельных решений/программ. Это не специфическая задача для Zabbix, но даже если она будет решена, см. п.1, инициализация расписаний возможна будет только на сервере.
  3. Обработка параметров для IoT платформы и обработка параметров в Zabbix, Nagios это два разных подхода. IoT платформа поддерживает обработку значений как на контроллере, так и на сервере, выполняет преобразование данных от различных параметров, создает на основе обработки параметров новые (вычисляемые) параметры, агрегирует любые параметры за любой срок сбора с учетом природы поведения параметра. Системы ИТ-мониторинга в основном поддерживают два механизма обработки: создание вычисляемых параметров и агрегация параметров группы хостов по значениям min, max, avg. И здесь есть как минимум две проблемы: а) природа параметров HVAC систем самая разная, и для параметров с нарастающим итогом значения min,max,avg просто не применимы, как это ограничение обойти в Zabbix - предмет отдельного проекта, б) агрегация по группировке хостов означает, что если у меня на удаленном агенте мониторятся 10 счетчиков ModBus, все они попадут в группу хостов и будут агрегироваться. Но только 2 счетчика из 10 являются Вводами на объект (для примера), и требуется агрегация только этих двух счетчиков. Придется выносить эти два счетчика на отдельный агент zabbix и приобретать для них контроллер ModBus hardware module (на примере презентации).


Третий важный аспект, который является безусловным преимуществом Iot платформ - это унификация протоколов обмена и взаимодействия между собой. Обычно IoT среда использует MQTT либо HTTP. Одним из основных принципов технологии IoT является возможность предоставления данных многим потребителям, которые заинтересованы в получении информации от IoT объектов. Использование унифицированных протоколов в качестве среды обмена реализуют этот принцип. Для корпоративных сред, это существенно снижает риски и затраты на интеграции и масштабировании систем. Системы ИТ-мониторинга (Zabbix, Nagios)) для обмена в распределенной среде используют проприетарные протоколы обмена агент-сервер. По сравнению с IoT системами это сильно сужает варианты интеграций - все интеграции необходимо выполнять только через основной сервер мониторинга, и делает сложным и дорогостоящим модернизацию или замену Zabbix, поскольку придется заново проходить путь по разработке «переводчиков».

Теперь обратимся к такому важному аспекту как «Data Visualization». Разберем этот вопрос на примере возможностей Zabbix, которые поддерживает набор виджетов, и возможность построения Панелей, Комплексных экранов из виджетов. Выглядит это вот так: https://www.zabbix.com/ru/screenshots. Эта реализация лучше , чем у Nagios, но ее недостаточно для создания дашей для операторов, диспетчеров, руководителей, которые должны смотреть на экраны близкие к бизнес представлению HVAC систем:

  1. Все представления Zabbix построены на виджетах График и Таблица. График поддерживает линейный тип для всех единиц измерения и пайп для единицы размерности объем в байтах. Но, в мире инженерных систем используется намного более широкий диапазон единиц измерения, и требуется их представления в самых разных вариантах.
  2. Нельзя расширить набор виджетов Zabbix, этот набор расширяется в ядре. Нельзя воспользоваться API для того того, чтобы созданный комплексный экран вызвать во внешней системе. API поддерживает только работу с данными.
  3. Нет виджетов с возможностью управления. Задать значение параметру объекта можно только с помощью административных функций Zabbix. Например, если оператору потребуется выключить свет, или открыть дверь, в Zabbix через уровень представления этого сделать нельзя. В отличие от IoT платформ.


В заключении, отметим:

  1. Мониторинг IoT среды с помощью платформ Zabbix, Nagios не бесплатен. Любая оценка в денежном выражении субъективна, но с точки зрения времени и трудозатрат, это точно намного дольше и в разы сложнее, чем использование IoT платформы.
  2. Для больших систем с порядком больше тысячи устройств, поддержка шаблонов мониторинга в ИТ-системах потребует от специалистов компетенций в области HVAC систем, сопровождать такие конфигурации в Zabbix будет сложно и трудоемко.
  3. Системы ИТ-мониторинга плохо масштабируемы для среды IoT устройств. IoT платформа, за счет унификации протоколов обмена и использования протоокла MQTT поддерживают высокую масштабируемость, с простыми и прозрачными инструментами интеграций для внешних систем. С учетом ограничений Zabbix по удаленному управлению, для критичных объектов, где необходима гарантированная передача сигналов при возникновении события за секунды, системы на базе Zabbix просто не применимы.
  4. Компания Zabbix на своих ресурсах не приводит ни одного успешного проекта в области мониторинга HVAC или IoT систем. Специализация продукта и его развитие (см. https://www.zabbix.com/ru/roadmap) направлена в ИТ-мир. Нужно ли повторять опыт строительства Вавилонской башни - вопрос очевиден.