Разработка и тестирование системы автоматизированного обнаружения и управления инженерными устройствами на базе предиктивной аналитики

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

Развитие автоматизированных систем управления в последние годы всё больше связано с внедрением интеллектуальных методов анализа данных. Если ранее управление сводилось к фиксированным сценариям работы оборудования, то сегодня на первый план выходят предиктивные алгоритмы, опирающиеся на технологии машинного обучения, искусственного интеллекта и анализа больших данных. Такие алгоритмы позволяют не только регистрировать сбои, но и прогнозировать возможные отказы оборудования, заранее планировать ремонтные работы, оптимизировать потребление энергии и тем самым снижать эксплуатационные расходы. В результате управление зданием становится не реактивным, а упреждающим, что существенно повышает его устойчивость и экономическую эффективность.

Тем не менее одной из главных проблем остаётся неоднородность протоколов обмена данными между устройствами. На практике применяются различные стандарты — BACnet IP, Modbus TCP, MQTT и Bus77. Каждый из них эффективен в своей области, но их сосуществование приводит к тому, что инженерные системы часто остаются разобщёнными. Отсутствие универсального инструмента, способного комплексно объединить данные протоколы в рамках одной платформы мониторинга, серьёзно ограничивает потенциал интеллектуального управления.

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

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

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

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

Основные направления применения предиктивных алгоритмов включают:

- Предиктивное техническое обслуживание — анализ показаний датчиков (температура, вибрация, давление и др.) для прогнозирования вероятности отказа узлов и перехода от планового обслуживания к обслуживанию по состоянию.

- Модели прогнозирования энергопотребления — выявление закономерностей и аномалий в использовании ресурсов (электроэнергия, вода, тепло), формирование оптимальных графиков работы оборудования с учётом сезонности и внешних факторов.

- Аналитика аномалий и выявление сбоев — применение методов машинного обучения для обнаружения отклонений в работе систем в реальном времени.

- Прогнозирование нагрузок и климат-контроль — управление системами отопления, вентиляции и кондиционирования на основе прогнозируемых сценариев использования помещений.

Принцип работы предиктивной аналитики строится на пяти этапах:

1. Сбор и агрегация данных с датчиков и систем здания.

2. Обработка информации статистическими и интеллектуальными методами.

3. Построение прогнозных моделей и выявление закономерностей.

4. Генерация рекомендаций для операторов или автоматизированное управление оборудованием.

5. Постоянное уточнение моделей на основе новых данных.

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

[5]

.

Рисунок 1 - Диаграмма этапов развития на пути к «цифровой зрелости»

DOI:10.60797/IRJ.2025.160.72.1

Таким образом, при проектировании модульного сервиса мониторинга необходимо учитывать уровень цифровой зрелости предприятия. На базовом этапе ключевой задачей является организация сбора и визуализации данных с оборудования. По мере роста зрелости возрастают требования к интеграции разнородных подсистем, масштабируемости и применению аналитических инструментов.

Не менее важным фактором является готовность к внедрению предиктивной аналитики: именно она позволяет перейти от простого контроля текущего состояния к прогнозированию отказов и автоматизации принятия решений. В модели (рисунок 2) этот процесс отражён как движение от нижнего уровня, связанного с регистрацией данных, к верхнему уровню, где центральную роль играет интеллектуальная поддержка управления

[6]

.

Рисунок 2 - Оценка готовности к системе предиктивной аналитики

DOI:10.60797/IRJ.2025.160.72.2

Для модульного сервиса мониторинга это означает, что его архитектура должна быть построена так, чтобы поддерживать все уровни зрелости:

- на начальных этапах — обеспечивать сбор и агрегацию информации из разных протоколов (BACnet IP, Modbus TCP, MQTT, Bus77)

- на среднем уровне — предоставлять инструменты для анализа и выявления аномалий;

- на продвинутом уровне — интегрироваться с системами поддержки принятия решений и предиктивной аналитикой.

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

На практике нередко встречаются ситуации, когда сбор данных уже частично реализован, но документально не зафиксирован. В подобных случаях следы обмена информацией можно обнаружить в сетевых пакетах локальной вычислительной сети. Это открывает возможность использования протоколов TCP/IP как источника данных о функционировании систем без необходимости дооснащения оборудования

При этом, несмотря на наличие большого числа специализированных сканеров и утилит, до сих пор отсутствуют универсальные инструменты, обеспечивающие комплексное обнаружение всех сетевых узлов и устройств, работающих по различным протоколам. Именно эта проблема формирует практическую задачу, решаемую разрабатываемым модульным сервисом мониторинга: объединить в единую платформу механизмы анализа сетевых пакетов, сканирования узлов (например, с помощью Nmap) и специализированные модули для протоколов BACnet IP, Modbus TCP, MQTT и Bus77.

Для того чтобы интеллектуальная система мониторинга могла эффективно работать, необходимо начинать с самой основы — выявления всех активных узлов в сети и определения их характеристик. Без этой информации дальнейшая интеграция протоколов и организация обмена данными становятся невозможными. Наиболее подходящим инструментом для выполнения данной задачи является утилита Nmap, зарекомендовавшая себя как гибкий и надёжный инструмент сетевого анализа. Она позволяет не только фиксировать факт наличия устройства в сети, но и собирать дополнительную информацию о его конфигурации, что делает её важным элементом в общей архитектуре разрабатываемого сервиса.

Одним из ключевых этапов построения модульного сервиса мониторинга является первичное сканирование сети с целью обнаружения потенциальных узлов инженерных систем. Для решения этой задачи используется утилита с открытым исходным кодом Nmap (Network Mapper).

Nmap позволяет определить:

1) активные хосты в сети;

2) открытые порты и соответствующие им службы;

3) характеристики операционных систем и их версий;

4) дополнительные параметры, отражающие конфигурацию узлов.

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

Nmap классифицирует состояние портов по четырём категориям:

1) open (открыт) — порт доступен и принимает соединения;

2) filtered (фильтруется) — трафик блокируется межсетевыми экранами;

3) closed (закрыт) — порт не используется приложениями, но может быть открыт позднее;

4) unfiltered (не фильтруется) — доступен, но статус определить невозможно.

Пример сканирования сети с проверкой целевых инженерных протоколов (листинг): 

Листинг. Пример вывода результата сканирования с использованием Nmap

1# nmap -A -T4 example.com
2Starting Nmap ( https://nmap.org )
3Interesting ports on example.com (93.184.216.34):
4(The 1672 ports scanned but not shown below are in state: filtered)
5PORT    STATE  SERVICE      VERSION
622/tcp  open   ssh          OpenSSH 8.2p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
753/tcp  open   domain       ISC BIND 9.16.1
880/tcp  open   http         nginx 1.18.0 (Ubuntu)
9443/tcp open   ssl/http     nginx 1.18.0 (Ubuntu)
103389/tcp closed ms-wbt-server
11Device type: general purpose
12Running: Linux 5.X
13OS details: Linux 5.4.0-88-generic
14Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel:5.4
15Nmap finished: 1 IP addresses (1 hosts up) scanned in 45.671 seconds

Nmap выступает незаменимым инструментом в составе разрабатываемого сервиса, выполняя роль первичного сетевого сканера и обеспечивая быстрое обнаружение активных устройств. Полученные данные становятся исходной информацией для последующей обработки специализированными модулями BACnet, Modbus, MQTT и Bus77. С помощью Nmap сервис автоматически определяет подключённые устройства, их IP-адреса, открытые порты и доступные сервисы, что ускоряет анализ и снижает риск пропуска важных узлов.

Такой подход делает сервис универсальным и гибким: он способен работать в любых TCP/IP сетях без ручной настройки, самостоятельно выявляя устройства и передавая данные модулям для более детального изучения. Это упрощает работу с сетью, сокращает время аудита и повышает точность выявления её особенностей.

В результате использование Nmap закладывает прочный фундамент для автоматизации сетевого мониторинга, сочетая эффективность первичного сканирования с глубиной последующей обработки специализированными протокольными модулями

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

Для автоматизированного мониторинга и управления инженерными системами на базе BACnet IP, Modbus TCP, MQTT и Bus77 используются методы проверки доступности устройств и сервисов, аналогичные сетевому сканированию, но ориентированные на безопасный и эффективный мониторинг.

Для устройств, работающих по TCP, применяются легкие проверки соединений, позволяющие фиксировать доступность без полного установления соединения. В случае отсутствия низкоуровневого доступа используется полное TCP-соединение, аналогичное стандартному Connect-подходу.

Для протоколов, работающих через UDP, сервис отправляет диагностические пакеты и анализирует ответы или ICMP-сообщения об ошибках. Поскольку UDP-пакеты не гарантируют доставку, открытые сервисы могут не отвечать, что требует повторной отправки и параллельного опроса ключевых портов.

Методы, аналогичные TCP ACK-проверке, позволяют оценивать сетевые фильтры и выявлять доступные сегменты сети. Ответ RST указывает на отсутствие фильтрации, что используется для построения карты доступности устройств.

Для повышения эффективности применяется параллельный опрос устройств и концентрация на критически важных сервисах, что обеспечивает своевременное обновление состояния инженерных систем без перегрузки сети

BACnet IP представляет собой реализацию протокола BACnet поверх стека TCP/IP, что обеспечивает интеграцию инженерных систем здания — отопления, вентиляции, кондиционирования, освещения, безопасности и энергоменеджмента — в корпоративные сети с возможностью удалённого мониторинга и управления. Открытость и совместимость протокола позволяют интегрировать устройства разных производителей, что критически важно для модульного сервиса, предназначенного для автоматизированного контроля и управления разнородной инфраструктурой. Стандартизация BACnet (ANSI/ASHRAE Standard 135, ISO 16484-5) и поддержка современных сетевых технологий

Гибкая топология является важной особенностью BACnet IP, что делает протокол удобным для интеграции в разнородные инженерные сети. Устройства могут подключаться через различные типы локальных сетей (LAN) или последовательные линии, а комплексные конфигурации создаются с помощью маршрутизаторов и мостов, обеспечивающих объединение сегментов сети и фильтрацию сообщений по MAC-адресам. Это позволяет формировать распределённые инфраструктуры, объединяя BACnet-сети с различными технологиями (Ethernet, MS/TP) в единую управляемую систему с гарантированным маршрутом передачи сообщений между узлами.

Для модульного сервиса каждое устройство BACnet IP представляется набором именованных сущностей — объектов. Объекты характеризуются набором свойств (атрибутов), что позволяет сервису получать структурированную информацию о состоянии устройства и управлять им через стандартные BACnet-сервисы. Стандартные типы объектов могут расширяться, обеспечивая поддержку специализированных функций и сохранение совместимости с существующими системами. Обязательный объект типа Device обеспечивает уникальную идентификацию устройства (Object_Identifier) и предоставляет перечень всех доступных объектов (Object_List)

Прикладной уровень BACnet IP отвечает за обработку данных и управление устройствами инженерных систем на уровне приложений. В модульном сервисе он реализуется через Application Entity, состоящую из двух компонентов:

BACnet User Element — управляет транзакциями, генерирует идентификаторы запросов, отслеживает таймауты и обеспечивает повторную передачу данных при необходимости.

BACnet Application Service Element (ASE) — реализует прикладные сервисы для удалённого мониторинга и управления устройствами, такие как чтение и изменение свойств объектов.

Взаимодействие между модулем сервиса и BACnet User Element осуществляется через API, который передает параметры сервисов (например, адрес целевого устройства или идентификатор объекта) на нижние уровни протокольного стека

Сервисные примитивы BACnet обеспечивают стандартизированный обмен информацией между приложением и сетевым стеком. Каждый примитив передаёт набор параметров, необходимых для выполнения операций (например, адресация, идентификаторы объектов, приоритет сообщений).

Для автоматического обнаружения устройств в сети сервисы Who-Is и I-Am позволяют модулю сервиса идентифицировать активные устройства BACnet IP, получать их уникальные Object_Identifier и сетевые адреса. Это обеспечивает динамическую интеграцию нового оборудования и синхронизацию состояния устройств при запуске системы

Сервис ReadProperty используется для получения значений свойств объектов устройств, что является ключевым механизмом мониторинга состояния инженерных систем. Аналогичные принципы применяются в других протоколах (Modbus TCP, MQTT, Bus77) для опроса устройств и сбора данных, обеспечивая единый подход к построению модульного сервиса управления

B/IP PAD (BACnet/IP Packet-Assembler-Disassembler) обеспечивает взаимодействие между BACnet-сетями и IP-инфраструктурой для модульного сервиса мониторинга и управления. Он обрабатывает Network Protocol Data Unit (NPDU), включая NPCI и NSDU, и маршрутизирует пакеты на основе номера целевой сети (DNET)

Данные BACnet передаются в UDP-пакетах на порту X'BAC0' (47808), что обеспечивает совместимость с корпоративными сетями и поддержку широковещательных сообщений. На принимающей стороне устройство B/IP PAD извлекает эти данные и пересылает их в локальную BACnet-сеть по стандартным процедурам, что позволяет обеспечить непрерывный обмен информацией внутри системы. Асинхронная передача через UDP делает возможным быстрый обмен данными в реальном времени, поддержку широковещательных запросов и интеграцию BACnet IP с другими протоколами, такими как Modbus TCP, MQTT и Bus77, в рамках единой модульной архитектуры.

Modbus TCP, в свою очередь, является протоколом прикладного уровня, обеспечивающим клиент-серверное взаимодействие между устройствами в промышленной и инженерной автоматизации. С момента своего появления в 1979 году он стал де-факто стандартом для обмена данными между контроллерами, датчиками и исполнительными устройствами

Физической средой передачи служит Ethernet, обеспечивающий высокую пропускную способность и масштабируемость. На рисунке 3 показан стек протоколов Modbus TCP, демонстрирующий взаимодействие прикладного, транспортного и сетевого уровней, что важно для построения модульного сервиса.

Рисунок 3 - Стек протоколов MODBUS

DOI:10.60797/IRJ.2025.160.72.3

В Modbus TCP структура данных формируется через PDU, включающий функциональный код и поле данных с параметрами операции (адреса регистров, количество элементов, значения для записи). Функциональные коды определяют тип операции: чтение или запись регистров, диагностика устройств, при этом коды 128–255 зарезервированы для исключительных ответов.

Модель данных организована в четыре таблицы:

1. Дискретные входы и выходы — бинарные значения, только чтение.

2. Регистры входов и хранения (Holding Registers) — 16-битные данные, регистры хранения доступны для чтения и записи, что позволяет управлять параметрами устройств.

В архитектуре Modbus TCP клиент инициирует все транзакции, отправляя запросы на устройства с уникальными идентификаторами (1–247) в режиме unicast. Основные операции чтения включают:

1. Read Coils (01) — состояние дискретных выходов.

2. Read Discrete Inputs (02) — дискретные входы.

3. Read Holding Registers (03) и Read Input Registers (04) — 16-битные регистры хранения и входов.

Такой подход позволяет модульному сервису эффективно собирать данные с устройств и управлять их параметрами в режиме реального времени.

Для тестирования модульного сервиса и отладки взаимодействия с устройствами Modbus TCP широко используются специальные эмуляторы. Они создают виртуальные сети Modbus, что позволяет проверять работу клиентских приложений без необходимости подключения к реальному оборудованию.

Одним из таких инструментов является Simulator MODBUS (mod_RSsim.exe) от Simplight. Он предназначен для имитации устройств Modbus RTU и TCP, поддерживает основные функции протокола и активно применяется для тестирования Modbus-клиентов, OPC/DDE-серверов, SCADA-проектов и программ мониторинга. Программа распространяется под лицензией GPL 3.0.

Другой вариант — Modbus TCP/RTU эмулятор от ardsoft, который позволяет воспроизводить работу ведомых устройств как в Modbus TCP, так и в Modbus RTU. Этот эмулятор используется для отладки клиентских приложений, тестирования SCADA-систем, проверки каналов связи и моделирования технологических процессов. Особенностью инструмента является встроенный скриптовый модуль, позволяющий задавать сложную логику работы устройств, включая ПИД-регуляторы, эмуляцию счётчиков расхода и выполнение типовых операций оборудования.

Использование эмуляторов в разработке модульного сервиса позволяет безопасно тестировать сбор данных и управление инженерными системами, минимизируя риски при работе с реальными объектами.

MQ Telemetry Transport (MQTT) — легковесный протокол обмена сообщениями по модели «издатель-подписчик», работающий поверх TCP/IP. Его минимальные накладные расходы и простота реализации делают MQTT оптимальным для встроенных устройств, IoT и сетей с ограниченной пропускной способностью, что важно для модульного сервиса мониторинга инженерных систем.

Основные элементы протокола:

1. Клиент — устройство или программа, публикующая или получающая сообщения.

2. Сервер (брокер) — посредник, управляющий публикациями и подписками клиентов.

3. Топик (тема) — метка, по которой маршрутизируются сообщения к подписчикам.

4. Подписка и фильтр темы — определяют, какие сообщения клиент получает.

5. Сессия — состояние взаимодействия между клиентом и сервером, которое может сохраняться между соединениями.

Модель работы MQTT основана на публикации сообщений издателями и их доставке подписчикам через брокера. Например, датчик температуры может публиковать данные в топики sensors/temp, а управляющее устройство подписываться на этот топик для мониторинга. Клиенты могут управлять соединением, подписками и корректно завершать сессии, а сервер обеспечивает маршрутизацию сообщений и обработку подключений.

Использование MQTT в модульном сервисе позволяет эффективно собирать данные с распределённых устройств и управлять ими в реальном времени, обеспечивая масштабируемость и гибкость интеграции с BACnet IP, Modbus TCP и Bus77.

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

Для разработки модульного сервиса используются протоколы Modbus TCP, MQTT и Bus77, обеспечивающие обмен данными, сбор информации и управление устройствами.

Modbus TCP применяет модель клиент-сервер через порт 502. Данные организованы в дискретные входы/выходы и регистры входов/хранения, что позволяет сервису опрашивать и управлять параметрами устройств. Основные функции — Read Coils, Read Discrete Inputs, Read Holding Registers и Read Input Registers. Для тестирования используются эмуляторы, имитирующие устройства и виртуальные сети. Передача данных осуществляется через Ethernet, обеспечивая интеграцию в корпоративные сети.

MQTT работает по модели «издатель-подписчик». Клиенты подключаются через CONNECT и регистрируют подписки на топики (SUBSCRIBE) с уровнем QoS. Топики имеют древовидную структуру с поддержкой wildcard-символов (#, +), что позволяет сервису гибко собирать данные и управлять устройствами в реальном времени.

Bus77 — гибридный российский протокол, предназначенный для работы как в централизованных, так и в децентрализованных сетях. Он поддерживает различные типы данных, включая числа, строки и массивы, обеспечивает обмен пакетами в широковещательном и адресном режимах и позволяет функционировать на микроконтроллерах с ограниченными ресурсами. Участниками сети выступают инструменты разработчика, сервер-контроллеры, панели управления и исполнительные устройства. Благодаря интеграции с BACnet IP, Modbus TCP и MQTT протокол Bus77 обеспечивает масштабируемый и безопасный обмен данными между всеми компонентами системы, создавая основу для единой модульной архитектуры.

Опираясь на возможности этих протоколов, разработанный модульный сервис реализует автоматическое обнаружение устройств, работающих с BACnet IP, Modbus TCP, Bus77 и MQTT, а также управление устройствами Bus77 с помощью команд абстрактного языка. При проектировании системы учитывались требования компании «Дисанс», включая использование программного обеспечения с открытым исходным кодом, формирование структуры данных для шлюзов и устройств, а также возможность выбора сетевого интерфейса для сканирования. Такой подход позволяет объединить различные протоколы в единую платформу для мониторинга и управления инженерными системами, обеспечивая одновременно гибкость, масштабируемость и безопасность. Для реализации функционала по каждому протоколу созданы отдельные модули: BACnet для взаимодействия с устройствами BACnet IP, Modbus для работы с Modbus TCP, Bus77 для обмена данными и управления устройствами Bus77, и MQTT для интеграции с брокерами и подписки на топики.

Система построена по модульной архитектуре с двухэтапным алгоритмом обнаружения устройств (рисунок 4).

Рисунок 4 - Структурная схема системы

DOI:10.60797/IRJ.2025.160.72.4

На первом этапе модуль на основе утилиты Nmap получает параметры сканирования, выполняет поиск устройств в сети и определяет, на каких из них запущены службы поддерживаемых протоколов. На втором этапе модули протоколов получают информацию из Nmap и выполняют детальный опрос устройств. Модуль BACnet отличается тем, что сканирует только заданный пользователем диапазон IP-адресов с использованием собственного механизма поиска.

В рамках проведённого исследования установлено, что большинство существующих программных решений, предназначенных для обнаружения сетевых устройств, либо имеют закрытый исходный код, либо не обеспечивают формирование структурированных данных об идентифицированных объектах. В связи с этим для реализации разработанного подхода был выбран язык программирования C#, что обусловлено как уровнем владения им со стороны разработчика, так и наличием открытых библиотек, поддерживающих работу с основными целевыми протоколами, включая Bacnet.Net для протокола BACnet IP, NModbus для протокола Modbus TCP и MQTTnet для протокола MQTT. Поддержка протокола Bus77, для которого отсутствуют специализированные библиотеки, была реализована средствами платформы .NET посредством использования TCP-сокетов и бинарной сериализации. Дополнительно в систему была интегрирована утилита Nmap, доступ к функционалу которой обеспечивается через библиотеку-обёртку SaltwaterTaffy, предоставляющую возможность программного управления процессом сетевого сканирования.

С помощью библиотеки SaltwaterTaffy модуль вызывает утилиту Nmap, передавая диапазон IP и порты, соответствующие протоколам: 502 (Modbus TCP), 30464 (Bus77), 1883 (MQTT). Nmap выполняет TCP Connect-сканирование, результатом которого является набор объектов, описывающих просканированные хосты с информацией об открытых портах.

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

Особняком стоит модуль BACnet IP. В отличие от других модулей, он не зависит от результатов сканирования Nmap и использует исходные параметры, указанные пользователем (-t, -lip). Это связано с особенностями протокола: BACnet применяет UDP-широковещательные и адресные запросы, требующие отдельного подхода. Модуль BACnet предназначен для обнаружения устройств BACnet IP и сбора детализированных данных об их объектах и свойствах. После обработки всех найденных хостов работа модуля Nmap завершается, а модуль BACnet продолжает сбор информации независимо от предыдущих результатов, обеспечивая полноту и точность мониторинга сети.

Архитектура модуля реализована на языке C# с использованием библиотеки Bacnet.Net, выбранной за следующие преимущества:

1) полностью написана на C#, что упрощает интеграцию в .NET-проекты;

2) активно поддерживается на GitHub, регулярно обновляется;

3) реализует основные службы BACnet для работы с устройствами (чтение/запись свойств, управление устройствами).

Конфигурация модуля задается через аргументы запуска: IP-адрес сетевого интерфейса и диапазон сканирования.

Структурная схема модуля представлена на рисунке 5.

Рисунок 5 - Структурная схема части системы с модулем Bacnet

DOI:10.60797/IRJ.2025.160.72.5

Алгоритм работы включает пять этапов (рисунок 6):

Рисунок 6 - Диаграмма последовательности модуля Bacnet

DOI:10.60797/IRJ.2025.160.72.6

1. Широковещательный запрос WhoIs — отправка запроса для поиска устройств в сети.

2. Адресный запрос WhoIs — рассылка запросов всем узлам IP-диапазона для получения ответов IAm.

3. Регистрация устройств — обработка ответов IAm с занесением каждого устройства в список с IP и Device ID.

4. Рекурсивный сбор данных — чтение списка объектов устройства через свойство PROP_OBJECT_LIST объекта OBJECT_DEVICE и получение свойств каждого объекта через ReadPropertyRequest.

5. Сериализация результатов – сохранение всех данных в JSON-файл, имя которого соответствует IP интерфейса (например, 192.168.0.100.json).

Особенности работы: обработка исключений при ошибках чтения свойств, параллельная обработка устройств через асинхронные вызовы Bacnet.Net, поддержка сложных сетей с обходом ограничений маршрутизации широковещательных запросов.

После завершения работы модуля BACnet, отвечающего за сбор детализированных данных с устройств BACnet IP, модульный сервис продолжает взаимодействие с другими протоколами. Следующим в работе системы выступает модуль Modbus TCP, который отвечает за обнаружение устройств и сбор информации о состоянии регистров, обеспечивая непрерывный мониторинг и управление инженерными системами через сеть Modbus.

Структурная схема модуля представлена на рисунке 7.

Рисунок 7 - Структурная схема части системы с модулем Modbus

DOI:10.60797/IRJ.2025.160.72.7

Работа модуля выполняется в два этапа:

1. Поиск активных устройств: получение IP-адреса шлюза от модуля Nmap, последующий опрос Slave ID 1–247. Для каждого устройства отправляются запросы на чтение четырех типов регистров: Coils, Discrete Inputs, Holding Registers и Input Registers. Устройство считается активным при успешном ответе хотя бы на один тип запроса.

2. Сбор данных регистров: бинарный поиск границ адресного пространства для каждого типа регистра, чтение всех регистров с сохранением в структуру данных. Для повышения производительности используется групповое чтение (до 2000 дискретных значений и 125 16-битных регистров за один запрос).

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

Параметры подключения задаются через аргументы запуска, включая IP-адрес шлюза. Запросы формируются в виде бинарных пакетов в соответствии со спецификацией Bus77, а ответы декодируются с проверкой контрольной суммы CRC16 для обеспечения целостности данных.

Структурная схема модуля представлена на рисунке 8.

Рисунок 8 - Структурная схема части системы с модулем Bus77

DOI:10.60797/IRJ.2025.160.72.8

Алгоритм работы модуля:

1. Установка соединения — модуль открывает TCP-соединение со шлюзом.

2. Широковещательный запрос IRIDIUM_MESSAGE_SYSTEM_SEARCH (код 0x03) — позволяет получить первичный список устройств. Программа ожидает некоторое время, чтобы устройства обработали запрос и отправили свои базовые метаданные: адрес, сегмент, группу и уникальный идентификатор.

3. Адресной запрос IRIDIUM_MESSAGE_SYSTEM_DEVICE_INFO (код 0x04) — выполняется для каждого обнаруженного устройства для сбора расширенной информации: пользовательский идентификатор, счетчик изменений параметров, флаги состояния, тип устройства (контроллер, исполнительный механизм, панель управления) и другие свойства.

4. Запрос Smart API IRIDIUM_MESSAGE_SYSTEM_SMART_API (код 0x0A) — предназначен для получения универсальных данных устройства в виде массива байт. Не все устройства поддерживают данный тип запроса, и ответы с ошибкой (код 4) интерпретируются как отсутствие поддержки сообщения.

Диаграмма последовательности работы модуля представлена на рисунке 9.

Рисунок 9 - Диаграмма последовательности модуля Bus77

DOI:10.60797/IRJ.2025.160.72.9

В результате модуль использует три запроса из 19 доступных в библиотеке, что подтверждает её корректную работу. Полученные данные о каждом устройстве сериализуются в JSON-файл, имя которого соответствует IP-адресу шлюза (например, 192.168.0.100.json).

Модуль Bus77 обеспечивает автоматическое обнаружение устройств и сбор их метаданных через широковещательные и адресные запросы, проверку целостности данных с помощью CRC16 и сохранение информации в формате JSON. Это позволяет систематизировать данные, упрощает анализ сети и демонстрирует эффективную работу с устройствами Bus77 в рамках модульного сервиса.

После описания работы модулей и механизмов сбора данных становится возможным оценить их эффективность на практике. Следующий этап — проверка функциональности и производительности модульного сервиса, чтобы убедиться, что обнаружение устройств, сбор метаданных и взаимодействие с протоколами BACnet IP, Modbus TCP, Bus77 и MQTT выполняются корректно и надёжно.

Для испытаний использовались как физические стенды, так и эмуляторы:

1. Физические стенды предоставлены компанией «Дисанс» для тестирования протоколов Bus77 и MQTT.

2. Эмуляторы использовались для проверки работы Modbus TCP и BACnet IP:

- Modbus: Ardsoft Modbus Simulator и Simplight MODBUS Simulator.

- BACnet: Bacnet.Room.Simulator от компании Elacompil.

Физические стенды были удалёнными и доступны через VPN с пингом ~79 мсек. Эмуляторы размещались на виртуальной машине того же хоста, с которого запускалась система.

Для теста были заданы два диапазона IP-адресов:

192.168.42.1–192.168.42.255 — удалённый физический стенд.

192.168.0.1–192.168.0.255 — виртуальная машина с эмуляторами.

Сетевой интерфейс: eth0, адрес интерфейса хоста: 192.168.0.100. Запуск системы выполнялся командой:

.\NmapModule.exe -t 192.168.42.0/24 192.168.0.0/24 -i eth0 -lip 192.168.0.100

Состояние тестовой сети:

- Эмулятор Modbus: 2 активных устройства из 254, с изменёнными значениями регистров всех типов.

- Эмулятор BACnet: 1 устройство с 15 объектами.

- Физический стенд Bus77: 8 устройств, включая один шлюз.

- Стенд MQTT: 1 брокер версии 3.1.1.

Результаты трёх запусков представлены в таблице:

Примечание: значения в графе «Просканировано устройств» отражают количество устройств, с которыми взаимодействовал конкретный модуль. Например, при наличии двух брокеров MQTT модуль Nmap передал бы на анализ два устройства.

Для модуля Modbus дополнительно измерялось время на поиск устройств и сбор данных регистров:

1. Поиск устройств: 1915 сек. (~98% общего времени).

2. Чтение регистров: 40,55 сек.

После завершения работы системы были проанализированы сформированные JSON-файлы и лог консоли. Результаты показали:

1. Модуль Nmap обнаружил 2 хоста с целевыми службами и передал данные другим модулям.

2. Модуль Bus77 получил информацию о всех 8 устройствах физического стенда.

3. Модуль BACnet обнаружил эмулятор и получил данные всех 15 объектов.

4. Модуль MQTT успешно подключился к брокеру и собрал retained-сообщения из 126 топиков.

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

В ходе работы была разработана и протестирована модульная система для автоматизированного мониторинга и управления инженерными системами на базе протоколов BACnet IP, Modbus TCP, MQTT и Bus77. Предложенная архитектура обеспечивает комплексное решение задач обнаружения устройств, сбора данных и интеграции разнородных подсистем в единую платформу. Использование открытых библиотек и модульного принципа построения позволило добиться универсальности и масштабируемости системы, а также снизить зависимость от проприетарного программного обеспечения.

Проведённые эксперименты с применением эмуляторов и физических стендов подтвердили корректность работы всех модулей и показали возможность практического использования сервиса в условиях реальной инфраструктуры. Результаты испытаний продемонстрировали эффективность предложенного подхода для создания единой платформы интеллектуального мониторинга, готовой к внедрению предиктивной аналитики и интеграции в процессы цифровой трансформации предприятий.

Перспективными направлениями дальнейших исследований являются:

1) расширение функционала предиктивных алгоритмов для повышения точности прогнозирования отказов и оптимизации энергопотребления;

2) внедрение механизмов кибербезопасности для защиты инженерных систем от внешних угроз;

3) интеграция сервиса с системами управления жизненным циклом зданий (BIM, CAFM);

4) разработка облачной версии платформы для удалённого мониторинга и управления объектами.

Таким образом, созданный модульный сервис закладывает основу для построения интеллектуальных систем управления зданиями, способных повысить надёжность эксплуатации инженерных систем и снизить затраты на их обслуживание.