Open Control Architecture

Last updated

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".

Contents

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.

Applicability

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.

Background

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.

Structural Overview

Scope

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.

Device Model

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:

  1. AES70 does not presume a hierarchical device structure.
  2. AES70 does not predefine specific processing configurations, signal processing modules, device types, or device families.
  3. AES70 does not define controller user interfaces or user interface elements.
  4. AES70 has strong support for dynamically reconfigurable devices.
  5. AES70 offers a strong and transport-agnostic model for connection management.
  6. AES70's repertoire of management and housekeeping functions is relatively rich.

Class Structure

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:

Protocols

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:

Control Repertoire

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.

Table 1. AES70-2015 Control Repertoire
Media Connection ManagementSignal 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

Notable Features

Connection Management

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.

Control Grouping

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.

Snapshot and Preset Management

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.

Reconfigurable DSP Device Setup

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.

Proprietary Extensibility

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.

Upward / Downward Compatibility

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.

Security

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.

Reliable Firmware Update Capability

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.

Availability

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

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

Also known as OCF, this specification describes the overall architecture of AES70 and describes its mechanisms. OCF is published in a document named AES-1-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 1: Framework. [7]

2. AES70 Class Structure

Also known as OCC, this specification describes the object-oriented class structure that defines the functional repertoire (connection management, control, and monitoring) of AES70. OCC is published in a document named AES70-2-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 2: Class Structure [8]
It is critical for readers also to download this document's Appendix A in either of two forms (see below for explanation):
AES70-2-2015 Appendix A (Enterprise Architect format) [9]
or
AES70-2-2015 Appendix A (XMI format) [10]

3. AES70 Protocols

Also known as OCP.1, OCP.2, etcetera, these specifications describe protocols that implement OCA control over various types of networks.
In AES70-2015, only one protocol -- OCP.1 -- is defined. It is for TCP/IP networks. Future updates to the standard will define additional protocols. OCP.1 is published in a document named AES70-3-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 3: Protocol for TCP/IP Networks [11]
Readers should also download this document's Appendix B in either of two forms (see below for explanation):
AES70-3-2015 Appendix B (Enterprise Architect format) [12]
or
AES70-23-2015 Appendix B (XMI format) [13]

The Appendices

The two appendices listed above are Universal Modeling Language (UML) specifications.

The UML files are in two forms:

  • The *.eap files are master files from a UML tool named Enterprise Architect from Sparx Systems. The usual version of the tool costs US$240, but Sparx Systems offers a free viewer.
  • The *.xmi files are master files in XMI 2.1, a standard format for representation of UML information. XMI stands for "XML Metadata Interchange". XMI files can be opened by most UML editors, including free ones. See XML Metadata Interchange for more information.

The OCA Alliance

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.

Available development tools / code

A number of development tools / open source code is available which helps in start developing AES70 compatible products.

Related Research Articles

<span class="mw-page-title-main">Bluetooth</span> A short-range wireless technology standard

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.

<span class="mw-page-title-main">OSI model</span> Model of communication of seven abstraction layers

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).

<span class="mw-page-title-main">Universal Plug and Play</span> Set of networking protocols

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.

<span class="mw-page-title-main">KNX</span> Standard in building automation

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.

<span class="mw-page-title-main">Electronic test equipment</span> Testing appliance for electronics systems

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.

<span class="mw-page-title-main">H.248</span>

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.

<span class="mw-page-title-main">Profinet</span> Computer network protocol

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.

<span class="mw-page-title-main">Media gateway control protocol architecture</span>

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.

<span class="mw-page-title-main">Audio Video Bridging</span> Specifications for synchronized, low-latency streaming through IEEE 802 networks

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:

References

  1. The Open Control Architecture Alliance, http://ocaalliance.com/
  2. AES24-1-1999 (w2004): AES standard for sound system control - Application protocol for controlling and monitoring audio devices via digital data networks - Part 1: Principles, formats, and basic procedures. 2004: Audio Engineering Society, New York.
  3. AES24-2-tu (w2004): PROPOSED DRAFT AES standard for sound system control - application protocol for controlling and monitoring audio devices via digital data networks - Part 2, data types, constants, and class structure (for Trial Use). 2004: Audio Engineering Society, New York.
  4. Jeffrey Berryman, "Technical Criteria for Professional Media Networks," in Proceedings of AES 44th Conference on Networking, San Diego, 2011.
  5. American National Standards Institute. "E1-17: Architecture for Control Networks" . Definition of ACN. Package of 17 documents plus supporting files. At http://webstore.ansi.org.
  6. Richard Foss and Andrew Eales, "Towards a Standard Model for Networked Audio Devices," in Proceedings of the AES 44th International Conference - Audio Networking, San Diego, 2011 . Includes a helpful overview of current media system control protocols.
  7. AES70-1-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 1: Framework. http://www.aes.org/publications/standards/search.cfm?docID=101. Audio Engineering Society, January 2016.
  8. AES70-2-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 2. http://www.aes.org/publications/standards/search.cfm?docID=102. Audio Engineering Society, January 2016.
  9. AES70-2-2015 Appendix A (Enterprise Architect format). http://www.aes.org/standards/models/AES70-2-AnnexA-151112-class-structure-1.eap. Audio Engineering Society, January 2016
  10. AES70-2-2015 Appendix A (XMI format). http://www.aes.org/standards/models/AES70-2-AnnexA-151112-class-structure-1.xmi. Audio Engineering Society, January 2016.
  11. AES70-3-2015: AES standard for Audio applications of networks - Open Control Architecture - Part 3: Protocol for TCP/IP Networks. http://www.aes.org/publications/standards/search.cfm?docID=103. Audio Engineering Society, January 2016.
  12. AES70-2-2015 Appendix A (Enterprise Architect format). http://www.aes.org/standards\models/AES70-3-AnnexB-151112-tcpip-protocol-1.eap. Audio Engineering Society, January 2016
  13. AES70-2-2015 Appendix B (XMI format). http://www.aes.org/standards/models/AES70-3-AnnexB-151112-tcpip-protocol-1.xmi. Audio Engineering Society, January 2016.
  14. The Open Control Architecture Alliance, http://ocaalliance.com/