Архитектура для сетей управления

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Architecture for Control Networks" – news · newspapers · books · scholar · JSTOR (January 2012) (Learn how and when to remove this message)

Архитектура для сетей управления ( 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 .

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

Протокол управления устройствами (DMP) представляет любое устройство как набор адресуемых свойств, которые представляют его текущее или желаемое состояние. Мониторинг или управление контроллером достигается путем установки или проверки значений этих свойств. Чтобы избежать неэффективности опроса, в дополнение к простому считыванию значений свойств (с использованием сообщения Get-Property ) DMP предоставляет механизм подписки, посредством которого устройство будет асинхронно отправлять сообщения о событиях всем подписанным контроллерам при изменении значения свойства.

DMP ожидает, что его соединения могут обеспечить надежность, так что сообщения Set-Property и Event , которые составляют большую часть рабочей полосы пропускания в ситуации показа, не требуют явного подтверждения на уровне DMP. В стандарте E1.17 и большинстве систем SDT обеспечивает эту надежность, но DMP также работал с использованием TCP для обеспечения своих надежных соединений.

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

Язык описания устройств (DDL) позволяет определить машинно-анализируемое описание интерфейса и возможностей любого устройства. ^[1] Это описание может быть интерпретировано контроллером, который затем может автоматически настроить себя для управления этим устройством. Описание не только предоставляет информацию об адресе и сопоставлении свойств, которая необходима для работы DMP, но также может содержать огромное количество информации о функциональности, возможностях и семантике устройства в расширяемом формате, что позволяет контроллеру извлекать функции, необходимые для его конкретного контекста, пропуская информацию, которая не имеет отношения к его потребностям. ^[2]

DDL — это язык на основе XML , и описания содержатся в небольшом количестве XML- документов. В обычных системах ACN описание устройства может быть загружено с самого устройства. Однако описания могут также распространяться другими способами (например, загрузка через Интернет), и поскольку описание действительно для всех устройств одного типа, контроллеры обычно могут поддерживать кэш описаний для устройств, с которыми они часто сталкиваются.

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

Благодаря своей модульной структуре ACN легко расширяется.

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

PLASA разработала и стандартизировала ряд дополнительных профилей взаимодействия. К ним относятся:

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

Ранняя реализация ACN с открытым исходным кодом была выпущена как OpenACN ^[3] и доступна на SourceForge . Она была портирована на широкий спектр платформ, но ее область применения ограничена и она не реализует никакой поддержки DDL.

Есть еще один проект ACN с открытым исходным кодом ^[4] , который реализован на языке C# . Он направлен на обеспечение полной реализации управляемого кода и включает код для нескольких других связанных протоколов.

Полная реализация под названием Acacian ^[5] на языке C , которая включает в себя анализ описаний DDL для генерации структур DMP, была выпущена под лицензией Mozilla Public License в 2014 году.

E1.31 (потоковая передача DMX через ACN) поддерживается в Linux ( ARM , i386 , x86-64 ) и Macintosh ( PowerPC ; i386, x86-64) благодаря Open Lighting Architecture. ^[6]

Реализацию Rust E1.31 можно найти на GitHub . ^[7]

ACN была развернута в собственных реализациях рядом компаний, включая ее использование Electronic Theatre Controls (ETC) в качестве основы своей сетевой инфраструктуры управления под брендом «NET3», а также Shure Inc. для управления беспроводными микрофонами.

• Системы управления освещением зданий и жилых помещений
• Пульты управления освещением для сценического освещения и других устройств DMX-512
• Art-Net , фирменный протокол для передачи DMX-512 по UDP/IP
• Открытая архитектура управления для управления и мониторинга сетевых аудио- и видеоустройств

• Программа технических стандартов ESTA