|
|
|
Home & Information
Technical Support
ADB Products
Related Products |
Technical FAQ 
Navigation:
HOME |
Technical FAQ overview
> communictaion protocols
> ACN
|
ACN: Advanced Control Network Communication Protocol
The following information is taken from the ESTA website. It outlines the design goals of the ACN communication protocol.
ESTA's Advanced Control Network (ACN) Protocol Suite
Overview and Goals
Revised 3/25/98
Introduction
The Advanced Control Network (ACN) is intended to provide the next generation standard for the distribution of data in lighting control networks.
ACN needs to do much more than just supercede DMX. Ideally, ACN will unify lighting control networking, allowing a single network to carry many different kinds of lighting-related data and to connect equipment from different manufacturers. ACN is not limited to lighting. It is expected that support for audio control and stage automation will also be incorporated.
There are several broad classes of issues to be considered, including:
- Network initialization, configuration, and management.
- Addressing and routing of messages
- Standardization of lighting-related data
Issues 1 and 2 constitute a network infrastructure to support the industry-specific data that is the subject of issue 3.
To address these different categories of issues and to handle cleanly the need for manufacturer-specific data types, we propose an architecture in which ACN consists of a suite of sub-protocols, analogous to the way that TCP/IP is the umbrella for IP, UDP, SNMP, etc.
Design Goals
The following list sketches some of the requirements for an advanced control network protocol:
- Interoperability across manufacturers
The protocol should enable various participating manufacturers' equipment to communicate usefully; e.g., to let one manufacturer's console control another manufacturer's dimmers or moving lights.
- Many sources, many sinks
The protocol should provide for multiple sources of control data on the same network, as well as multiple consumers of that data.
- One "wire" but multiple independent uses
The protocol should allow a single network to support multiple, independent uses. For example, in large, complex installations it will be desirable to dynamically configure sub-venues as independent universes of control, with independent addressing, etc. Another example: future extensions of the protocol will go beyond lighting into other kinds of control.
- A mainstream protocol
The protocol should be based upon mainstream internetworking transport-level protocols. For the foreseeable future, this means the TCP/IP protocol suite.
Note that the TCP/IP protocols are not tied to any specific underlying network. In that sense, ACN is not an Ethernet-based protocol, it is a TCP/IP-based protocol. TCP/IP means that technologies such as FDDI and ATM are automatically supported.
- Maximum opportunity to use off-the-shelf technology
The protocol should be designed to use the enormous variety of off-the-shelf networking hardware and software (routers, switches, hubs, protocol stacks, diagnostic tools, etc) available from third parties. Moreover, it should be designed so it can continue to "ride the wave" of the rapidly evolving state of the art in networking in the future.
- Support for manufacturer-specific uses
Only a subset of the control and data requirements of a modern lighting installation will be standardized industry-wide. The protocol should support manufacturer-specific extensions in an elegant way. The standardized subset should not be a conceptual orphan, but should fit in naturally with the protocol as a whole.
- Scalability
The protocol should adequately address the needs of the full range of size and complexity of lighting application. It should be simple enough for use on the smallest systems, but it also must scale up to networks controlling the lighting for hotel complexes, theme parks, etc.
- Extensibility
The protocol should be designed to be easily and cleanly extended over time to handle future requirements as they arise. The protocol must be "built to last."
- Ease of configuration
The protocol should provide a means for the network to be easily configured and managed. Ideally, devices should dynamically discover one another without user intervention.
- Efficient use of available bandwidth
The protocol should be reasonably frugal with network bandwidth.
- Flexibility and control with respect to subnetworks and routing
To achieve scalability and efficient use of available bandwidth, it is essential that the protocol not foreclose the normal range of options used to structure network traffic.
- Fault tolerance
The kinds of applications in which ACN will be used cannot tolerate frequent network failures. Nor can end-users be expected to have a high level of networking expertise. Ideally, network failures will be minimized and the network will recover gracefully and with a minimum of user intervention when failures do occur.
- Device feedback
The protocol should support feedback information (e.g., error or status information) originating in peripheral devices.
- Effective distribution of output level data
The protocol should support output level distribution in a flexible and effective way.
See also:
|
 |
 |