Somehow, months ago, I got it in my head that a unified control & monitoring standard for operating devices on an audio over IP network would be simply a framework for “Start,” “Record” and “Stop.” Maybe “Rewind” would be in the command set too. And it would look and feel like a remote control for an Ampex 300 reel-to-reel recorder.
Well! A copy of the new AES70 standard for audio applications of networks-Open Control Architecture came across my desk recently, and it’s a heady three-part document that describes a thoroughly modern yet familiar architecture that could be applied to control and monitor, yes, Ampex recorders, I suppose, but a broad range of existing and future devices we don’t usually consider: outboard equalizers, delay units, amplifier output channels, in-console processing devices and other AES70-aware physical and virtual devices for broadcast and stage.
The three parts of the standard guide the reader through an overview of the models and mechanisms (Part 1), then delve into the control class structure that define the capabilities (Part 2), then finishes crisply in Part 3 with the technical specifications that define the protocol for TCP/IP networks — this is the dense, bit-by-bit section I like to peruse, but I’m glad there’s no quiz on the material after the reading.
AES70 doesn’t care about or interfere with the streaming media or media content within the data network; the standard is about device control and monitoring only.
As a high-level overview, the AES70 describes eight architectural goals and constraints; the first is support of the following functions:
1. Discover the AES70 devices that are connected to the network.
2. Define and un-define media stream paths between devices.
3. Control operating and configuration parameters of an AES70 device.
4. Monitor operating and configuration parameters of an AES70 device.
5. For devices with reconfigurable signal processing and/or control capabilities, define and manage configuration parameters.
6. Upgrade software and firmware of controlled devices. Include features for fail-safe upgrades.
Second, the standard supports the following security measures:
1. Entity authentication
2. Prevention of eavesdropping
3. Integrity protection
4. Freshness — “Freshness” in this context means certainty that replayed messages in a replay attack on a protocol will be detected as such.
Third, the standard says it is scalable up to “at least” 10,000 of your devices that need controlling and monitoring.
The remaining five architectural goals are particularly interesting:
• High availability by supervising the devices and the networks and efficiently re-initializing following errors or configuration changes;
• Supports “robustness” by handling control data loss, device failure and using a mechanism to confirm intended operation.
• Has a safety compliance that allows implementation of media networks that conform to life-safety emergency standards. To me, this is a significant goal. From AES70-compliant medical equipment that can be controlled and monitored from a distance, to secure and hack-resistant alert triggering.
• AES70 recognizes that as the standard evolves, backward compatibility and a predictable method of operation between devices with different versions are required.
• Finally, the standard recognizes that debugging the devices, their network interfaces, the network itself and the media stream parameters are essential.
Fig. 1 illustrates the AES70 device model. The boxed elements are objects.
Courtesy Audio Engineering Society Digging deeper into the standard, a feeling of familiarity bubbles up; a banquet of Object Oriented Programming phrases appear and discuss classes, properties, methods, inheritance, subclassing, trees, hierarchy and introduce the three main objects: Managers, Workers and Agents. These three software objects, shown in Fig. 1, perform the activities that fulfill the eight architectural goals.
An interesting concept, Matrix, is introduced and it “shall be a generalization of the familiar audio cross point matrix concept. AES70 matrices are rectangular arrays of identical Workers that share one or more common input and output busses for the rows and columns, respectively.”
The concept seems unnaturally abstract at first, but the standard goes on to describe how matrices are not limited to the representing traditional audio matrix routing, but may be useful for addressing collections of objects.
“For example, a loudspeaker crossover might be represented as a matrix of crossover channels, with each channel being a block containing the usual filters, gain elements, delays and dynamics controls. In this case, the channels might share a common input which could be represented by a matrix row port. However, they would use separate output ports, so no matrix output ports would be required.” Now that makes sense.
While the AES70 details may be exciting to those who will be developing AES70-capable devices and controllers, the extreme takeaway for me was the prospect of plugging an Ethernet cable into an AES70 aware device in Athens, Ohio, and automagically controlling it from an AES70-aware control position in, say, Athens, Ga., and monitoring the transaction by an AES70-aware console in Athens, Pa.
Comment to me at[email protected]. Also check out Radio World’s new ebook “Radio AoIP 2016” with comments from industry thought leaders about the state of AoIP today at http://tinyurl.com/rw-aoip.
