How AES70 and OCA Work
AES70 offers a refreshing approach to control.
When people start to think about controlling devices, they traditionally envision the control signals that are actually travelling along the cable from one device to another. Engineers like to start with knowing what the packets of information look like. To understand AES70, you need to start the other way around, and when you do, it all makes a lot more sense.
The first thing to do is to look at the control model. A control model defines what a device can publish to the network to expose remotely controllable functions.
The OCA control model defines what are known as control classes. A control class is a template for controlling a particular device function. There are control classes for gain controls, equalizers, switches, level meters, and many other devices. AES70’s current control model defines a kit of over 100 control classes from which device developers can choose. Additionally, developers may create their own classes.
An object is a representation of a part the device’s network control implementation. If a device has four gain controls that a developer wishes to be controlled remotely, it will have four gain control objects, each one constructed from the same gain control class.
A device’s collection of objects defines the control interface that is exposed on the network. Once the control interface is known, a controller can control and monitor all of the device’s exposed parameters. Manufacturers have the flexibility to choose which parameters of a device are exposed.
A device’s particular set of control objects is called its schema. When a device connects to a network, controllers are able to retrieve the device’s schema.
The objects which a schema defines are constructed from AES70 classes.
The OCA Alliance provides an Excel spreadsheet template for documenting AES70 schemas in a standard way. The resulting spreadsheets are called AES70 Implementation Charts, because they resemble traditional MIDI Implementation Charts. The Alliance provides a free software tool to help fill in the charts automatically.
In a schema, each object has a class ID. The class ID specifies the class from which the object is constructed, which in turn specifies what that object does — a gain control, an equalizer etc. Each has a different class ID.
Each object has a unique Object Number that distinguishes it from all other objects in the device. When a schema includes multiple objects of the same class (e.g. multiple parametric equalizers), all those objects will have the same Class ID, but each one will have a unique Object Number. No two objects in a device will ever have the same Object Number.
A class defines one or more properties. A property is a parameter of the class- for example, a typical parametric equalizer has three: frequency, gain, and Q or bandwidth.
Every object created from a class will have all of the classes properties.
To control a device, controllers need a network protocol to access the objects in the device’s schema. AES70 defines such a protocol – it’s called OCP.1. OCP.1 specifies how controllers can send commands to a device’s objects, and receive the results of those commands. It also defines a way for devices to notify controllers of changes in operating state, signal level, and other parameters.
OCP.1 is designed to operate over TCP/IP networks. In the future, AES70 may provide other protocol options, but the underlying classes, objects, and schemas will be the same for all.
Device Internals
AES70 doesn’t describe what is inside a device or how the device actually functions or is built. It also doesn’t describe internal algorithms – how something works. For example, the control settings of a parametric equalizer object may indicate -6dB, 400Hz, Q=2.5, but AES70 doesn’t define the actual curve you get.
User Interface
AES70 doesn’t define what happens at the controller end: it doesn’t describe the user interface – whether a control should look like a knob, a fader or something else.
High level system functions
Also, AES70 doesn’t define higher level application elements such as studio workflows, multipurpose venue configurations, system emergency modes, or maintenance procedures.