RDM протокол – ожидание/реальность.
Александр Тишков,
разработчик АСУ Light Stream,
aa@lightstream.pro
Современные светотехнические системы становятся все более сложными и многофункциональными, что требует новых подходов к их управлению и мониторингу. Протокол DMX512, широко используемый в индустрии, долгое время оставался основным стандартом для управления осветительными устройствами. Однако, с ростом числа устройств и усложнением их функционала, возникла потребность в более гибкой и интерактивной системе управления. Протокол Remote Device Management (RDM), введенный в стандарте ANSI E1.20-2006, стал ответом на эти вызовы, предоставив возможность двусторонней связи между контроллерами и устройствами.
Многие инсталляторы и производители светового оборудования для архитектурного освещения активно продвигают RDM и декларируют большое количество преимуществ от его внедрения. Вот некоторые из выделяемых преимуществ:
- RDM – это расширение протокола DMX,что позволяет использовать те же самые кабеля и коннекторы, не усложняется инфраструктура
- Автоматическое распознавание и диагностика осветительных приборов
- Возможность изменить DMX-адрес светильника удаленно
- Передача статусных сообщений
- Обновление программного обеспечения световых приборов через интерфейс RS-485
- Возможность удаленно применить различные настройки драйверов, например, установить значения тока для каналов
Но по факту в проектах реализуется только малая часть этих преимуществ и наиболее частым применением протокола является лишь возможность задавать адреса световым приборам. В конкурентной борьбе компаниям удается убедить заказчика вписать необходимость внедрения RDMв техническое задание к проекту или к тендеру, но редко детализируется глубина такого внедрения и практическая выгода, хотя при этом значительно вырастает сложность и стоимость такого проекта. И в итоге получается, что вместо обширного перечня плюсов мы имеем сопоставимое количество недостатков:
- Совместимость: Первым препятствием является общая совместимость существующего оборудования с протоколомRDM (менее 10% от общего числа светодинамического оборудования для АХО). Второй фактор – неполная или некорректная поддержка RDM протокола и систем управления освещением.
- Сложность реализации: внедрение RDM требует значительных изменений в аппаратном и программном обеспечении контроллеров и устройств, что может быть трудоемким и дорогостоящим процессом.
- Проблема обработки и хранения информации. Большинство разработчиков ПО для систем управления освещением не располагают возможностью собирать, хранить и визуализировать данные, получаемые от конечных устройств. Из представленных на рынке производителей, только InoageGmbh (Madrix), TraxonTechnologiesEuropeGmbH (Sympholight), и ООО «Лайт Стрим» (Light Stream) разработали программные и аппаратные инструменты, в полной мере позволяющие реализовать преимущества RDM
- Ограничения при передаче данных. Двунаправленность системы DMX/RDM несет определенные ограничения, обусловленные ограниченным временным периодом отправки RDM-пакетов, возможным в период «Brake» между отправкой DMX-фреймов (см.рис.1). Также, ранее решенная проблема коллизии данных, при которой контроллеру приходилось синхронизировать соединения с устройствами посредством индивидуальной инициализации сеансов и определения периода обратной связи, внесла дополнительное временное ограничение на сбор данных
- Сложности с конфигурацией сети: Процедура поиска устройств — discovery требует тщательной настройки сети и может быть затруднена в условиях большого количества устройств или сложной топологии сети.
- Сложность интеграции: Внедрение и эксплуатация RDM требует специалистов с определенными навыками и теоретическими знаниями. Найти такие кадры может быть сложно, особенно в условиях дефицита кадров в сфере автоматизации.
Такие проблемы как совместимость устройств, сложность интеграции и реализации проектов с применением RDM со временем решатся эволюционным путем за счет развития отрасли и распространения протокола. Мне же в данной статье хотелось бы выделить и рассмотреть отдельные технические аспекты некоторых проблем, которые привнесены особенностью интерфейсаRS-485 на базе которого реализуется DMX-512 и его расширениеRDM протокол. А именно подробнее хотелось бы остановиться на одной из ключевых функций RDM — команде discovery, которая позволяет обнаруживать и идентифицировать все устройства в сети.
Основные принципы RDM
Протокол RDM расширяет возможности DMX512, добавляя обратный канал связи, который позволяет контроллерам (или консолям) отправлять команды и получать ответы от устройств (светильников, диммеров и других). Это достигается за счет использования уникальных идентификаторов устройств (UID), которые позволяют однозначно идентифицировать каждое устройство в сети.
Процедура поиска устройств
Процедура поиска устройств в сети RDM является многосложным процессом, включающим несколько этапов. Она предназначена для обнаружения всех устройств, подключенных к сети, и получения их уникальных идентификаторов (UID). Рассмотрим этот процесс более подробно.
- Инициация поиска
Контроллер начинает процедуру поиска, отправляя широковещательный запрос на все устройства в сети. Этот запрос содержит специальную команду DISC_UNIQUE_BRANCH, которая указывает устройствам ответить, если их UID попадает в определенный диапазон.
- Разбиение на диапазоны
Для ускорения процесса и уменьшения количества коллизий, сеть разбивается на диапазоны UID. Контроллер последовательно опрашивает эти диапазоны, начиная с самого широкого (например, от 0x000000000000 до 0xFFFFFFFFFFFF) и постепенно сужая их.
- Ответы устройств
Устройства, чьи UID попадают в запрашиваемый диапазон, отвечают контроллеру специальным сообщением DISC_UNIQUE_BRANCH_REPLY. Ответы могут приходить одновременно от нескольких устройств, что приводит к коллизиям на шине.
- Устранение коллизий
Для разрешения коллизий контроллер использует метод двоичного деления. Он делит текущий диапазон UID на два поддиапазона и повторяет запросы для каждого из них. Этот процесс продолжается до тех пор, пока каждый диапазон не будет содержать только одно устройство или не станет пустым.
- Подтверждение обнаружения
Когда контроллер получает ответ от устройства без коллизий, он записывает его UID и продолжает опрос других диапазонов. Таким образом, контроллер последовательно обнаруживает все устройства в сети.
- Завершение поиска
После завершения опроса всех возможных диапазонов контроллер завершает процедуру поиска и переходит к следующему этапу взаимодействия с устройствами, таким как настройка параметров или диагностика.
Процедура поиска устройств в сети RDM является критически важным элементом для эффективного управления светотехническими системами. Проблемным местом этой процедуры является время выполнения в больших сетях с большим количеством устройств и коллизии, которые могут дополнительно могут замедлить процесс поиска. При этом нет необходимости использовать процедуру discovery в постоянном режиме и наиболее оптимальным путем развития систем управления архитектурным освещением реализующих все плюсы RDMпротокола видится в применении 2 видов переключаемых сервисных режимов:
Режим 1 (пуско-наладочных работы) – Режим, при котором осуществляется процедура discovery, собираются максимально полные данные, передаваемые от приборов к центральному контроллеру, тайминги brakeмаксимально увеличены и допускается пропуск кадров DMX. В таком режиме мы должны обнаружить все светильники проекта и сохранить собранную карту UIDадресов в центральный контроллер, в нашем случае мы говорим об автономном контроллере Light Stream Player.
После получения информации в веб-интерфейсе центрального контроллера мы выбираем данные для последующего опроса устройств, чтобы уменьшить их количество при избытке. И также фиксируем все полученные UIDи параметры этих приборов в память центрального контроллера.
Режим 2 (эксплуатационный) — Существенное ограничение сбора данных по параметрам, увеличение интервала опроса и приема данных. Для данного режима необходимо манипулировать следующими параметрами: уменьшение размера пакета данных, использование коротких сообщений, сокращение частоты опроса, увеличение интервала между запросами и ответами, применение алгоритмов обнаружения и коррекции ошибок для снижения доли отправляемых повторных пакетов, приоритезация типов данных.
К общим инструментам оптимизации пакета можно отнести применение коротких уникальных идентификаторов устройств, динамическая адресация и маршрутизация пакетов.
Заключение.
Интеграция протокола RDM требует применения осветительного оборудования с качественными драйверами и систем управления, адаптированных разработчиками под полную поддержку протокола. Система управления должна быть максимально адаптивной к различным режимам эксплуатации инсталляции. Тайминги, собираемые параметры и их объем, а также частота сбора данных являются единственными доступными инструментами при настройке специальных RDM-пресетов.
Протокол RDM на текущий период применяется и функционирует условно, полноценно не используется. Сложные драйверы светильников не могут раскрыть потенциал ввиду своей невостребованности, отсутствует ПО, способное аккумулировать и систематизировать получаемую сервисную информацию в удобном виде. Производители систем управления стремятся реализовать полноценную поддержку только собственных устройств, что осложняет поддержку конечными устройствами.
В перспективе будут формироваться новые требования, предъявляемые заказчиками, по настройке систем управления, поддерживающих RDM. Соответствие таким требованиям будет являться индикатором эффективности работы проектировщиков и интеграторов и качества систем управления при участии в тендерах.
