Введение

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

Архитектура сетей управления (ACN) – это набор сетевых протоколов для управления оборудованием индустрии развлечений, особенно используемым в живых выступлениях или масштабных инсталляциях. Например, оборудование для освещения, звука или спецэффектов. ACN поддерживается Ассоциацией услуг и технологий индустрии развлечений, и его первым официальным выпуском был стандарт ANSI E1.17 2006 «Технологии индустрии развлечений. Архитектура сетей управления». Стандарт был впоследствии пересмотрен и выпущен как ANSI E1.17 2010. ACN изначально разрабатывалась для работы поверх UDP/IP и, следовательно, может функционировать в большинстве IP-сетей, включая стандартные, недорогие сети Ethernet и 802.11 (Wi-Fi).

Архитектура протокола

ACN определяет общую архитектуру протокола, два основных сетевых протокола (SDT, DMP), язык описания устройств (DDL) и ряд «Профилей E1.17 для обеспечения взаимодействия» (известных как EPI или профили взаимодействия), которые определяют, как элементы архитектуры ACN должны использоваться в конкретном контексте для достижения взаимодействия. Например, путем указания конкретных значений или диапазонов для временных параметров, используемых в определенной сетевой среде. Разделение ACN на подпротоколы, профили взаимодействия и другие небольшие компоненты критиковалось за то, что оно затрудняет чтение и понимание ACN, но при этом делает архитектуру высокомодульной и четко структурированной, что позволило использовать многие компоненты в других контекстах или заменять или пересматривать их, не затрагивая остальные части. Например, DMP использовался как поверх TCP, так и поверх SDT, как это было определено в первоначальном стандарте, DDL был адаптирован с минимальными изменениями для описания устройств, к которым осуществляется доступ через DMX512 (ANSI E1.31/Streaming ACN), и несколько профилей взаимодействия были существенно пересмотрены или заменены, не нарушая работу других частей стандарта.

Общая архитектура

Общая архитектурная спецификация определяет формат вложенных протокольных данных (PDU), во многом схожий с кодировкой TLV, используемый в основных протоколах. Далее определяется, как минимальный протокол корневого уровня используется для объединения протоколов более высокого уровня с транспортным уровнем более низкого уровня, и определяется этот протокол корневого уровня с использованием формата PDU для работы поверх UDP/IP.

Транспорт данных сеанса

Транспорт данных сеанса (SDT) — это надежный протокол многоадресной передачи, работающий поверх UDP/IP, который позволяет объединять узлы в сети в сеансы и доставлять им сообщения индивидуально или группами. Доставка сообщений осуществляется в порядке их отправки, и каждое сообщение может быть отправлено выборочно — надежно или ненадежно (надежность критически важна для одних данных, в то время как для других предпочтительнее избежать временных и ресурсных затрат, связанных с механизмом обеспечения надежности). Механизм обеспечения надежности также предоставляет информацию о состоянии соединения, позволяя компоненту обнаруживать его разрыв. SDT обеспечивает высокую степень гибкой настройки баланса между задержкой, уровнями надежности и потреблением ресурсов, а возможность одновременной работы большого числа сеансов делает его мощным инструментом для группировки и управления компонентами со связанными функциями или схожими требованиями к обмену данными.

Протокол управления устройством

Протокол управления устройствами (DMP) представляет любое устройство как набор адресуемых свойств, отражающих его текущее или желаемое состояние. Мониторинг или управление устройством осуществляется путем установки или проверки значений этих свойств. Для повышения эффективности, помимо простого чтения значений свойств (с помощью сообщения Get Property), DMP предоставляет механизм подписки, при котором устройство асинхронно отправляет сообщения о событиях всем подписанным контроллерам при изменении значения свойства. DMP предполагает, что его соединения обеспечивают надежность, поэтому сообщения о свойствах и событиях, составляющие значительную часть операционной пропускной способности во время работы (например, в шоу), не требуют явного подтверждения на уровне DMP. В стандарте E1.17 и большинстве систем эту надежность обеспечивает SDT, однако DMP также может работать с использованием TCP для обеспечения надежных соединений. Размер в битах, формат представления, доступность для чтения/записи и функциональность каждого свойства в устройстве DMP не определяются протоколом, который лишь определяет механизм чтения и/или записи значения свойства. Вместо этого эта информация должна быть предоставлена извне в виде описания устройства, написанного на DDL, или, в ограниченных случаях, может быть предварительно запрограммирована на основе известных типов устройств.

Язык описания устройства

Язык описания устройств (DDL) позволяет определить машиночитаемое описание интерфейса и возможностей любого устройства. Это описание может быть интерпретировано контроллером, который затем может автоматически настроиться для управления этим устройством. Описание предоставляет не только информацию об адресе и сопоставлении свойств, необходимую для работы DMP, но и может содержать обширный объем информации о функциональности, возможностях и семантике устройства в расширяемом формате. Это позволяет контроллеру извлекать необходимые функции для своего конкретного контекста, игнорируя при этом нерелевантную информацию. DDL – это язык, основанный на XML, и описания содержатся в небольшом количестве XML-документов. В типичных системах ACN описание устройства может быть загружено непосредственно с устройства. Однако описания могут распространяться и другими способами (например, через интернет), и поскольку описание справедливо для всех устройств одного типа, контроллеры обычно могут поддерживать кэш описаний для часто встречающихся устройств.

Профили взаимодействия

Профили взаимодействия (EPI) определены в ANSI E1.17 для первоначального обнаружения служб в системе, для выделения многоадресных адресов при использовании UDP и IPv4, для выделения UDP-портов при многоадресной передаче, для назначения IP-адресов в соответствующих системах, для установки тайм-аутов протоколов в определенных средах и так далее. Другие EPI, соответствующие архитектуре ACN, были разработаны за пределами стандарта ANSI E1.17 (см. ниже).

Внешние расширения

Благодаря своей модульной структуре ACN легко поддавался расширению. Основной протокол ANSI E1.31, известный как Streaming ACN или sACN, был разработан той же организацией и использует корневой уровень и формат PDU ACN для передачи данных DMX512 по IP-сетям (или любому другому транспорту, совместимому с ACN). Ряд дополнительных профилей совместимости был разработан и стандартизирован PLASA. К ним относятся:

ANSI E1.30 3 2009 – Временная привязка в системах ACN с использованием SNTP и NTP
ANSI E1.30 4 2010 – определяющий способ использования DDL для описания устройств, управляемых с помощью DMX512 или Streaming ACN.