Arquitectura para redes de control

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)

La arquitectura para redes de control ( ACN ) es un conjunto de protocolos de red para el control de equipos de tecnología de entretenimiento, en particular los utilizados en espectáculos en vivo o instalaciones a gran escala. Por ejemplo, equipos de iluminación, audio o efectos especiales. La ACN es mantenida por la Asociación de Servicios y Tecnología de Entretenimiento y su primera publicación oficial fue la Norma ANSI E1.17-2006 - Tecnología de entretenimiento - Arquitectura para redes de control. La norma fue revisada posteriormente y publicada como ANSI E1.17-2010.

ACN fue diseñado inicialmente para ser colocado sobre UDP/IP y, por lo tanto, se ejecutará sobre la mayoría de los transportes IP , incluidas las redes Ethernet y 802.11 ( Wi-Fi ) estándar y económicas .

ACN define una arquitectura de protocolo común, dos protocolos de red principales (SDT, DMP), un lenguaje de descripción de dispositivos (DDL) y una serie de "Perfiles E1.17 para interoperabilidad" (conocidos como EPI o perfiles de interoperabilidad ) que definen cómo se deben utilizar los elementos de la arquitectura ACN 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.

La división de ACN en subprotocolos, perfiles de interoperabilidad y otras pequeñas piezas ha sido criticada ^{[¿ por quién? ]} por hacer que ACN sea difícil de leer y entender, pero hace que la arquitectura sea altamente modular y esté claramente estructurada en capas, lo que 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 sobre TCP así como sobre SDT como se define en el estándar inicial, DDL se ha adaptado con pocos cambios para describir dispositivos a los que se accede mediante DMX512 (ANSI E1.31/Streaming ACN), y varios perfiles de interoperabilidad han experimentado una revisión o reemplazo importante sin alterar las otras partes del estándar.

La especificación de arquitectura común define un formato de unidades de datos de protocolo (PDU) anidadas, bastante similar a la codificación TLV , que se utilizan en los protocolos principales. Luego define cómo se utiliza un protocolo de capa raíz mínimo para unir 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 .

Session Data Transport (SDT) es un protocolo de transporte de multidifusión confiable que opera sobre UDP/IP y que se puede utilizar para agrupar pares dentro de una red en sesiones y enviarles mensajes de forma individual o en grupo. La entrega de mensajes se ordena y los mensajes se pueden enviar 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 un estado en línea para que un componente detecte cuando se interrumpe una conexión. SDT proporciona un alto grado de ajuste fino sobre el equilibrio entre latencia, niveles de confiabilidad y requisitos de recursos, y la disponibilidad de una gran cantidad 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.

El Protocolo de administración de dispositivos (DMP) representa cualquier dispositivo como un conjunto de propiedades direccionables que representan su estado actual o deseado. La supervisión o el 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 ), el DMP proporciona un mecanismo de suscripción mediante el cual un dispositivo enviará de forma asincrónica mensajes de eventos a todos los controladores suscritos cuando cambie el valor de una propiedad.

DMP espera que sus conexiones puedan proporcionar confiabilidad de modo que los mensajes de configuración de propiedades y eventos , que forman una gran parte del ancho de banda operativo en una situación de presentación, no requieran un reconocimiento explícito en el 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 utilizado con TCP para proporcionar 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án determinados por el protocolo, que solo define el mecanismo para leer y/o escribir el valor de la propiedad. En cambio, esa información debe ser proporcionada externamente por una descripción del dispositivo escrita en DDL o, en casos limitados, puede ser preprogramada mediante el conocimiento previo de tipos de dispositivos específicos.

El lenguaje de descripción de dispositivos (DDL) permite definir una descripción de la interfaz y las capacidades de cualquier dispositivo que pueda analizarse por máquina. ^[1] Esta descripción puede ser interpretada por un controlador que puede configurarse automáticamente para controlar ese dispositivo. La descripción no solo proporciona la información de mapeo de direcciones y propiedades que es necesaria para que el lenguaje de descripción de dispositivos (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 que necesita para su contexto específico y omitir la información que no es relevante para sus necesidades. ^[2]

DDL es un lenguaje basado en XML y las descripciones se encuentran en una pequeña cantidad de documentos XML . En sistemas ACN normales, la descripción de un dispositivo se puede descargar desde el propio dispositivo. Sin embargo, las descripciones también se pueden distribuir de otras maneras (como por ejemplo mediante descargas 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.

Los perfiles de interoperabilidad (EPI) se proporcionan en ANSI E1.17 para el descubrimiento inicial de servicios en un sistema; para la asignación de direcciones de multidifusión cuando se utilizan en UDP e IPv4 ; para la asignación de puertos UDP durante la multidifusión, para la asignación de direcciones IP en sistemas compatibles, para los tiempos de espera de protocolo en entornos específicos, etc. Se han desarrollado otros EPI que cumplen con la arquitectura ACN fuera del estándar ANSI E1.17 (ver a continuación).

Gracias a su naturaleza modular, ACN ha sido fácil de ampliar.

La misma organización desarrolló un protocolo principal 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 DMX512 a través de redes IP (o cualquier otro transporte compatible con ACN).

PLASA ha desarrollado y estandarizado otros perfiles de interoperabilidad, entre los que se incluyen los siguientes:

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

Una implementación temprana de código abierto de ACN fue lanzada como OpenACN ^[3] y está disponible en SourceForge . Esta implementación ha sido trasladada a una amplia gama de plataformas, pero su alcance es limitado y no implementa ningún soporte DDL.

Existe otro proyecto ACN de código abierto ^[4] que se implementa en C# . Su objetivo es proporcionar una implementación de código completamente administrado e incluye código para varios otros protocolos relacionados.

Una implementación completa titulada Acacian ^[5] en C , que incluye el análisis de descripciones DDL para generar estructuras DMP, se lanzó bajo la Licencia Pública de Mozilla en 2014.

E1.31 (Transmisión DMX a través de ACN) es compatible con Linux ( ARM , i386 , x86-64 ) y Macintosh ( PowerPC ; i386, x86-64) mediante 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 empresas, incluido Electronic Theatre Controls (ETC) como base de su infraestructura de control en red de marca 'NET3' y por Shure Inc. en el control de micrófonos inalámbricos.

• 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 a través de UDP/IP
• Arquitectura de control abierta para el control y monitoreo de dispositivos de audio y video en red

• Programa de Normas Técnicas de ESTA