User:Teenbean65/sandbox

Open Control Architecture (OCA)
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 inteded 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. Although OCA is architecturally suitable for control of home media networks, the hom media networking requirement has already been addressed by other schemes, primarily the Digital Living Network Alliance (DLNA) protocol suite, which is based on the UPnP architecture first developed by Microsoft in the 1990's. 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" developed by the Audio Engineering Society in the early 1990's. 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 [ref]. OCA 1.1 is a proposed standard. The task of transforming OCA 1.1 into a formal standard has been undertaken by the Audio Engineering Society (AES), a fully commissioned standardsmaking body. The standardization of OCA 1.1 is designated as AES project X210. When the first phase of X210's work is complete, OCA 1.1 will be published as an AES 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, the OCA specification does not extend to cover the elements or design of controllers or their user interfaces. Control user intefaces are outside of OCA's scope. 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 [def], and defines a required and an optional set of objects ("OCA objects") that a device's control interface implements. Using an OCA protocol [ref], 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. 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 [ref].

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 may address video devices as well. Control Repertoire. OCA 1.1 offers a relatively complete audio control repertoire that includes: Signal Handling •	Gain controls •	Mutes •	Switches (n-position) •	Delays •	Equalizers •	Filters (IIR & FIR) •	Limiters & Compressors •	Expanders & Gates •	Levelers •	Matrices •	Signal generators •	Arbitrary numeric parameters	Signal sensing •	Level sensors (meters) •	Frequency sensors •	Time interval sensors •	Temperature sensors

Control Processing
•	Composite functional blocks •	Matrices of arbitrary elements •	Control grouping (~VCA groups) •	Crossfading •	Prestored settings (aka "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.