Многие предприятия до сих пор эксплуатируют системы автоматизации зданий (BMS) на базе оборудования Johnson Controls предыдущих поколений. Часто возникает задача модернизации или расширения системы.
Цель данной работы — исследовать механизм обмена данными протокола N2Bus по интерфейсу RS-485 и проверить возможность подключения современных устройств Modbus RTU непосредственно в ту же физическую шину, где "живут" контроллеры Johnson Controls.
Важно: Все приведённые данные использованы исключительно для целей локальной интеграции. Материал предназначен для образовательных и исследовательских целей в контексте интеграции в системы автоматизации зданий.
1. Архитектура решения
Мы имеем классическую шину N2Bus (RS-485, 9600, 8, N, 1). Наша задача — убрать мастер (NAE) и дополнить систему, добавив в неё новые Modbus-устройства и завести всё это в современную SCADA.
Используемое оборудование:
· Контроллеры FX15 и модули XT9100 (существующее оборудование N2Bus).
· Контроллер Pixel (новое оборудование Modbus).
· Конвертер Ethernet <-> RS-485.
· ПК с MasterOPC Server и Simple Scada.
Ниже представлена схема трансформации сети. Мы переходим от архитектуры с проприетарным мастером к открытой архитектуре.
2. Анализ протокола: Пассивный сниффинг
Для понимания того, как "подселить" Modbus к N2Bus, необходимо изучить структуру пакетов последнего. Был использован метод пассивного сниффинга с помощью преобразователя интерфейсов, подключенного параллельно шине, и ПО sscom5.
Параметры порта: 9600 baud, 8 data bits, no parity, 1 stop bit.
Типичный кадр N2Bus выглядит так: 3E 34 42 30 34 44 41 0D 41 0D
Состоит из двух частей:
Команда к устройству N2Bus 3E 34 42 30 34 44 41 0D
Ответ 41 0D
Где:
· 0x3E — Стартовый байт (символ >). Это важный момент для нашей интеграции.
· Далее идут данные в формате ASCII Hex.
· 0x0D — Байт окончания посылки (CR).
3. Математическое обоснование совместимости (Коллизии кадров)
Главный страх любого инженера АСУ ТП при смешивании протоколов — коллизии. Что будет, если устройство N2Bus примет пакет Modbus за свой, или наоборот?
Оценка вероятности совпадения кадров при одном жестком условии: Для устройств Modbus ЗАПРЕЩЕНО использовать адрес 62 (0x3E).
Почему именно 0x3E?
В протоколе N2Bus каждый пакет начинается с байта 0x3E (символ >). В протоколе Modbus RTU первым байтом посылки всегда идет адрес устройства.
Сценарий 1: Устройство Modbus слушает N2Bus
Если Мастер отправляет запрос устройству N2Bus, пакет начинается с 0x3E. Устройства Modbus на линии воспринимают этот байт как адрес. Поскольку мы исключили адрес 62 из адресного пространства Modbus, ни одно устройство Modbus не ответит на этот запрос.
Вероятность коллизии:
P modbus error = 0
Сценарий 2: Устройство N2Bus слушает Modbus
Это более сложный случай. В потоке бинарных данных Modbus (значения регистров, CRC) может случайно встретиться байт 0x3E. Устройство N2Bus "проснется" и начнет слушать линию, ожидая валидный пакет N2.
Рассчитаем вероятность того, что случайный шум (данные Modbus) сформирует валидный пакет N2Bus. Валидный пакет N2 должен удовлетворять условиям:
1. Стартовый байт: 0x3E.
2. Следующие 2 байта (Адрес): должны быть валидными ASCII-символами (0-9, A-F).
3. Адрес должен совпадать с реальным адресом устройства на шине.
4. Пакет должен завершаться 0x0D и проходить проверку контрольной суммы (CS).
Вероятность формирования "фантомного" пакета (P Phantom):
P phantom = P(0x3E) x P(ASCII_Addr) x P(Match_Addr) x P(CR) x P(CS)
Подставим значения для случайного распределения байтов:
P(0x3E)=1/256
P(ASCII_Addr)=(16/256)^2 = 1/256
P(CR)=1/256
P(CS)=1/256
Итоговая вероятность ложного срабатывания на один байт данных:
P phantom = 1/(256^4) = 1 / 4 294 967 296
Вывод: Вероятность того, что устройство N2Bus ошибочно исполнит команду из потока Modbus, стремится к нулю. При грамотной настройке таймаутов и исключении адреса 62 (0x3E) для Modbus, протоколы могут сосуществовать на одной физической паре.
4. Реализация: OPC Server и Simple Scada
Для опроса использовался MasterOPC Universal Modbus Server. Была настроена архитектура тегов, позволяющая опрашивать как старые контроллеры Johnson (через драйвер N2 или скрипты), так и новые модули Modbus.
В качестве верхнего уровня была выбрана Simple Scada. Она считывает теги чер��з OPC и предоставляет единый интерфейс для диспетчера, где не видно разницы между "старым" и "новым" оборудованием.
Ниже представлен пример реализации интерфейса в Simple Scada. Обратите внимание, что данные с FX15 (N2Bus) и Pixel (Modbus) выводятся на соседних экранах или даже в одном окне.
5. Результаты
В ходе работы удалось достичь следующих результатов:
1. Полный мониторинг: Состояние устройств N2Bus и Modbus отслеживается в реальном времени.
2. Стабильность: Подтверждена одновременная работа двух протоколов на одной физической шине без взаимных помех.
3. Управляемость: Реализована возможность удаленного управления уставками и режимами ра��оты.
4. Масштабируемость: Теперь систему можно расширять любыми устройствами Modbus.
Заключение
Исследование подтвердило возможность "бесшовной" интеграции Modbus устройств в существующую сеть N2Bus. Использованы промышленные решения, такие как преобразователи интерфейсов и MasterOPC Server.
Данная публикация основана на собственных наблюдениях процесса обмена данными. Автор не использовал сервисные прошивки, SDK или закрытую документацию Johnson Controls. Вся информация получена неинвазивными методами. Все торговые марки (Johnson Controls, Metasys, N2Bus и др.) принадлежат их правообладателям и используются здесь исключительно для идентификации описываемого оборудования. Автор не связан с компанией Johnson Controls. Автор не несёт ответственности за неправильное использование материала.
