Architecture for Control Networks

ACN brings show control to the next level. Learn more how to make use of the latest and greatest show control protocol.

BSR E.17 Architecture for Control Networks - ACN

What is ACN ?

The ACN (Architecture for Control Network) is a new protocol suite for controlling electrical equipment in the entertainment industry. ACN was developed by the Enterntainment Services and Technology Association (ESTA). The standard was developed by the Technical Standards Working Group and is supported by several well known manufacturers of lighting controllers and devices.

This website will provide some introduction regarding the technology used by ACN. The information provided here is taken from the current drafts of the E1.17 standard.

Why do we need it ?

In 1990 DMX-512 (digital multiplex) was introduced by the USITT to digitally control dimmer racks. Today DMX technolgy is "the" standard for the digital control of lighting equipment in the entertainment industry. It is supported by almost all manufacturers of lighting equipment all over the world.

So why do we need new standards ?

Expectations, Needs but also Capabilities are greater

The features of lighting equipment changed during the last years. In the 70th the word "lighting" was equivalent to "set up some dimmer racks and Par cans". Today lighting professionals face new challenges. Current productions use complex (and even more expensive) gear: several dozends (if not even hundreds) of automated fixtures, moving truss, video walls, LED curtains and laser technology, pyrotechnics, digital sound reinforcement systems just to mention some few. Today engineers have to assemble/integrate all these different technologies to one large system which can then be controlled by a few (or even one single) operator.

DMX with it's 512 channels one way transmission can only address few of today's controlling requirements. Fortunately the growth of the internet lead to the development of high performance networking technologies which can now be used even for the control of equipment used by the entertainment industry.

  • Performance: Modern lighting fixtures require larger quantities of control data. Video walls and LED curtains require a significant amount of control data. These devices typically already require high bandwidth connections. DMX-512 does not provide enough bandwidth to support these devices, while networks carrying ACN traffic are available up to speeds of multiple Gigabit per second.
  • Scalability and Extensibility: Today, venues are getting larger and larger. Each DMX link can carry just 512 bytes of dimmer data. As a result, current lighting consoles have to support dozens of DMX universes to control all lighting fixtures. ACN is able to control small systems containing some few dimmer channels but also large complex systems containing huge numbers of automated fixtures.
  • Any IP network: DMX-512 specifies a physical transmit layer (RS485). ACN does not. It runs over any network which can carry IP traffic (e.g. Ethernet, WiFi, xDSL, GPON, GSM/GPRS, LTE, serial connections). So why not controlling a show from the other side of the world via the Internet?
  • Use of already developed technology: As ACN is supported by any IP based network, show designers can take advantage of the huge pool of standard (and therefore cheap) network gear and can integrate the latest, best suited devices in their shows. WiFi technology and Ethernet data cabling are widely spread in buildings, RS485 cabling is not. Using ACN in architectural lighting can reuse the existing infrastructure.
  • Autoconfiguration: Tired from manually selecting unique DMX addresses and channel assignments for each device ("Are Pan and Tilt transmitted as 16 bit or 8 bit values ? Does channel 3 select the gobo or color ?")? ACN devices register themselves at the lighting controller and report back their capabilities. No need to fiddle around with addresses and channel assignments.
  • Faul tolerance and bidirectional communication: Some equipment has special requirements regarding reliability e.g. pyrotechnics or chain hosts. The ACN protocol can guarantee the delivery of messages to the destination. The communication is bidirectional. Devices can report their status to the lighting controller.
  • Many sources, many sinks: Any device can talk to any other device at any time. Fixtures can be controlled by multiple consoles at the same time.
  • Interoperatability: Lighting controllers shall be able to communicate with equipment of different type from different manufacturers.

What ACN cannot provide

Timing accuracy and Reliability: ACN uses internet (mainly Ethernet) technology for data transmission and cannot guarantee delivery times. The time required to send a message from the controller to the destination depends on the distance (i.e. number of switches and routers on the track) and the traffic on the network and cannot be predicted. By using multicast addressing special emphasize has been put on the reduction of message size and thus network traffic. In addition modern ethernet networks provide enough bandwidth, that this should be no limitation (e.g. a 1GBit Ethernet Network can transport the data of 4000 DMX universes at the same time).

UDP packages on the network may be discarded by network equipment on their way at any time. The ACN protocol (to be more precise: the SDT component) ensures, that at the end the receiver gets all packages originating from the sender. Packets which were dropped on their way to the destination (and which have therefore not been acknowledged by the receiver) are resent by the controller. In timing critical applications like chain hosts or pyrotechnics where human safety is affected, this fact can be a concern.

Security: ACN does not specify any user access rights for equipment usage. Everyone connected to the network is allowed to establish a connection with any device in order to control it. In closed networks this should be no problem. In open networks and especially in networks connected to the world wide Internet or when using WiFi the networking hardware (i.e. routers, firewalls) are responsible to filter ACN network traffic appropriately.

So how does it look like ?

The diagram below shows the components required for a complete implementation of the ACN protocol suite. ACN uses a TCP/IP (to be more precise: UDP/IP) protocol stack for communicating with devices. In most cases the transport layer will be some form of Ethernet (e.g. IEEE802.3, IEEE802.11).

Components which are exclusively described in the ESTA E1.17 are marked in orange. Components which are marked green have been defined by the internet industry. The related standards can be found in the RFC (request for comments) files at the website of the Internet Engineering Task Force. The E1.17 standard refers to these components (predominantly in the so called EPIs "E1.17 Profiles for Interoperatability") or they are simply always required to establish a communication using TCP/IP. Most of them are usually provided with the TCP/IP stack by the operating system (at least as long as you are not a manufacturer of non PC based equipment).

The SLP component is special. Although it is not ACN specific, most commercially available operating systems (Windows, Linux) do not provide it in their distribution packages (thus there seem to be not too many SLP users out there up to now). However there is an Open Source solution available which runs on several operating systems called OpenSLP.

Components marked in blue are absolutely optional and are not covered by the ACN framework at all. As you can see, ACN does not require the implementation of a TCP stack ! Nevertheless users will definitely want to configure their gear via web browsers. Equipment manufacturers should also think of (non timing critical) applications like architectural lighting, museums or theme parks, where users may desire to control their lighting devices using well established protocols which are based on TCP (e.g. SMTP, HTTP, ...).

As you can see from the diagram below, the ACN protocol suite is obviously not a trivial low cost solution. Thus, one can assume that the DMX protocol will still be alive throughout the next years especially in the low end / comsumer market.

OK, I am interested ... tell me how it works !