The Open Control Architecture (OCA) is a communications protocol architecture for control, monitoring, and connection management of networked audio and video devices. Such networks are referred to as "media networks".
The official specification of OCA is the Audio Engineering Society (AES) standard known as AES70-2015, or just AES70.
AES70 is an open standard that may be used freely, without licenses, fees, or organization memberships.
AES70 is intended to support media networks that combine devices from diverse manufacturers. Targeted for professional applications, AES70 is suitable for media networks of 2 to 10,000 devices, including networks with mission-critical and/or life-safety roles.
AES70 is for device control, monitoring, and connection management only. It does not provide transport of media program material. However, AES70 is designed to work with virtually any media transport scheme, as the application requires.
AES70's parts are separable and may be used independently. For example, a device may implement AES70 connection management, but use other means for operational control and monitoring.
AES70 is termed an "architecture" because it provides the basis for definition of multiple control protocols. These protocols all share a common programming model, but vary in signalling detail, depending on the form of the underlying data transport mechanism. An AES70 application will use whichever AES70 protocol is appropriate for the communications method available.
OCA, the architecture of AES70, was developed by the OCA Alliance, [1] trade association, beginning in 2011. OCA was based on an existing control protocol named OCP, which had been created by Bosch Communications Systems in 2009 and 2010. OCP was in turn based on an embryonic control protocol standard named AES-24 [2] [3] developed by the AES in the early 1990s.
From the outset, it was the intention of all involved to have OCA rendered into an open public standard. The Alliance completed OCA development in the Fall of 2014, and transferred the specification to the AES for rendering into a formal standard. AES70, the formal standard, was published on January 4, 2016.
Today, the OCA Alliance works to develop and enhance the functionality of AES70 and to promote AES70's adoption throughout the professional media systems industry. The Alliance promotes understanding and adoption of AES70, facilitates the creation of AES70 implementations and related tools and technologies, and develops future functional enhancements of the AES70 standard.
AES70 defines the control interface that a media device presents to a network to which it is connected. Thus, AES70 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" with user interfaces that allow humans to control and monitor the audio and/or video functioning of the networked devices. In AES70-compliant networks, controllers use AES70 protocols to communicate with the devices they control.
AES70 defines the control protocol used between controllers and devices; its scope does not extend to cover the design or construction of controllers or their user interfaces.
AES70 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.
The AES70 Device Model is the canonical description of the control interface that an AES70-compliant device presents to the network. The AES70 Device Model is object-oriented. It defines a required and an optional set of objects ("OCA objects") that the device's control interface implements. Using an AES70 protocol, controllers may access the properties of these objects to perform control, monitoring, and connection management operations.
OCA objects are abstractions that represent device control and monitoring points and media connections. They may or may not correspond to actual programming objects or hardware components inside the device. If a device correctly implements an AES70 protocol, it is AES70-compliant. AES70 does not define how that may or should be accomplished.
Generally speaking, the AES70 device model tends to differ from device models in other control architectures. [5] [6] in several ways:
The AES70 Class Structure defines a set of classes ("OCA Classes") that devices may use to instantiate OCA objects. There are three kinds of classes:
OCA classes may be broadly grouped into three functional sets:
As noted above, the AES70 architecture supports multiple protocols, depending on the nature of the network medium used. At present, AES70 defines one protocol, named OCP.1. OCP.1 is the AES70 protocol for TCP/IP networks. Future plans include OCP.2, a byte-serial version for USB networks, Bluetooth connections, and point-to-point links, and OCP.3, a text version in JSON.
Each AES70 protocol defines three kinds of messages, as follows:
The AES70 control repertoire covers control, monitoring, and connection management of audio devices. Future versions will expand the audio control repertoire, and may address video devices as well.
AES70 includes features that allow manufacturers to extend the OCA class structure to address functions not in the standard repertoire. Such extensions may be public or confidential, as the manufacturer chooses.
Table 1 summarizes the AES70-2015 control repertoire.
Media Connection Management | Signal Processing |
- Connection control | - Gain controls |
- Directory/discovery functions | - Mutes |
Additional Functions | - Switches (n-position) |
- Control grouping (~VCA groups) | - Delays |
- Crossfading | - Equalizers |
- Snapshot & preset management | - Filters (IIR & FIR) |
- Reconfigurable DSP device setup | - Limiters & compressors |
- Reliable firmware updating | - Expanders & gates |
Signal Monitoring | - Levelers |
- Level sensors (meters) | - Matrices |
- Frequency sensors | - Signal generators |
- Time interval sensors | - Arbitrary numeric parameters |
- Temperature sensors | - Arbitrary string parameters |
- Arbitrary numeric parameters | + Proprietary extensions as needed |
Although AES70 does not itself provide media transport functions, it is designed to interface with modern media transport standards to control signal routing and other connection setup functions, and to interface with network directory/discovery services. In this capacity, AES70 provides a useful level of abstraction for applications, allowing controllers and devices to use one common software model for managing stream connections of various transport architectures.
The OCA Alliance defines recommended practices for interfacing AES70 with various well-known media transport architectures. The specification for interfacing AES70 with a given media transport scheme is called an AES70 Adaptation.
AES70 includes an architectural solution to the problems of control grouping, i.e. the use of a single control input to effect multiple operating parameters. An example of control grouping is a master gain control covering multiple device channels in one or more devices.
Control grouping poses difficult problems, especially in systems where a given operating parameter may be affected by multiple control groups. For example, in a stereophonic multiway sound system, the gain of the left-channel high-frequency amplifier may be affected by settings of master controls for (a) overall high-frequency level, (b) left-channel level, and (c) overall level of the entire system. In such systems, machine intelligence is required to manage cumulative settings effects that lead to overrange or underrange parameter values. The AES70 grouping mechanism provides a basis for such management, for one or many devices.
AES70 includes a powerful and general mechanism for applying, storing, recalling, uploading, and downloading sets of operating parameter values. Both partial and full snapshots are supported.
AES70 includes complete support for managing the configurations of reconfigurable DSP devices, i.e. software-based devices whose signal processing topologies can be defined and redefined at runtime by external controllers. For such devices, AES70 supports creation, configuration, and deletion of signal processing elements and the internal signal paths that connect them.
AES70 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.
AES70 devices and controllers will continue to interoperate as AES70 evolves over the years. Devices that use various versions of OCA will generally be intermixable in one media network without problems.
AES70 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 OCAAES70 although AES70 may be used to configure and control them.
AES70 defines primitives that allow reliable update of device firmware over the network. These primitives may be used by maintenance software to ensure that incomplete firmware updates do not render critical devices and networks inoperative.
AES70 is an open and license-free standard. It may be freely used in products as manufacturers choose. Although AES70 is nurtured and promoted by the OCA Alliance, membership in the Alliance is not required in order to use AES70.
AES70 documents are available from the Audio Engineering Society (AES) Standards Store. The standard is in three parts and two significant appendices, as follows:
1. AES70 Framework
2. AES70 Class Structure
3. AES70 Protocols
The two appendices listed above are Universal Modeling Language (UML) specifications.
The UML files are in two forms:
The OCA Alliance, [14] is a non-profit corporation originally formed to secure the standardization of the OCA. With the publication of the AES70 standard in 2016, the Alliance's purposes have evolved, and are now:
Alliance members are large and small companies who desire to steer the evolution of AES70, and to benefit from the exchange of technology and business information that a trade association can provide. New members are always welcome.
A number of development tools / open source code is available which helps in start developing AES70 compatible products.
Bluetooth is a short-range wireless technology standard that is used for exchanging data between fixed and mobile devices over short distances and building personal area networks (PANs). In the most widely used mode, transmission power is limited to 2.5 milliwatts, giving it a very short range of up to 10 metres (33 ft). It employs UHF radio waves in the ISM bands, from 2.402 GHz to 2.48 GHz. It is mainly used as an alternative to wired connections to exchange files between nearby portable devices and connect cell phones and music players with wireless headphones.
The Open Systems Interconnection (OSI) model is a reference model from the International Organization for Standardization (ISO) that "provides a common basis for the coordination of standards development for the purpose of systems interconnection." In the OSI reference model, the communications between systems are split into seven different abstraction layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).
Universal Plug and Play (UPnP) is a set of networking protocols on the Internet Protocol (IP) that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices.
KNX is an open standard for commercial and residential building automation. KNX devices can manage lighting, blinds and shutters, HVAC, security systems, energy management, audio video, domestic appliances, displays, remote control, etc. KNX evolved from three earlier standards; the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus.
Zigbee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios, such as for home automation, medical device data collection, and other low-power low-bandwidth needs, designed for small scale projects which need wireless connection. Hence, Zigbee is a low-power, low-data-rate, and close proximity wireless ad hoc network.
Electronic test equipment is used to create signals and capture responses from electronic devices under test (DUTs). In this way, the proper operation of the DUT can be proven or faults in the device can be traced. Use of electronic test equipment is essential to any serious work on electronics systems.
The Gateway Control Protocol is an implementation of the media gateway control protocol architecture for providing telecommunication services across a converged internetwork consisting of the traditional public switched telephone network (PSTN) and modern packet networks, such as the Internet. H.248 is the designation of the recommendations developed by the ITU Telecommunication Standardization Sector (ITU-T) and Megaco is a contraction of media gateway control protocol used by the earliest specifications by the Internet Engineering Task Force (IETF). The standard published in March 2013 by ITU-T is entitled H.248.1: Gateway control protocol: Version 3.
The Arm Advanced Microcontroller Bus Architecture (AMBA) is an open-standard, on-chip interconnect specification for the connection and management of functional blocks in system-on-a-chip (SoC) designs. It facilitates development of multi-processor designs with large numbers of controllers and components with a bus architecture. Since its inception, the scope of AMBA has, despite its name, gone far beyond microcontroller devices. Today, AMBA is widely used on a range of ASIC and SoC parts including applications processors used in modern portable mobile devices like smartphones. AMBA is a registered trademark of Arm Ltd.
IEC 61850 is an international standard defining communication protocols for intelligent electronic devices at electrical substations. It is a part of the International Electrotechnical Commission's (IEC) Technical Committee 57 reference architecture for electric power systems. The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Current mappings in the standard are to Manufacturing Message Specification (MMS), GOOSE [see section 3, Terms and definitions, term 3.65 on page 14], SV or SMV, and soon to web services. In the previous version of the standard, GOOSE stood for "Generic Object Oriented Substation Event", but this old definition is still very common in IEC 61850 documentation. These protocols can run over TCP/IP networks or substation LANs using high speed switched Ethernet to obtain the necessary response times below four milliseconds for protective relaying.
Profinet is an industry technical standard for data communication over Industrial Ethernet, designed for collecting data from, and controlling equipment in industrial systems, with a particular strength in delivering data under tight time constraints. The standard is maintained and supported by Profibus and Profinet International, an umbrella organization headquartered in Karlsruhe, Germany.
The Media Gateway Control Protocol (MGCP) is a telecommunication protocol for signaling and call control in hybrid voice over IP (VoIP) and traditional telecommunication systems. It implements the media gateway control protocol architecture for controlling media gateways connected to the public switched telephone network (PSTN). The media gateways provide conversion of traditional electronic media to the Internet Protocol (IP) network. The protocol is a successor to the Simple Gateway Control Protocol (SGCP), which was developed by Bellcore and Cisco, and the Internet Protocol Device Control (IPDC).
ORiN is a standard network interface for FA systems. The Japan Robot Association proposed ORiN in 2002, and the ORiN Forum develops and maintains the ORiN standard.
MOST is a high-speed multimedia network technology for the automotive industry. It can be used for applications inside or outside the car. The serial MOST bus uses a daisy-chain topology or ring topology and synchronous serial communication to transport audio, video, voice and data signals via plastic optical fiber (POF) or electrical conductor physical layers.
The media gateway control protocol architecture is a methodology of providing telecommunication services using decomposed multimedia gateways for transmitting telephone calls between an Internet Protocol network and traditional analog facilities of the public switched telephone network (PSTN). The architecture was originally defined in RFC 2805 and has been used in several prominent voice over IP (VoIP) protocol implementations, such as the Media Gateway Control Protocol (MGCP) and Megaco (H.248), both successors to the obsolete Simple Gateway Control Protocol (SGCP).
RTP-MIDI is a protocol to transport MIDI messages within Real-time Transport Protocol (RTP) packets over Ethernet and WiFi networks. It is completely open and free, and is compatible both with LAN and WAN application fields. Compared to MIDI 1.0, RTP-MIDI includes new features like session management, device synchronization and detection of lost packets, with automatic regeneration of lost data. RTP-MIDI is compatible with real-time applications, and supports sample-accurate synchronization for each MIDI message.
AES67 is a technical standard for audio over IP and audio over Ethernet (AoE) interoperability. The standard was developed by the Audio Engineering Society and first published in September 2013. It is a layer 3 protocol suite based on existing standards and is designed to allow interoperability between various IP-based audio networking systems such as RAVENNA, Wheatnet, Livewire, Q-LAN and Dante.
Audio Video Bridging (AVB) is a common name for a set of technical standards that provide improved synchronization, low latency, and reliability for switched Ethernet networks. AVB embodies the following technologies and standards: