В статье рассмотрена система МИС24 для мониторинга распределенных объектов и ее функциональность: от получения аварийного сигнала до уведомления ответственных сотрудников и контроля дальнейших действий. Описаны контроллеры, локальная обработка данных, личный кабинет и практические сценарии эксплуатации.
ООО «Мониторинговые информационные системы», г. Москва
![]()
Современная автоматика позволяет контролировать состояние оборудования практически непрерывно. Агент контроля фиксирует отклонение, система управления формирует сигнал, оператор получает уведомление. Дальше начинается уже другой этап работы, от которой во многом зависит оперативность устранения аварии: нужно передать информацию, создать заявку, найти исполнителя и дождаться устранения. Время от уведомления до реакции персонала на него можно назвать ахиллесовой пятой всего процесса. Поэтому в современных технических решениях наряду с АСУ применяют отдельный контур системы событийного мониторинга, чтобы свести к минимуму простой оборудования и повысить эффективность работы.
Чтобы не быть голословными, приведем данные, полученные специалистами компании «Мониторинговые информационные системы» (ООО «МИС»). Они проверили всю цепочку на предприятиях нескольких заказчиков. От момента возникновения аварии до включения в работу всех участников проходило порядка 24 часов. Казалось бы, сигнал уже есть, проблема известна. Но почему задерживается работа по ее устранению?
Значительная часть времени уходит не на техническую операцию, а на передачу информации от участника к участнику. Сначала сигнал должен попасть к ответственному сотруднику, затем превратиться в заявку, дойти до исполнителя, наконец, должна быть предоставлена обратная связь о результатах работ. Если эксплуатация распределена между несколькими подразделениями или объект обслуживает подрядная организация, таких переходов становится больше. Возникает задача, которую нельзя решить с помощью увеличения количества датчиков: кроме состояния оборудования, нужно контролировать дальнейшее продвижение самого инцидента.
На этом этапе меняется объект контроля. Наряду с неисправностью оборудования система фиксирует события, которые происходят после ее (неисправности) возникновения: кто получил сообщение, кому передана задача, соблюден ли срок реакции и закрыта ли заявка.
Что происходит с сигналом «Авария»
Если задача состоит не только в регистрации аварии, системе недостаточно собрать показания и вывести их на экран. Сигнал должен пройти несколько этапов: поступить от оборудования, претерпеть обработку, превратиться в событие, получить уровень критичности и дойти до сотрудника, который отвечает за дальнейшие действия.
Такая последовательность и заложена в архитектуре MIS24. На нижнем уровне находятся контроллеры и подключенное оборудование. Данные поступают к серверной части через MQTT-брокер, где специальный программный модуль агрегирует информацию и формирует события. За передачу уведомлений отвечает модуль информирования, который может отправлять сообщения как на электронную почту, так и в наиболее популярные мессенджеры, в том числе в МАКС.
При обработке дискретных сигналов учитывается «дребезг» сенсора агента контроля. Кроме того, для событий задаются задержки перед уведомлением, чтобы отделить кратковременное изменение состояния от сигнала, который сохраняется и требует реакции персонала.
После регистрации определяется уровень критичности события и порядок уведомления. Сообщение поступает ответственному сотруднику, и если реакция от него отсутствует, то в установленный срок информация передается на следующий уровень. Для этого используется эскалация.
На распределенных объектах особую проблему представляет потеря связи. Если канал временно недоступен, данные о событиях сохраняются локально и передаются после восстановления соединения. Сама потеря связи регистрируется отдельно, поскольку она не означает неисправности оборудования, а только фиксирует его состояние. Здесь подключаются специалисты, ответственные за работу системы мониторинга.
В итоге между уведомлением и действием появляется последовательность: получение сигнала, обработка, регистрация события, определение уровня критичности, уведомление и эскалация. Благодаря ей данные, полученные от оборудования, внедряются в рабочий процесс эксплуатационной службы.
Агенты контроля на базе контроллера и локальная обработка
Для передачи сформированного сигнала требуется определить состав аппаратных средств. Он зависит от конкретного объекта: на одном будет достаточно нескольких дискретных сигналов, на другом надо организовать сбор данных от группы устройств. В системе мониторинга МИС24 для этого используются собственные контроллеры, рассчитанные на прямое подключение к оборудованию. Базовый МИС24‑HB имеет четыре дискретных входа и два релейных выхода.
Для подключения внешних устройств предусмотрены RS‑485 и 1‑Wire, беспроводная связь работает по Wi-Fi 2,4 ГГц. В исполнении МИС24‑HBE добавлен Ethernet (рис. 1).

Рис. 1. Контроллеры системы мониторинга МИС24: а – базовое исполнение MIS24‑HB; б – МИС24‑HBE с интерфейсом Ethernet
Если количества входов недостаточно, к контроллеру подключаются модули расширения МИС24 E. Каждый оснащен четырьмя дискретными входами и тремя релейными выходами. В составе программно-аппаратного комплекса можно установить до восьми таких модулей.
Контроллер устанавливается прямо на объекте, поэтому может решать часть задач до передачи информации на сервер. Это особенно важно при нестабильной связи с удаленной площадкой: оборудование продолжает работать, а данные о событиях временно сохраняются локально.
Для более сложных задач в архитектуре МИС24 предусмотрен агент контроля – локальный вычислительный узел ARM.Local на базе Intel N100 под управлением Linux. Локальный компьютер используется на объектах, где нужна высокая производительность, которой контроллер не располагает, и сетевая архитектура требует гибкости.
Такой подход разделяет два уровня. Агенты контроля на базе контроллеров работают, как правило, с дискретными сигналами оборудования, а агент контроля на базе локального промышленного компьютера выполняет функции агента и агрегации контроля перед передачей данных дальше. При этом основная система управления объектом сохраняет свой контур, а МИС24 получает необходимые для мониторинга параметры, не вмешиваясь в работу АСУ.
Данные для службы эксплуатации
Аварийный сигнал сам по себе мало что меняет. Для эксплуатационной службы важнее, что произошло дальше: кто получил сообщение, когда заявка ушла исполнителю и чем закончилась работа. В МИС24 аварийное событие может быть связано с Service Desk и превратиться в заявку с назначенным исполнителем и сроком реакции. Дальше в истории сохраняются этапы работы с инцидентом. Это позволяет проверить информацию о самом отказе и времени его устранения. Тот же принцип работает при обслуживании оборудования подрядчиками. Если исполнитель сообщил об устранении аварии, состояние оборудования можно проверить с помощью средств телеметрии. В этом случае результат оценивается и по отметке в заявке, и по фактическим данным.
Накопленная история пригодна для анализа повторяющихся отказов. Например, сведения о неисправностях можно сопоставить с использованием запасных частей и фактической частотой выхода компонентов из строя. Для объектов с установленными сроками реакции такая статистика дополняется данными по SLA. В итоге журнал событий становится частью истории объекта. В нем остаются не только аварии, но и данные о том, как на них реагировали и чем закончились работы.
Личный кабинет и история объекта
В личном кабинете МИС24 эти сведения привязаны практически к каждому контролируемому оборудованию и в итоге – к конкретному объекту. Формируется паспорт объекта с информацией об оборудовании, параметрах мониторинга и истории событий. Данные по каждому узлу и объекту можно просматривать в виде графиков, дашбордов и отчетов (рис. 2).

Рис. 2. Система МИС24: визуализация отображения данных в рабочем кабинете (увеличить изображение)
История нужна не только для просмотра прошлых аварий. События можно сопоставлять с конкретным оборудованием и выполненными работами, видеть повторяемость неисправностей и отслеживать изменения параметров во времени. При разборе инцидента это дает возможность вернуться к состоянию объекта до и после события, не ограничиваясь текущими показаниями.
Отдельный уровень связан с правами доступа. В системе предусмотрена ролевая модель, поэтому набор доступных объектов и операций зависит от пользователя. Для предприятий с распределенной инфраструктурой можно разделять работу диспетчерской службы, инженеров и руководителей эксплуатации. Есть возможность объединять пользователей разных организаций и подразделений в группы по интересам и ответственности.
МИС24 предусматривает интеграцию с Service Desk и различными инженерными системами, также в числе направлений интеграции рассматриваются 1С и сторонние системы мониторинга (как правило, ИТ). Ведутся работы по интеграции с системами, позволяющими получить функциональность AI-помощника.
От мониторинга к анализу
Система мониторинга МИС24 работает сразу в нескольких эксплуатационных сценариях. Один из них связан с Service Desk: аварийное событие становится основанием для заявки, а данные мониторинга используются при подтверждении ее закрытия. История инцидентов при этом связывается с оборудованием и запасными частями (что способно помочь в формировании ЗИП).
Другой сценарий относится к инженерной инфраструктуре. В серверных и КПП контролируются фазы, температура, состояние ИБП и другие параметры. При необходимости в цепочку включается удаленное управление оборудованием. В ТЗ МИС24, например, описана автоматическая перезагрузка зависшего коммутатора через устройство удаленного управления.
Отдельная задача – контроль подрядчиков. Если исполнитель сообщает об устранении неисправности, результат сопоставляется с данными мониторинга. Заявка закрывается не только по отметке о выполненной работе, но и после проверки фактического состояния оборудования. Такой подход связывает телеметрию с контролем SLA.
Дальнейшее развитие системы связано с моделью объекта и аналитикой. В личном кабинете 3.0 имеется паспорт объекта, история оборудования, графики, дашборды и отчетность. На следующем этапе планируется реализовать автоматическую классификацию заявок и прогнозные показатели состояния объектов.
Опубликовано в журнале «ИСУП» № 4(124)_2026
С. Т. Крыль, генеральный директор,
ООО «Мониторинговые информационные системы», г. Москва,
тел.: +7 (495) 120‑2928,
эл. почта: infomis24.ru
Иллюстрации предоставлены ООО «Мониторинговые информационные системы»


_small.jpg)
