Architecture for Control Networks ( ACN ) es un conjunto de protocolos de red para el control de equipos de tecnología de entretenimiento, particularmente cuando se usan en presentaciones en vivo o instalaciones a gran escala. Por ejemplo, equipos de iluminación, audio o efectos especiales. ACN es mantenido por Entertainment Services and Technology Association y su primer lanzamiento oficial fue ANSI Standard E1.17-2006 - Entertainment Technology - Architecture for Control Networks. La norma fue posteriormente revisada y publicada como ANSI E1.17-2010.
Estándar internacional | Estándar ANSI E1.17-2006 |
---|
ACN se diseñó inicialmente para colocarse sobre UDP / IP y, por lo tanto, se ejecutará en la mayoría de los transportes IP , incluidas las redes Ethernet estándar y económicas y 802.11 (Wi-Fi).
Arquitectura de protocolo
ACN define una arquitectura de protocolo común, dos protocolos de red principales (SDT, DMP), un lenguaje de descripción de dispositivo (DDL) y una serie de 'Perfiles de interoperabilidad E1.17' (conocidos como EPI o perfiles de interoperabilidad ) que definen cómo los elementos de la arquitectura ACN debe usarse en un contexto particular para lograr la interoperabilidad. Por ejemplo, proporcionando valores o rangos específicos para los parámetros de temporización que se utilizarán en un entorno de red particular.
El desglose de ACN en subprotocolos, perfiles de interoperabilidad y otras pequeñas piezas ha sido criticado [¿ por quién? ] hace que ACN sea difícil de leer y entender, pero hace que la arquitectura sea altamente modular y con capas limpias y esto ha permitido que muchas de las piezas se operen en otros contextos o se reemplacen o revisen sin cambiar las otras piezas. Por ejemplo, DMP se ha operado tanto a través de TCP como a través de SDT como se define en el estándar inicial, DDL se ha adaptado con pocos cambios para describir los dispositivos a los que se accede mediante DMX512 (ANSI E1.31 / Streaming ACN), y se han visto varios perfiles de interoperabilidad. revisión o reemplazo importante sin alterar las otras partes de la norma.
Arquitectura común
La especificación de arquitectura común define un formato de unidades de datos de protocolo anidado (PDU), bastante similar a la codificación TLV , que se utilizan en los protocolos principales. A continuación, define cómo se utiliza un protocolo de capa raíz mínimo para empalmar los protocolos de nivel superior en un transporte de nivel inferior y define dicho protocolo de capa raíz utilizando el formato PDU para su uso en UDP / IP .
Transporte de datos de sesión
El transporte de datos de sesión (SDT) es un protocolo de transporte de multidifusión confiable que opera sobre UDP / IP que se puede usar para agrupar pares dentro de una red en sesiones y entregarles mensajes individualmente o como grupo. La entrega de mensajes está ordenada y los mensajes pueden enviarse de forma selectiva de manera confiable o no confiable mensaje por mensaje (la confiabilidad es muy importante para algunos datos, mientras que evitar la sobrecarga de tiempo y recursos del mecanismo de confiabilidad es beneficioso para otros). El mecanismo de confiabilidad también proporciona el estado en línea para que un componente detecte cuando se interrumpe una conexión. SDT proporciona un alto grado de ajuste fino sobre la compensación entre latencia, niveles de confiabilidad y requisitos de recursos, y la disponibilidad de un gran número de sesiones simultáneas significa que son una herramienta poderosa para agrupar y administrar componentes cuyas funciones están relacionadas o cuyos requisitos de comunicación son similares. .
Protocolo de administración de dispositivos
El Protocolo de administración de dispositivos (DMP) representa cualquier dispositivo como un conjunto de propiedades direccionables que representan su estado actual o deseado. El monitoreo o control por parte de un controlador se logra estableciendo o examinando los valores de esas propiedades. Para evitar las ineficiencias del sondeo, además de simplemente leer los valores de las propiedades (usando un mensaje Get-Property ), DMP proporciona un mecanismo de suscripción mediante el cual un dispositivo enviará mensajes de eventos de forma asincrónica a todos los controladores suscritos cuando el valor de una propiedad cambie.
DMP espera que sus conexiones puedan proporcionar confiabilidad de modo que los mensajes de eventos y propiedades del conjunto que forman una gran parte del ancho de banda operativo en una situación de exhibición no requieran un reconocimiento explícito a nivel de DMP. En el estándar E1.17 y en la mayoría de los sistemas, SDT proporciona esta confiabilidad, pero DMP también se ha operado usando TCP para proporcionar sus conexiones confiables.
El tamaño en bits, la representación, la accesibilidad de lectura / escritura y la función de cada propiedad en un dispositivo DMP no está determinada por el protocolo que solo define el mecanismo para leer y / o escribir el valor de la propiedad. En cambio, esa información debe proporcionarse externamente mediante una descripción del dispositivo escrita en DDL o, en casos limitados, puede estar preprogramada mediante el conocimiento previo de tipos de dispositivos específicos.
Idioma de descripción del dispositivo
El lenguaje de descripción de dispositivo (DDL) permite definir una descripción analizable por máquina de la interfaz y las capacidades de cualquier dispositivo. [1] Esta descripción puede ser interpretada por un controlador que luego puede configurarse automáticamente para controlar ese dispositivo. La descripción no solo proporciona la información de asignación de direcciones y propiedades que es necesaria para que DMP funcione, sino que también puede contener una gran cantidad de información sobre la funcionalidad, las capacidades y la semántica del dispositivo en un formato extensible que permite a un controlador extraer las características. necesita para su contexto específico mientras se salta la información que no es relevante para sus necesidades. [2]
DDL es un lenguaje basado en XML y las descripciones están contenidas en una pequeña cantidad de documentos XML . En los sistemas ACN normales, la descripción de un dispositivo se puede descargar desde el propio dispositivo. Sin embargo, las descripciones también pueden distribuirse de otras formas (como la descarga de Internet) y, dado que una descripción es válida para todos los dispositivos del mismo tipo, los controladores normalmente pueden mantener un caché de descripciones para los dispositivos que encuentran comúnmente.
Perfiles de interoperabilidad
Los perfiles de interoperabilidad (EPI) se proporcionan en ANSI E1.17 para el descubrimiento de servicios inicial en un sistema; para la asignación de direcciones de multidifusión cuando se utiliza en UDP e IPv4 ; para la asignación de puertos UDP en multidifusión, para la asignación de direcciones IP en sistemas compatibles, para tiempos de espera de protocolo en entornos específicos, etc. Otros EPI que cumplen con la arquitectura ACN se han desarrollado fuera del estándar ANSI E1.17 (ver más abajo).
Extensiones externas
Debido a su naturaleza modular, ACN ha sido fácil de ampliar.
La misma organización desarrolló un protocolo importante ANSI E1.31 conocido como Streaming ACN o sACN y utiliza la capa raíz y el formato PDU de ACN para transportar los datos de DMX512 a través de redes IP (o cualquier otro transporte compatible con ACN).
PLASA ha desarrollado y estandarizado varios perfiles de interoperabilidad adicionales. Éstas incluyen:
ANSI E1.30-3-2009 Referencia de tiempo en sistemas ACN que utilizan SNTP y NTP ANSI E1.30-4-2010 que define cómo utilizar DDL para describir dispositivos controlados mediante DMX512 o Streaming ACN
Implementaciones
Una de las primeras implementaciones de código abierto de ACN fue lanzada como OpenACN [3] y está disponible en SourceForge . Esto se ha adaptado a una amplia gama de plataformas, pero tiene un alcance limitado y no implementa ningún soporte DDL.
Una implementación más reciente y mucho más completa en C es 'Acacian', [4] que incluye más funciones y soporte DDL.
Hay otro proyecto ACN de código abierto [5] en Codeplex que se implementa en C # . Esto tiene como objetivo proporcionar una implementación completa de código administrado e incluye código para varios otros protocolos relacionados.
E1.31 (Streaming DMX sobre ACN) es compatible con Linux ( ARM , i386 , x86-64 ) y Macintosh ( PowerPC ; i386, x86-64) por la Arquitectura de iluminación abierta. [6]
Se puede encontrar una implementación de Rust de E1.31 en GitHub . [7]
ACN ha sido implementado en implementaciones patentadas por varias compañías, incluido su uso por Electronic Theatre Controls (ETC) como la base de su infraestructura de control en red de marca 'NET3' y por Shure Inc. en el control de micrófonos inalámbricos.
Ver también
- Sistemas de control de iluminación para edificios o residencias.
- Consolas de control de iluminación para iluminación de escenarios y otros dispositivos DMX-512
- Art-Net , un protocolo propietario para transmitir DMX-512 sobre UDP / IP
- Arquitectura de control abierta para el control y monitoreo de dispositivos de audio y video en red
Referencias
- ^ http://engarts.com/ddl/index.html
- ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 29 de noviembre de 2014 . Consultado el 17 de noviembre de 2014 .CS1 maint: copia archivada como título ( enlace )
- ^ "OpenACN" . Consultado el 25 de agosto de 2011 .
- ^ "Acaciano" . Consultado el 28 de abril de 2020 .
- ^ "Página de inicio del proyecto Arquitectura para Redes de Control" . Consultado el 5 de octubre de 2011 .
- ^ "Arquitectura de iluminación abierta" . Consultado el 5 de enero de 2012 .
- ^ "óxido-sacn" . Consultado el 16 de diciembre de 2015 .
enlaces externos
- Programa de normas técnicas de la ESTA