Open Control Architecture

The Open Control Architecture (OCA) is a communications protocol architecture for control, monitoring, and connection management of networked audio and video devices. Such networks are referred to as "media networks". The official specification of OCA is the Audio Engineering Society (AES) standard known as AES70-2015, or just AES70.

AES70 is an open standard that may be used freely, without licenses, fees, or organization memberships.

Applicability

AES70 is intended to support media networks that combine devices from diverse manufacturers. Targeted for professional applications, AES70 is suitable for media networks of 2 to 10,000 devices, including networks with mission-critical and/or life-safety roles.

AES70 is for device control, monitoring, and connection management only. It does not provide transport of media program material. However, AES70 is designed to work with virtually any media transport scheme, as the application requires.

AES70's parts are separable and may be used independently. For example, a device may implement AES70 connection management, but use other means for operational control and monitoring.

AES70 is termed an "architecture" because it provides the basis for definition of multiple control protocols. These protocols all share a common programming model, but vary in signalling detail, depending on the form of the underlying data transport mechanism. An AES70 application will use whichever AES70 protocol is appropriate for the communications method available.

Background

OCA, the architecture of AES70, was developed by the OCA Alliance, trade association, beginning in 2011. OCA was based on an existing control protocol named OCP, which had been created by Bosch Communications Systems in 2009 and 2010. OCP was in turn based on an embryonic control protocol standard named AES-24 developed by the AES in the early 1990s.

From the outset, it was the intention of all involved to have OCA rendered into an open public standard. The Alliance completed OCA development in the Fall of 2014, and transferred the specification to the AES for rendering into a formal standard. AES70, the formal standard, was published on January 4, 2016.

Today, the OCA Alliance works to develop and enhance the functionality of AES70 and to promote AES70's adoption throughout the professional media systems industry. The Alliance promotes understanding and adoption of AES70, facilitates the creation of AES70 implementations and related tools and technologies, and develops future functional enhancements of the AES70 standard.

Structural Overview

Scope

AES70 defines the control interface that a media device presents to a network to which it is connected. Thus, AES70 is concerned with the representation of device functions in a systematic way, and with the control and monitoring of those functions via a well-defined family of protocols.

Media networks normally include one or more devices called "controllers" with user interfaces that allow humans to control and monitor the audio and/or video functioning of the networked devices. In AES70-compliant networks, controllers use AES70 protocols to communicate with the devices they control.

AES70 defines the control protocol used between controllers and devices; its scope does not extend to cover the design or construction of controllers or their user interfaces.

AES70 is intended to be used for professional applications. Technical requirements for such applications have been detailed elsewhere . OCA's scope excludes applications in homes, automobiles, and other consumer areas.

Device Model

The AES70 Device Model is the canonical description of the control interface that an AES70-compliant device presents to the network. The AES70 Device Model is object-oriented. It defines a required and an optional set of objects ("OCA objects") that the device's control interface implements. Using an AES70 protocol, controllers may access the properties of these objects to perform control, monitoring, and connection management operations.

OCA objects are abstractions that represent device control and monitoring points and media connections. They may or may not correspond to actual programming objects or hardware components inside the device. If a device correctly implements an AES70 protocol, it is AES70-compliant. AES70 does not define how that may or should be accomplished.

Generally speaking, the AES70 device model tends to differ from device models in other control architectures. in several ways:

1. AES70 does not presume a hierarchical device structure.
2. AES70 does not predefine specific processing configurations, signal processing modules, device types, or device families.
3. AES70 does not define controller user interfaces or user interface elements.
4. AES70 has strong support for dynamically reconfigurable devices.
5. AES70 offers a strong and transport-agnostic model for connection management.
6. AES70's repertoire of management and housekeeping functions is relatively rich.

Class Structure

The AES70 Class Structure defines a set of classes ("OCA Classes") that devices may use to instantiate OCA objects. There are three kinds of classes:

• Workers, which represent application functions of devices—gain controls, level meters, switches, equalizers, et cetera.
• Agents, which modify and assist control functions in various ways.
• Managers, which represent various global device states.

OCA classes may be broadly grouped into three functional sets:

• Management classes, which provide basic device management and housekeeping functions.
• Control and monitoring classes, which are concerned with device operation.
• Connection management classes, which are concerned with setup, supervision, and teardown of media stream connections, and with directory (aka "discovery") services for location and identification of network devices.

Protocols

As noted above, the AES70 architecture supports multiple protocols, depending on the nature of the network medium used. At present, AES70 defines one protocol, named OCP.1. OCP.1 is the AES70 protocol for TCP/IP networks. Future plans include OCP.2, a byte-serial version for USB networks, Bluetooth connections, and point-to-point links, and OCP.3, a text version in JSON.

Each AES70 protocol defines three kinds of messages, as follows:

• Commands - directives from a controller to an object in a device, requesting some kind of action or retrieving some parameter value;
• Responses - replies from an object to a controller, indicating success or failure of a previous command, and returning parameter values, where requested;
• Notifications - automatically generated messages from an object in a device to a controller, indicating the occurrence of some condition or periodically reporting a parameter value such as signal amplitude.

Control Repertoire

The AES70 control repertoire covers control, monitoring, and connection management of audio devices. Future versions will expand the audio control repertoire, and may address video devices as well.

AES70 includes features that allow manufacturers to extend the OCA class structure to address functions not in the standard repertoire. Such extensions may be public or confidential, as the manufacturer chooses.

Table 1 summarizes the AES70-2015 control repertoire.

Table 1. AES70-2015 Control Repertoire

Media Connection Management	Signal Processing
- Connection control	- Gain controls
- Directory/discovery functions	- Mutes
Additional Functions	- Switches (n-position)
- Control grouping (~VCA groups)	- Delays
- Crossfading	- Equalizers
- Snapshot & preset management	- Filters (IIR & FIR)
- Reconfigurable DSP device setup	- Limiters & compressors
- Reliable firmware updating	- Expanders & gates
Signal Monitoring	- Levelers
- Level sensors (meters)	- Matrices
- Frequency sensors	- Signal generators
- Time interval sensors	- Arbitrary numeric parameters
- Temperature sensors	- Arbitrary string parameters
- Arbitrary numeric parameters	+ Proprietary extensions as needed

Notable Features

Connection Management

Although AES70 does not itself provide media transport functions, it is designed to interface with modern media transport standards to control signal routing and other connection setup functions, and to interface with network directory/discovery services. In this capacity, AES70 provides a useful level of abstraction for applications, allowing controllers and devices to use one common software model for managing stream connections of various transport architectures.

The OCA Alliance defines recommended practices for interfacing AES70 with various well-known media transport architectures. The specification for interfacing AES70 with a given media transport scheme is called an AES70 Adaptation.

Control Grouping

AES70 includes an architectural solution to the problems of control grouping, i.e. the use of a single control input to effect multiple operating parameters. An example of control grouping is a master gain control covering multiple device channels in one or more devices.

Control grouping poses difficult problems, especially in systems where a given operating parameter may be affected by multiple control groups. For example, in a stereophonic multiway sound system, the gain of the left-channel high-frequency amplifier may be affected by settings of master controls for (a) overall high-frequency level, (b) left-channel level, and (c) overall level of the entire system. In such systems, machine intelligence is required to manage cumulative settings effects that lead to overrange or underrange parameter values. The AES70 grouping mechanism provides a basis for such management, for one or many devices.

Snapshot and Preset Management

AES70 includes a powerful and general mechanism for applying, storing, recalling, uploading, and downloading sets of operating parameter values. Both partial and full snapshots are supported.

Reconfigurable DSP Device Setup

AES70 includes complete support for managing the configurations of reconfigurable DSP devices, i.e. software-based devices whose signal processing topologies can be defined and redefined at runtime by external controllers. For such devices, AES70 supports creation, configuration, and deletion of signal processing elements and the internal signal paths that connect them.

Proprietary Extensibility

AES70 is designed to support proprietary extensions with maximum compatibility. Manufacturers may define their own extensions to the control repertoire, and these will coexist peacefully with standard elements.

Upward / Downward Compatibility

AES70 devices and controllers will continue to interoperate as AES70 evolves over the years. Devices that use various versions of OCA will generally be intermixable in one media network without problems.

Security

AES70 protocols offer encryption and authentication options that allow the construction of secure control and monitoring networks. Completely secure media networks will require encryption of transmitted program content as well; the mechanisms for such encryption lie outside the scope of OCAAES70 although AES70 may be used to configure and control them.

Reliable Firmware Update Capability

AES70 defines primitives that allow reliable update of device firmware over the network. These primitives may be used by maintenance software to ensure that incomplete firmware updates do not render critical devices and networks inoperative.

Availability

AES70 is an open and license-free standard. It may be freely used in products as manufacturers choose. Although AES70 is nurtured and promoted by the OCA Alliance, membership in the Alliance is not required in order to use AES70.

AES70 Documents

AES70 documents are available from the Audio Engineering Society (AES) Standards Store. The standard is in three parts and two significant appendices, as follows:

1. AES70 Framework

Also known as OCF, this specification describes the overall architecture of AES70 and describes its mechanisms. OCF is published in a document named AES-1-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 1: Framework.

2. AES70 Class Structure

Also known as OCC, this specification describes the object-oriented class structure that defines the functional repertoire (connection management, control, and monitoring) of AES70. OCC is published in a document named AES70-2-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 2: Class Structure

It is critical for readers also to download this document's Appendix A in either of two forms (see below for explanation):

AES70-2-2015 Appendix A (Enterprise Architect format)

or

AES70-2-2015 Appendix A (XMI format)

3. AES70 Protocols

Also known as OCP.1, OCP.2, etcetera, these specifications describe protocols that implement OCA control over various types of networks.

In AES70-2015, only one protocol -- OCP.1 -- is defined. It is for TCP/IP networks. Future updates to the standard will define additional protocols. OCP.1 is published in a document named AES70-3-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 3: Protocol for TCP/IP Networks

Readers should also download this document's Appendix B in either of two forms (see below for explanation):

AES70-3-2015 Appendix B (Enterprise Architect format)

or

AES70-23-2015 Appendix B (XMI format)

The Appendices

The two appendices listed above are Universal Modeling Language (UML) specifications.

The UML files are in two forms:

• The *.eap files are master files from a UML tool named Enterprise Architect from Sparx Systems. The usual version of the tool costs US$240, but Sparx Systems offers a free viewer.
• The *.xmi files are master files in XMI 2.1, a standard format for representation of UML information. XMI stands for "XML Metadata Interchange". XMI files can be opened by most UML editors, including free ones. See XML Metadata Interchange for more information.

The OCA Alliance

The OCA Alliance, is a non-profit corporation originally formed to secure the standardization of the OCA. With the publication of the AES70 standard in 2016, the Alliance's purposes have evolved, and are now:

• Promoting the adoption of AES70 through marketing, education and training.
• Developing documents and tools that complement the AES70 standard, by providing useful advice and materials to developers of AES70-compliant products and to end users of AES70 systems.
• Working with other standards groups to ensure the optimum blending of AES70 with other industry media networking standards, especially those related to media program transfer.
• Developing recommended enhancements to the AES70 standard.

Alliance members are large and small companies who desire to steer the evolution of AES70, and to benefit from the exchange of technology and business information that a trade association can provide. New members are always welcome.

Available development tools / code

A number of development tools / open source code is available which helps in start developing AES70 compatible products.

• A device implementation example in C++ can be downloaded from https://github.com/OCAAlliance/OCAMicro
• AES70 Explorer - Free development utility for AES70 Device Development, downloaded from https://aes70explorer.com/
• Free tools can be downloaded from https://ocaalliance.github.io/downloads.html
• A javascript controller library can be downloaded from https://github.com/DeutscheSoft/AES70.js
• A npm package with AES70.js is available at https://www.npmjs.com/package/aes70
• A Swift controller library and device implementation can be downloaded from https://github.com/PADL/SwiftOCA

External links

• http://ocaalliance.com/, the OCA Alliance website.
• http://www.aes.org/standards, the Audio Engineering Society standards page. AES standards participation is open to all; AES membership is not necessary.
• https://github.com/OCAAlliance/OCAMicro, a device implementation of the AES70 protocol. Supported by OCA Alliance members.