Open Control Alliance (OCA): Deja Vu or A View To The Future?
Late last year, I saw an article in Live Sound International, by Ethan Wetzell, a Bosch/Electro Voice engineer, called Wait - Why Are We Doing This? Progress On The System Interoperability Front. I had put this article aside, but as part of the process of creating a new edition of my book, Control Systems for Live Entertainment, I finally made time to read the article, and I’m glad I did. The article describes an interoperable audio system control protocol, in development by the “Open Control Alliance” (OCA), which formed in June, 2011. The article talks about, “interconnectivity,” “convergence,” and “interoperability”, and reading through, I had a feeling of deja vu, since this sounds exactly like the work done 20 years ago within the Audio Engineering Society (AES): on the AES-24 standard. Here’s an an excerpt from the second edition of my book, released in 2000:
When the first edition of this book [1994] was released, work was under way on a radically new sound communications network standard—Audio Engineering Society (AES) 24. This was a very ambitious project, since the group was attempting to design an object-oriented and network independent system from the ground up—not standardize or modify existing systems. After many years of on and off again work, AES-24-1-1999, part one of the proposed standard, was published in the April 1999 issue of the Journal of the Audio Engineering Society. While this part of the standard has been reviewed and issued, it is unlikely that the remaining (and key) pieces of the puzzle will ever be completed, and so, sadly, the standard is basically dead.
Two primary factors led to the failure of this standard effort. The first is that no clear market demand or commercial pressure ever developed for the creation of a unified audio control standard, so key manufacturers, many of whom had proprietary systems already on the market, supported the group’s efforts only in token, and not substantive, ways. The second factor is that with the growth and power of modern DSP technologies, audio systems are becoming increasingly centralized, with more power housed in less physical devices, so there are less devices and types of devices that need to be connected and controlled ...
So, while it is unfortunate that AES-24 failed, the effort was not wasted; the list of those involved reads like a “who’s who” of the industry, and those people have incorporated what they learned and developed into many products and systems on the market today.
The AES-24 standard was eventually officially withdrawn in 2004.
The Limitation of Standards
The unfortunate market failure of AES-24 became part of a change in my thinking, which I detailed in a “limitation of standards” section of the 3rd edition of my book, which I excerpted into this blog posting. My basic point was that, after personally watching a number of control standards developed by brilliant people fail in the market (MSC 1.1, Medianet, AES-24, ZIPI, etc), I came to think that these kind of wide-reaching standards would, unfortunately, rarely succeed, no matter how great the idea is in the first place. I condensed my thoughts on this into a list called “Common Attributes Of Successful Standards”:
Successful standards are pulled into existence by the market; they are not pushed. They fill a clear commercial demand in the market, especially one driven by users. Often, this means that multiple, non-interoperable systems already exist in a market segment and users are screaming for interoperability.
They are limited in scope and ambition and optimized for some task. Consensus standards making processes ensure this, since only a minimal level of functionality will be agreed upon by all the parties involved.
They are open for all to use. All of the standards (of which I'm aware) that have caused our market to grow have been open.
They leave clear room for expansion and allow shortcomings to be corrected.
How does OCA Differ From AES-24?
Reading about the standard, I found that my old friend, the brilliant Jeff Berryman, was deeply involved in this new effort; Jeff was also a driving force behind the development of AES-24. I’d lost track of Jeff somewhere along the way, but found that he’s working at Bosch as a Senior Scientist, so I called him to get some background on this new effort, and how he feels the market differs from the mid 1990’s. “OCA is actually derived from AES-24”, Jeff says. It uses AES-24’s object oriented structure, and the basic aspects of its device model. “What’s been added to OCA”, he explains “are the concept of protocol agility (not just TCP), and a whole set of functions including group control, preset libraries, any many other features.”
As for the market today, Jeff says, “OCA's proponents do sense a market demand for integrated control. That demand is largely riding in on the heels of the hopes created by all the hoopla over AVB [editor’s note: you can read my AVB writeup from Infocomm 2009 here], which promises interoperable media transport. OCA simply aims to serve the other half (control) of the systems challenge. The sense of the group is that expectations have risen a lot since the AES-24 days, due mainly to the greatly improved interoperability in the computer data realm.” Standards often take a long time to develop, and Jeff feels that this was part of the reason for the failure of AES-24. But he feels that OCA is different: “A lot of the architecture has already been developed by AES-24, and at the outset of the OCA Alliance, Bosch contributed a substantially complete "version 0.5" to the effort.” In addition, OCA is not working within the aegis of a traditional standards-making body (although they will submit it to one eventually), and there are only nine companies involved: Bosch Communications Systems, d&b audiotechnik, Duran Audio, LOUD Technologies Inc, Media Technology Systems, PreSonus, Salzbrenner Stagetec Mediagroup, TC Group, and Yamaha Commercial Audio. “Everyone has committed to a fast-track schedule”, Jeff says, “and is sticking to it.”
So, how is OCA different from Open Sound Control (OSC) which also was developed under an informal structure and never sanctioned by ANSI or any other similar body? “OCA is targeted at a different set of 'usecases' from OSC”, Jeff explains, and he pointed me to a paper he gave to the AES networking conference last year. “It covers a wide range”, he continues, “from the small ones that OSC could probably serve, to the large and/or mission-critical ones that OSC could not serve. To the best of the Alliance's knowledge, OCA is the only public control protocol that aspires to serve this entire range of usecases--our sense of OSC is that it is designed to support relatively small systems that are operating in benign environments and that do not have mission-critical roles, particularly life-safety roles.”
What about PLASA’s Architecture for Control Networks (ACN) (info including some articles I wrote about ACN here)? I knew Jeff was aware of this standard, because, way back in 1999, when ACN was a few years into its development, I brought him to the ESTA (now PLASA) Control Protocol Working Group meeting at USITT in Toronto to talk about the issues of AES-24 development. He laid out the travails of the AES-24 process, and I remember distinctly the then ACN task group chairman saying, “well it will never take us that long” (it took them seven more years to get it done). “Before embarking on OCA, Bosch looked at ACN”, Jeff explains. “We found it a bit fragmented but not functionally rich. It's been a while since we did the investigation, but as I remember, ACN uses fairly weakly typed control variables, does not have a particularly rich device model, and does not define robust interoperability mechanisms for evolution and lateral compatibility. Also, I don't remember seeing concurrency control mechanisms, although I might not remember them. Unless someone did major profile work, I do not think ACN devices would come to be as interoperable as OCA devices over time.”
OK, with my grilling of my friend done, what exactly is proposed in OCA?
What Is Proposed?
Right now the development details aren’t fully public, but you can view the current documents if you're an “Observer” member (I applied here the other day and they approved me within 24 hours). OCA will run on a variety of transport and infrastructures, although the current focus is on Ethernet and IP, and it's being designed to work well with various streaming solutions like Dante (which Bosch is using), AVB, RTP, and others like Cobranet. I got permission from Jeff to publish these OCA design features/goals:
Scalability. 2 to 10,000 nodes, localized or wide-area.
Reliability. Loss-free exchange of control and monitoring information, and prompt detection of malfunctions.
Growth Potential. Expandable definition to support emergent products while still maintaining legacy compatibility.
Multivendor Flexibility. Rich support for proprietary extensions that do not compromise core functions.
Versatility. OCA supports media devices at all levels of complexity, with all kinds of functions. Reconfigurable processors are fully supported.
Security. The OCA security option offers controller authentication and full encryption of control and monitoring traffic. This option uses standard algorithms that are available worldwide.
Reliable Remote Firmware Update. OCA supports an option for accurate firmware updating over the network from a central point.
Full Discovery Features. OCA allows controllers to discover what OCA-compliant devices are on the network and what elements are inside each one. Controllers are notified when devices enter and leave the network.
Platform Independence. OCA relies on no manufacturer-specific protocols, platforms, or programming environments. System requirements are minimal.
Efficiency. Although OCA is not a minimalist architecture, it uses network bandwidth and node processing power conservatively.
Jeff emphasized that OCA is an “architecture, not a protocol”, and is currently made up of three main parts:
Framework (OCF): Device model, Functional mechanisms
Class Tree (OCC) Object-oriented definition of control & monitoring functional repertoire.
Protocol Implementations (OCP.1 ... OCP.n) OCA will be a family of protocols for different contexts; OCP.1 : for TCP/IP networks, OCP.2-n : TBD, may include USB, XML, ...
Mr. Wetzell's article said that OCA “interact[s] with parameters and functions, but [does] not define... the functions themselves”. But talking to Jeff, I found that OCA does defines specific control elements such as level, EQ compression, etc, but allows manufacturers to extend this to include proprietary control approaches and features. That makes OCA very different from OSC or ACN (not sACN), which only supply device description frameworks and methods to control them.
If You Build It, Will They Come?
In the short term, at least, in the sound market I know best--live sound--end users aren’t screaming for a universal audio control technology, and haven’t been since the days of AES-24, when we had racks and racks of individual analog processors from different manufacturers. For example, most of the sound systems I build (and I build both big and small) are these days made up of only a couple pieces of DSP: a digital console, and a matrix/DSP processor for loudspeaker signal distribution and management (see photo). Digital consoles today do all the processing that is needed for many, many shows (some engineers may insert a compressor or a couple outboard devices for a particular effect they like, but nothing like the old days), and modern consoles have a perfectly good physical control interfaces that don’t need a lot of remote control (and those that do want remote control are typically using proprietary solutions). As a system engineer, I often need to walk the venue with my laptop and make adjustments. I used to have to talk to a rack of DSP processors, often from different manufacturers, today I typically talk only to one box, which comes with really good remote control software that I can run from my laptop anywhere in the venue over wifi and IP. Keeping these interfaces (mixer and loudspeaker processor) separate not only means that each interface can be optimized (the console for mixing, the matrix/DSP for aligning the sound system), but also they can be used completely independently and simultaneously: I can work on the levels of the speakers in the back while the mix engineer is working on snare drum EQ at sound check. Of course, this could be integrated, but that really wouldn’t allow me to anything tomorrow that I can’t already do today.
But what wasn’t clear to me before my conversation with Jeff was that Bosch (which includes the audio brands DYNACORD, Electro-Voice, RTS, and Telex) does have a clear market need for this stuff right now, in large systems for facilities like the UN, large airports, and installed PA systems; OMNEO is Bosch’s approach for these markets, and is basically a combination of OCA and Dante. These kinds of systems have security and life safety issues that we don’t (yet, anyway) face in live sound, and wider adoption of the standard is of course in their interest. (Bosch has always been a fascinating organization that works differently--it’s controlled by a charitable foundation with much of its profit going to charity). With Bosch’s size and reach, and the other players involved, OCA looks to find applications in large, permanently installed systems, and that may trickle down to us in live sound in the future.
Jeff thinks the bulk of the protocol should be complete by the end of April; I’m including a section on it in the new edition of my book; and time will tell how it all plays out!