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 round, 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.
Over 100 classes available:
Any control class can be used any number of times for a device. Each separate use of a class is called an object. So if a device has four gain controls, it will have four gain control objects.
A device’s particular set of control objects is called its schema. When a device connects to a network, its schema becomes available. The schema shows what controllers to use in controlling and monitoring the device. If a device were a website, its objects would be individual web pages, and its schema would be the site map.
An AES70 schema defines objects that are constructed from control class definitions.
The OCA Alliance provides an Excel spreadsheet template for documenting OCA 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 the 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 have different class IDs.
Each use of an 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.
An object may have many parameters - for example, a typical parametric equalizer has three: frequency, gain and width.
Sometimes programmers use the term control API (API = "Application Program Interface" or "Application Protocol Interface") when speaking about network control. In the OCA context, a device's control API is the set of OCP.1 commands and responses that can be used to access its shema.
The way AES70 works, defining a device's schema automatically defines its control API - no further design work is needed. The device's control API is completely defined by the set of objects in its schema. Click on the image to view the file.
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.
It’s worth highlighting what AES70 does not cover:
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.
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.
Also, AES70 doesn’t define higher level application elements such as studio workflows, multipurpose venue configurations, system emergency modes, or maintenance procedures.