Open Control Architecture

The Open Control Architecture (OCA) is a communications protocol architecture for control and monitoring of networked audio and video devices. Such networks are referred to as "media networks".

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

OCA is for device control and monitoring only. It does not provide transport of media program material. However, OCA is designed to work with various media transport schemes, as the application requires.

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

Background

OCA was developed by the OCA Alliance, beginning in 2011. It was based on a control protocol named OCP, which was created by Bosch Communications Systems in 2009 and 2010. OCP was in turn based on an embryonic control protocol standard named AES-24 ^{[1] [2]} developed by the Audio Engineering Society in the 1990s.

The OCA Alliance is a trade association whose mission is to develop and enhance the definition of OCA, and to promote OCA's adoption throughout the professional media systems industry.

Status

The OCA specification currently stands at revision 1.1. The complete specification is downloadable from the OCA Alliance website.^[3]

OCA 1.1 is a proposed standard. It is now being rendered into a formal standard by the Audio Engineering Society (AES). The standardization of OCA 1.1 is designated as AES Standards Project X210. When the first phase of X210's work is complete, OCA 1.1 will be published as an AES standard.

In parallel with standardization of OCA, the OCA Alliance will work to promote understanding and adoption of OCA, to facilitate the creation of OCA implementations and related tools, and to develop future functional enhancements of the standard.

Structural Overview

Scope

OCA's purpose is to define the control and monitoring interface that a media device presents to a network to which it is connected. Thus, OCA 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" that have user interfaces which allow humans to control and monitor the audio and/or video functioning of the networked devices. In OCA-compliant networks, controllers will use OCA protocols to communicate with the devices they control. However, OCA's scope does not extend to cover the elements or design of controllers or their user interfaces.

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

Device Model

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

OCA objects are abstractions that represent device control and monitoring points. They may or may not correspond to actual programming objects or hardware components inside the device. If a device correctly implements an OCA protocol, it is OCA-compliant. How that is accomplished is not OCA's business.

Generally speaking, the OCA device model tends to differ from device models in other control architectures ^{[7] [8] [9] [10] [11] [12] [13] [14]} in several ways:

1. OCA does not presume a hierarchical device structure.
2. OCA does not predefine specific processing configura-tions, signal processing modules, device types, or device families.
3. OCA does not define controller user interfaces or user interface elements.
4. OCA has strong support for dynamically reconfigurable devices.
5. By comparison, OCA's repertoire of management functions is relatively rich.

Class Structure

The OCA Class Structure defines a set of 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.

Protocols

As noted above, OCA is an architecture that supports multiple protocols, depending on the nature of the network medium used. The OCA 1.1 specification defines one protocol, named OCP.1. OCP.1 is the OCA protocol for TCP/IP networks. Future plans include OCP.2, a byte-serial version for USB networks and point-to-point links, and OCP.3, a text version in JSON. Each OCA 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.

Features

OCA 1.1 covers control and monitoring of audio devices. Future versions will expand the audio control repertoire, and may address video devices as well.

OCA includes features that allow manufacturers to extend OCA protocols to address functions not in the standard repertoire. Such extensions may or may not be proprietary.

Control Repertoire

The OCA 1.1 control repertoire includes:

Signal Handling	Signal Sensing
- Gain controls	- Level sensors (meters)
- Mutes	- Frequency sensors
- Switches (n-position)	- Time interval sensors
- Delays	- Temperature sensors
- Equalizers	- Arbitrary numeric parameter sensors
- Filters (IIR & FIR)	Control Processing
- Limiters & Compressors	- Composite functional blocks
- Expanders & Gates	- Matrices of arbitrary elements
- Levelers	- Control grouping (like VCA groups)
- Signal generators	- Timed crossfading
- Arbitrary numeric parameters	- Prestored settings (presets, patches, scenes)

Dynamically Reconfigurable Devices

OCA includes complete support for dynamically reconfigurable devices, i.e. software-based devices whose signal processing topologies can be defined and redefined at runtime by external controllers.

Media Transport Control

Although OCA does not itself provide media transport functions, it is capable of interfacing with various media transport standards to control signal routing and perform other connection management functions. The OCA Alliance defines recommended practices for interfacing OCA with various well-known media transport architectures. The specification for interfacing OCA with a given media transport scheme is called an OCA "adaptation".

Proprietary Extendability

OCA 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

OCA devices and controllers will continue to interoperate as OCA evolved over the years. Devices that use various versions of OCA can generally be combined in one media network without problems. Security. OCA 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 OCA, although OCA could be used to configure and control them.

Reliable Firmware Update Capability

OCA defines primitives that allow reliable update of device firmware over the network.

References

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.