Architecture for Control Networks: Difference between revisions

Revision as of 15:59, 3 September 2012

Latest revision as of 17:21, 9 August 2025

(46 intermediate revisions by 26 users not shown)

Line 1:

{{Short description|Network protocols for control of entertainment technology equipment}}

{{Refimprove|date=January 2012}}

{{Infobox protocol

'''Architecture for Control Networks''' ('''ACN''') is a suite of [[network protocol]]s for [[show control]] developed by [[Entertainment Services and Technology Association]] (ESTA). The first official release is formally referred to as ANSI E1.17 - 2006 - Entertainment Technology - Architecture for Control Networks.

| name = Architecture for Control Networks

| image = <!--without [[File:...]] syntax-->

| caption =

| standard = [[ANSI]] Standard E1.17-2006

| developer = <!--organization(s) involved in development-->

| introdate = <!--{{Start date|YYYY|MM|DD}}-->

| industry = <!--industries used (such as PC/Chemical/Multimedia)-->

| connector = <!--connector(s) usable with protocol-->

| hardware = <!--examples of compatible hardware-->

| range = <!--{{convert|X|mi|abbr=on}}-->

| newer = <!--superseded by which protocol-->

}}

'''Architecture for Control Networks''' ('''ACN''') is a suite of [[network protocol]]s for [[show control]] developedof entertainment technology equipment, particularly as used in live performance or large-scale installations. For example, lighting, audio or special effects equipment. ACN is maintained by [[Entertainment Services and Technology Association]] (ESTA).and Theits first official release is formally referred to aswas [[ANSI]] Standard E1.17 - 2006 - Entertainment Technology - Architecture for Control Networks. The standard was subsequently revised and released as ANSI E1.17-2010.

It was designed as a replacement for [[DMX (lighting)|DMX]] as the control protocol for lighting systems and can be used for controlling more complex devices like video playback servers (media servers) and [[audio mixer]]s. The protocol is designed to be layered on top of [[User Datagram Protocol|UDP/IP]] and therefore will run over standard, inexpensive [[Ethernet]] and [[802.11]] (Wi-Fi) network links.

ACN was initially designed to be layered on top of [[User Datagram Protocol|UDP/IP]] and therefore will run over most [[Internet Protocol|IP]] transports including standard, inexpensive [[Ethernet]] and [[802.11]] ([[Wi-Fi]]) networks.

ACN relies on UDP in order to pass its messages. Where reliability is required, the Session Data Transport sub protocol allows semi-reliability of only the latest value for a particular "channel".

{{IPstack}}

==Protocol architecture==

The ACN defines a common protocol mayarchitecture, betwo furthermajor definednetwork viaprotocols interoperability(SDT, profilesDMP), whicha willdevice extenddescription variouslanguage layers(DDL) and a number of the‘E1.17 ACNProfiles stack,for Interoperability’ (known as ''EPI''s or ''[[#Interoperability profiles|interoperability profiles]]'') which define how elements of the ACN architecture must be used in a particular situationcontext to achieve interoperability. For example, by providing specific values or ranges for timing parameters to be used in a particular network environment.

ACN defines a number of sub protocols. These protocols all follow the [[Type-length-value|TLV]] style '''Protocol Data Units''' ('''PDU'''). These can be nested in predefined hierarchy.

The breakdown of ACN into sub-protocols, interoperability profiles and other small pieces has been criticized{{by whom|date=January 2016}} as making ACN hard to read and understand but it makes the architecture highly modular and cleanly layered and this has allowed many of the pieces to be operated in other contexts or replaced or revised without changing the other pieces. For example, DMP has been operated over TCP as well as over SDT as defined in the initial standard, DDL has been adapted with little change to describe devices accessed by DMX512 (ANSI E1.31/Streaming ACN), and several interoperability profiles have seen major revision or replacement without disturbing the other parts of the standard.

The Protocols defined in ANSI E1.17 are:

* Root Layer Protocol for [[UDP/IP|UDP]]

* Session Data Transport Protocol (SDT)

* Device Management Protocol (DMP)

===Common Architecture===

There is also an XML description language which defines properties of the devices which is called the Device Description Language.

The common architecture specification defines a format of nested [[protocol data unit]]s (PDUs), rather similar to [[Type–length–value|TLV]] encoding, which are used in the main protocols. It then defines how a minimal Root Layer Protocol is used to splice the higher level protocols into a lower level transport and defines such a Root Layer Protocol using the PDU format for use on [[User Datagram Protocol|UDP/IP]].

==Interoperability profiles==

The ACN protocol may be further defined via interoperability profiles which will extend various layers of the ACN stack, or define how elements of the ACN architecture must be used in a particular situation to achieve interoperability. For example, by providing specific values for timing parameters to be used in a particular network environment.

* ===Session Data Transport Protocol (SDT)===

Session Data Transport (SDT) is a [[reliable multicast]] transport protocol which operates over [[User Datagram Protocol|UDP/IP]] which can be used to group peers within a network into ''sessions'' and deliver messages to them individually or as a group. Message delivery is ordered and messages may be selectively sent [[Reliability (computer networking)|reliably or unreliably]] on a message-by-message basis (reliability is very important for some data while avoiding the time and resource overhead of the reliability mechanism is beneficial for others). The reliability mechanism also provides online status so a component will detect when a connection is broken. SDT provides a high degree of fine tuning over the trade-off between latency, reliability levels and resource requirements and availability of large numbers of concurrent sessions means they are a powerful tool for grouping and managing components whose functions are related or whose communication requirements are similar.

* ===Device Management Protocol (DMP)===

Device Management Protocol (DMP) represents any device as a set of addressable properties which represent its current or desired state. Monitoring or control by a controller is achieved by setting or examining the values of those properties. To avoid the inefficiencies of polling, in addition to simply reading property values (using a ''Get-Property'' message) DMP provides a subscription mechanism whereby a device will asynchronously send event messages to all subscribed controllers when the value of a property changes.

DMP expects that its connections can provide reliability so that ''Set-Property'' and ''Event'' messages which form a large part of the operational bandwidth in a show situation do not require explicit acknowledgement at the DMP level. In the E1.17 standard and the majority of systems SDT provides this reliability but DMP has also been operated using TCP to provide its reliable connections.

The size in bits, representation, read/write accessibility and function of each property in a DMP device is not determined by the protocol which only defines the mechanism to read and/or write the property value. Instead, that information must either be provided externally by a device description written in DDL or in limited cases may be pre-programmed by fore-knowledge of specific device types.

===Device Description Language===

Device Description Language (DDL) allows a machine parsable description of the interface and capabilities of any device to be defined.<ref name="EngArts">{{Cite web|url=http://www.engarts.com/ddl/index.html|title=Device Description Language}}</ref> This description can be interpreted by a controller which may then automatically configure itself for controlling that device. The description not only provides the address and property mapping information which is necessary for DMP to operate but it can also contain a huge amount of information on the functionality, capabilities and semantics of the device in an extensible format which allows a controller to extract the features it needs for its specific context while skipping over information which is not relevant to its needs.<ref>{{Cite web |url=http://powers.media.mit.edu/wiki/upload/E1-17ACN2006DDL.pdf |title=ANSI E1.17-2006 Architecture for Control Networks - Device Description Language (DDL) |archive-url=https://web.archive.org/web/20141129101447/http://powers.media.mit.edu/wiki/upload/E1-17ACN2006DDL.pdf |archive-date=2014-11-29 |url-status=dead }}</ref>

DDL is an [[XML]] based language and descriptions are contained in a small number of [[XML]] documents. In normal ACN systems the description for a device may be downloaded from the device itself. However, descriptions may also be distributed in other ways (such as internet download) and since a description is valid for all devices of the same type, controllers can typically maintain a cache of descriptions for devices they commonly encounter.

===Interoperability profiles===

Interoperability profiles (EPIs) are provided in ANSI E1.17 for initial [[service discovery]] in a system; for allocation of [[multicast address]]es when used on UDP and [[IPv4]]; for [[Port (computer networking)|UDP port]] allocation when multicasting, for [[IP address]] assignment in conformant systems, for protocol timeouts in specific environments and so on. Other EPIs which conform to the ACN Architecture have been developed outside the ANSI E1.17 standard (see below).

==External extensions==

Due to its modular nature ACN has been easy to extend.

A major protocol '''ANSI E1.31''' known as '''Streaming ACN''' or '''sACN''' was developed by the same organization and uses the Root Layer and PDU format of ACN to transport the data of [[DMX512]] data over IP networks (or any other ACN compatible transport).

A number of further Interoperability Profiles have been developed and standardized by PLASA. These include:

ANSI E1.30-3-2009 ''Time Reference in ACN Systems Using SNTP and NTP''

ANSI E1.30-4-2010 which defines how to use DDL to describe devices controlled using DMX512 or Streaming ACN

==Implementations==

E1.31 (Streaming DMX over ACN) is supported on [[Linux]] ([[ARM architecture|ARM]]; [[Intel 80386|i386]], [[x86-64]]), and [[Macintosh]] ([[PowerPC]]; i386, x86-64) by the Open Lighting Architecture.<ref>{{cite web |url=http://opendmx.net/index.php/OLA |title=Open Lighting Architecture |accessdate=2012-01-05}}</ref>

ThereAn isearly currently an OpenACN implementation project in progress which is hosted by SourceForge. This will provide[[Open-source software|open -source library]] implementation which is intended to be portable to a variety of platformsACN fromwas smallreleased embeddedas devices, to Windows and [[POSIX]] conformant operating systems.OpenACN<ref>{{cite web |url=httphttps://sourceforge.net/projects/openacn/ |title=OpenACN |accessdate=2011-08-25}}</ref><ref>{{cite weband is |url=http://wwwavailable on [[SourceForge]].openacn.org/ |title=OpenACNThis has homebeen pageported |accessdate=2011-08-25}}</ref>to a wide range of platforms, but it is limited in its scope and does not implement any DDL support.

There is another open source ACN project<ref>{{cite web|url=https://github.com/HakanL/ACN|title=Architecture for Control Networks project home page|website=[[GitHub]] |accessdate=2022-03-09}}</ref> which is implemented in [[C Sharp (programming language)|C#]]. This aims to provide a full [[managed code]] implementation and includes code for several other related protocols.

An full implementation entitled Acacian<ref>{{cite web|url=https://github.com/hoyes/acacian|title=Acacian project on GitHub|website=[[GitHub]] |accessdate=2022-05-05}}</ref> in [[C (programming language)|C]], which includes parsing of DDL descriptions to generate DMP structures was released under the [[Mozilla Public Licence]] in 2014

E1.31 (Streaming DMX over ACN) is supported on [[Linux]] ([[ARM architecture|ARM]];, [[Intel 80386|i386]], [[x86-64]]), and [[Macintosh]] ([[PowerPC]]; i386, x86-64) by the Open Lighting Architecture.<ref>{{cite web |url=http://opendmx.net/index.php/OLA |title=Open Lighting Architecture |accessdate=2012-01-05}}</ref>

A [[Rust (programming language)|Rust]] implementation of E1.31 can be found on [[GitHub]].<ref>{{cite web |url=https://github.com/RustLight/sacn |title=RUST Sacn |website=[[GitHub]] |accessdate=2022-03-09}}</ref>

ACN has been deployed in proprietary implementations by a number of companies, including its use by Electronic Theatre Controls (ETC) as the basis of their 'NET3' branded networked control infrastructure and by [[Shure|Shure Inc.]] in control of wireless microphones.

There is yet another open source ACN project on [[Codeplex]] which is implemented in C# and aims to provide a full managed code implementation of the standard and many of the sub protocols associated with ACN.<ref>{{cite web|url=http://acn.codeplex.com/|title=Architecture for Control Networks project home page|accessdate=5 October 2011}}</ref>

== See also ==

Line 33 ⟶ 81:

* [[Lighting control console]]s for stage lighting and other DMX-512 devices

* [[Art-Net]], a proprietary protocol for transmitting DMX-512 over UDP/IP

* [[Open Control Architecture]] for control and monitoring of networked audio and video devices

==References==

Line 38 ⟶ 87:

==External links==

* [https://web.archive.org/web/20060111182052/http://www.esta.org/tsp/working_groups/CP/projs.html ESTA's Technical Standards Program]

* [http://engarts.com/acn/ ACN information]

* [http://www.esta.org/tsp/working_groups/CP/projs.html ESTA's Technical Standards Program]

[[Category:Stage lighting]]

[[Category:Internet protocolsStandards]]

[[Category:Internet standards]]

[[Category:Application layer protocols]]