Remote Device Management (RDM) является расширением протокола USITT DMX512 [2], которое позволяет двухсторонний обмен данными между освещением или системным контроллером и подключенными RDM-совместимыми устройствами через стандартную линию связи DMX. Этот протокол позволит осуществить конфигурирование, мониторинг статуса и управление этими устройствами таким способом, который не нарушает нормальное функционирование стандартных устройств DMX512, которые не распознают протокол RDM. Стандарт изначально был разработан организацией Entertainment Services and Technology Association - Technical Standards (ESTA) и официально известен как "ANSI E1.20, Remote Device Management Over DMX512 Networks" (дистанционное управление устройствами через сети DMX512). Здесь приведен перевод описания протокола RDM из Википедии [1].

[Физический уровень RDM]

Протокол RDM и его физическая организация были разработаны с целью получения совместимости с уже существующим оборудованием DMX512. Все устройства, стандартно совместимые приемники DMX512 должны нормально работать в смешанных системах, которые имеют контроллер RDM (консоль) и RDM-респондеры (приемники). Приемники DMX и респондеры RDM могут использоваться со стандартной консолью DMX для формирования системы, работающей только по стандарту DMX512. С точки зрения пользователя вид организации системы остается очень похожим на систему DMX. Контроллер все так же помещается на одном конце основного сегмента кабеля. Далее кабель идет от приемника к приемнику в виде гирлянды (daisy-chain). Сплиттеры RDM используются точно тем же способом, как должны использоваться сплиттеры DMX. Дальний конец (не оканчивающийся консолью или сплиттером) кабельного сегмента должен быть терминирован.

Прим. переводчика: насколько я понял, это означает использование той же физической скорости передачи данных 250 килобит/сек, как в стандарте DMX, таких же кабелей с волновым сопротивлением 120 Ом и таких же терминаторов на 120 Ом.

RDM требует 2 главных изменения топологии в сравнении с DMX. Однако эти изменения главным образом внутренние, относятся к оборудованию и, таким образом, невидимы для пользователя. Во-первых, имеется терминирование на стороне выхода контроллера (консоль управления). Во-вторых, это терминирование должно обеспечивать смещение, чтобы удерживать линию в состоянии маркера ‘marking state’, когда нет разрешенного драйвера.

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

В протоколе DMX выходные драйверы консоли всегда разрешены и работают как активный выход. Протокол RDM разработан так, чтобы всегда, за исключением процедуры распознавания (discovery), не было коллизий данных. Чтобы гарантировать это отсутствие столкновений, делая возможным внедрение на различных платформах, здесь имеются интервалы времени, когда все драйверы на линии должны быть отключены. Если бы на линии не было ничего подключено, кроме терминирования, то линия имела бы некий неизвестный уровень. В этом случае на линии могут быть прочитаны одно или большее количество случайных изменений. Эти случайные изменения значительно уменьшают качество работы системы. Таким образом, требуется смещение линии.

Чтобы гарантировать это, секция 2.4.1 (Line Bias Networks) стандарта гласит: "порт команд (т. е. порт консоли) должен обеспечить средство ввода смещения в линию связи напряжением как минимум 245 мВ, и это должно быть проверено схемой тестирования, описанной в Приложении F". Далее стандарт устанавливает, что смещение означает “смещение должно иметь полярность положительным потенциалом к проводу Data+ относительно провода Data-. Смещение линии в сети должно сохраняться на эквивалентной нагрузке 32 устройства и напряжение общего режима будет изменяться в диапазоне от +7 вольт до -7 вольт DC”.

Стандарт не требует какой-либо отдельной схемы для предоставления базового состояния и терминирования; однако простейший метод подключения означает пассивное разделение сети.

Независимо от используемого метода соединение должно быть протестировано с выбранной микросхемой драйвера, чтобы убедиться, что комбинация оборудования удовлетворяет требованию стандарта E1.20. Тесты приведены в Приложении F стандарта. Эти тесты нужны для проверки дизайна, и не требуют на этапе тестирования выпуска оборудования. Опыт показывает, что многие драйверы EIA485, разработанные для работы от 5V, удовлетворяют требованиям необходимых тестов. Но совсем не обязательно, что все микросхемы на 3.3V пройдут эти тесты. В любом случае качество и быстродействие линии связи должно быть проверено. Подробную информацию о разделении сети и тестах можно найти в стандарте ANSI E1.20 - 2006.

[Протокол RDM]

Пакеты RDM вставляются между существующими пакетами данных DMX, использующимися для управления освещением. Стандарт DMX512 [2] требует, чтобы пакеты DMX начинались со стартового кода (start code). По умолчанию Start Code равен 0x00 (он также известен как Null Start Code). Путем использования стартового кода 0xCC, пакеты RDM могут быть безопасно вставлены между пакетами данных DMX, так что старые не-RDM устройства не будут пытаться их читать.

Стандарт DMX512 требует использования коннекторов DMX типа 5-pin XLR, где используются только первые 3 вывода (выводы 4 и 5 были зарезервированы для "будущего использования"). К сожалению, некоторые производители начали использовать последние два вывода коннектора для различных проприетарных целей, таких как передача маломощного питания или передачи проприетарных протоколов для организации обратного канала. Именно по этой причине было принято решение использовать для обмена по протоколу RDM все тех же выводов 2 и 3. Это ставит вопросы борьбы с коллизиями данных.

Стандарт RDM решает проблему коллизий, гарантируя во всех случаях (кроме процесса discovery), что только одно устройство авторизовано для передачи в любой момент времени (это работает подобно методу передачи маркера). Только контроллер (который может быть только один) может начать обмен по протоколу RDM. Респондеры RDM могут работать на передачу только в том случае, если контроллер обменивается данными именно с ним. Контроллер всегда инициирует все обмены данных по протоколу RDM.

Все устройства RDM имеют уникальный идентификатор (UID), который состоит из идентификатора производителя (manufacturer ID) и серийного номера (serial number).

Обмены данными по протоколу RDM можно разделить на 3 типа:

• Discovery (открытие канала, распознавание устройств).
• Unicast communication (обмен только с одним устройством).
• Broadcast communication (широковещание, обмен с многими устройствами).

Discovery. Это соответствует открытию сети RDM. Это единственная ситуация, когда могут происходить коллизии данных, если предположить исправность и корректную работу всех устройств на шине. В этом случае контролер широковещательно передает команду открытия (broadcast a discovery command) на все устройства сети и ждет от них подтверждения. Если к сети подключено больше чем одно устройство, то одновременный ответ от них приведет к коллизии данных, и контроллер не получит корректно отформатированный ответ. В этом случае контроллер будет уточнять свой поиск устройств к меньшему диапазону UID, в соответствии с двоичной маской поиска (binary search pattern). Как только контроллер примет корректный ответ, он попытается приглушить ответившее устройство (mute). После успешного mute это устройство больше не будет отвечать на сообщения discovery, и контроллер может продолжить поиск всех остальных устройств. После того как все устройства будут приглушены (т. е. на команды discovery больше не будет поступать ответов), то процесс discovery завершается, и контроллер будет иметь при себе составленный список всех подключенных устройств.

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

Unicast communication. Основной обмен с каждым отдельным устройством освещения происходит по шаблону запрос-ответ. Контроллер отправляет запрос к устройству, адресуя устройство по его UID. Когда запрос отправлен, контроллер освобождает линию DMX на определенное время, когда устройство может передать свой ответ. Обмен unicast - единственный способ получить данные от светильника (кроме получения его UID, который может быть получен через механизм discovery, описанный ранее). Если устройство не отвечает в течение указанного периода времени, то контроллер предполагает, что обмен данными потерпел по какой-то причине сбой, после чего контроллер может сделать повторную попытку обмена.

Broadcast communication. Чтобы быстро передать указания нескольким светильникам, RDM использует обмен broadcast (широковещание). Это позволяет контроллеру отправить инструкцию на все устройства, или на все устройства от одного производителя. Поскольку получателем сообщения может быть более чем одно устройство, то в широковещательной передаче не разрешены ответы от устройств, кроме как во время процедуры Discovery.

[Применения для RDM]

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

• Идентификация и классификация подключенных устройств: Fixtures (светильники), Dimmers (регуляторы освещенности), Splitters (разделители), и т. д.
• Адресация устройств, управляемая по протоколу DMX512 (т. е. можно подключить консоль управления по стандарту DMX512).
• Отчеты о состоянии светильников и других подключенных устройств.
• Конфигурирование светильников и других устройств DMX.

[Совместимость с существующим оборудованием DMX]

RDM был изначально разработан с расчетом совместной работы с существующими устройствами DMX. Использование другого start code гарантирует, что все DMX-совместимые устройства, которые не поддерживают RDM, будут игнорировать любые сообщения RDM, однако не все устройства DMX были изготовлены со строгим учетом требований стандарта DMX, поэтому старые устройства DMX, которые не проверяют start code приходящих пакетов DMX, будут пытаться интерпретировать сообщения RDM как буд-то это пакеты DMX, в результате чего будет происходить мерцание освещения и другое непредсказуемое, ошибочное поведение.

Любые устройства, которые предоставляют гальваническую изоляцию или буферизирование линии DMX (такие как сплиттеры DMX) традиционно были разработаны так, чтобы разрешить передачу данных только в одну сторону: в направлении от контроллера к устройствам. Поскольку RDM требует двунаправленного обмена между этими устройствами, то сигнал через такой сплиттер DMX в обратном направлении не пройдет. Нормально будут работать только устройства, которые были разработаны в учетом совместимости с протоколом RDM. Старые сплиттеры DMX, которые не совместимы с RDM, обычно могут передавать только данные DMX, и будут блокировать обмен протокола RDM.

[Адаптация и развитие стандарта RDM]

RDM был ратифицирован в 2006 году. Требовалось некоторое время на то, чтобы он широко внедрился на практике (прим. переводчика: похоже, что пока что DMX512 все-таки доминирует, но устройства RDM постепенно вытесняют DMX). Уже есть несколько общедоступных консолей управления освещением, поддерживающих RDM, и растет список респондеров RDM, таких как скроллеры, диммеры, бегущие огни [5]. Также уже появились беспроводные системы передачи данных для линков DMX/RDM [5].

Поддержка стандарта RDM. Доступны тестеры DMX512 / RDM. С этими инструментами можно адресовать, конфигурировать респондеры RDM, отслеживать их состояние, и все это без необходимости наличия консоли RDM. Ввод в эксплуатацию инструментария тестирования значительно расширило возможности по разработке и оценке контроллеров и респондеров RDM. Некоторые компании делают устройства - инжекторы RDM, которые могут работать между контроллером DMX и респондерами. Устройство-инжектор вставляет пакеты RDM в имеющийся поток данных DMX.

Межплатформенная совместимость (Cross-compatibility). Как всегда бывает с относительно новым протоколом, некоторые производители сообщают о неожиданно возникающих проблемах. Чтобы разобраться с этими проблемами, сообщество DMX приняло несколько мер. Имеются форумы разработчика протокола (RDM Protocol Developer Forum) и форум пользователя (User Forum), чтобы реализаторы могли получать ответы на возникающие вопросы, и можно было решать потенциальные проблемы. Организация PLASA проводит несколько раз в год совещания по RDM. Это позволяет производителям оборудования RDM обмениваться опытом между собой. Эти меры улучшили функциональную совместимость оборудования. Для респондеров RDM имеется открытый инструментарий тестирования Automated Responder Tests [3].

Совместимость с новыми технологиями. RDM был разработан так, чтобы учесть параметры традиционного последовательного интерфейса DMX512. В результате можно сделать предположения о совместимости RDM с другими технологиями освещения.

RDM основан на наличии в одной линии только одного контроллера, который обеспечивает отсутствие коллизий данных. Есть несколько других решений, которые позволяют передавать несколько потоков DMX от нескольких контроллеров, объединяя данные в один поток DMX. В однонаправленной среде передачи это довольно тривиально, однако становится намного более сложным, когда вовлекается протокол RDM, так как становиться весьма сложным направить обратные RDM-ответы от устройств обратно к нужному контроллеру.

RDM основан на устройствах, которые отвечают в заданный период времени, отведенный на передачу ответа. Если устройство не начало отвечать в корректном окне времени, то контроллер скорее всего сделать повторную попытку запроса или сдастся. В среде "только DMX" это не составляет проблемы, так как задержка между устройством и контроллером вероятно будет очень и очень мала. Однако если DMX распространяется поверх промежуточного носителя данных (такой как сеть TCP/IP Ethernet или беспроводный интерфейс передачи данных), то это может вызвать некоторые проблемы. Обычно если производитель осуществляет управление через промежуточный интерфейс (как это делается для беспроводного DMX), то возможно перенаправление ответов RDM, как если бы они были приняты, вместе с системой проксирования для поддержки процедуры discovery - это дает иллюзию, что обмен RDM прошел нормально.

Если же производитель не управляет промежуточной средой передачи (как если используется сеть Ethernet) то тогда на базе DMX невозможно виртуально передать сообщения RDM обратно к контроллеру RDM. Однако можно осуществить обмен RDM с устройствами DMX через контроллер на базе Ethernet. Поскольку контролеры освещения быстро стремятся к тому, чтобы полностью перейти на управление через Ethernet, то наверняка в будущем устройства DMX/RDM будут вытеснены новым протоколом. Появятся устройства вывода Ethernet-to-DMX, которые перенаправят данные в среду RDM и DMX, и далее они будут обработаны традиционными устройствами RDM и DMX.

На сайте протокола RDM [4] и его форумах можно найти сообщество, помогающее производителям и разработчикам, применяющим RDM в своих продуктах, или пользователям, которым нужно больше информации, или у которых есть вопросы по RDM. Организация ESTA не связана с сайтом и не управляет им, однако этот сайт лучший источник информации, поскольку на нем активно работают многие разработчики протокола RDM.

[Словарик]

Респондер в буквальном переводе "ответчик". В контексте протокола RDM это подчиненное устройство в сети (светильник, сплиттер и т. п.), которое может отвечать (передавать данные) в ответ на запрос мастера сети (например консоли управления освещением).

Скроллер рекламное табло, предназначенное для динамической рекламы наподобие бегущей строки.

Сплиттер в буквальном переводе означает "разделитель". Это устройство, которое разделяет сеть DMX512 (или RDM, в зависимости от стандарта, который поддерживает сплиттер) на отдельные физические сегменты, не связанные друг с другом напрямую. Цель такого разделения - буферизирование, усиление сигнала на длинных линиях (чтобы уменьшить искажения и помехи в сигнале на линии). Насколько я смог понять, многие устройства RDM на самом деле являются сплиттерами RDM, что не мешает им нормально работать совместно с консолью DMX и устройствами DMX. Обратное не верно - через сплиттер DMX сигнал RDM в обратном направлении не пройдет.

[Ссылки]

1. RDM (lighting) site:en.wikipedia.org.
2. Что такое DMX512?
3. RDM Responder Testing site:www.opendmx.net.
4. RDM Protocol Homepage site:www.rdmprotocol.org.
5. RDM Manufacturer Library site:rdm.openlighting.org.