STANDARDS AND INFORMATION DOCUMENTS

Transcription

1 AES STANDARDS: DRAFT FOR COMMENT ONLY Secretariat 2018/09/27 21:36 DRAFT REVISED AES70-2-xxxx STANDARDS AND INFORMATION DOCUMENTS Call for comment on DRAFT REVISED AES standard for Audio applications of networks - Open Control Architecture - Part 2: Class structure This document was developed by a writing group of the Audio Engineering Society Standards Committee (AESSC) and has been prepared for comment according to AES policies and procedures. It has been brought to the attention of International Electrotechnical Commission Technical Committee 100. Existing international standards relating to the subject of this document were used and referenced throughout its development. Address comments by to standards@aes.org, or by mail to the AESSC Secretariat, Audio Engineering Society, PO Box 731, Lake Oswego OR 97034, USA. Only comments so addressed will be considered. E- mail is preferred. Comments that suggest changes must include proposed wording. Comments shall be restricted to this document only. Send comments to other documents separately. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. This document will be approved by the AES after any adverse comment received within six weeks of the publication of this call on , has been resolved. Any person receiving this call first through the JAES distribution may inform the Secretariat immediately of an intention to comment within a month of this distribution. Because this document is a draft and is subject to change, no portion of it shall be quoted in any publication without the written permission of the AES, and all published references to it must include a prominent warning that the draft will be changed and must not be used as a standard. AES STANDARDS: DRAFT FOR COMMENT ONLY

2 STANDARDS The AES Standards Committee is the organization responsible for the standards program of the Audio Engineering Society. It publishes technical standards, information documents and technical reports. Working groups and task groups with a fully international membership are engaged in writing standards covering fields that include topics of specific relevance to professional audio. Membership of any AES standards working group is open to all individuals who are materially and directly affected by the documents that may be issued under the scope of that working group. Complete information, including working group scopes and project status is available at Enquiries may be addressed to standards@aes.org The AES Standards Committee is supported in part by those listed below who, as Standards Sustainers, make significant financial contribution to its operation. This list is current as of 2018/9/01

3 AES70-2-xxxx SC L DRAFT REVISED AES standard for audio applications of networks - Open Control Architecture - Part 2: Class structure Published by Audio Engineering Society, Inc. Copyright 2015, 2018 by the Audio Engineering Society Abstract AES70 defines a scalable control-protocol architecture for professional media networks. AES70 addresses device control and monitoring only; it does not define standards for streaming media transport. However, AES70 is intended to cooperate with various media transport architectures. AES70 is divided into a number of separate parts. AES70 is divided into a number of separate parts. This Part 2 specifies the control class structure for AES70 that defines the AES70 control and monitoring functional capabilities and should be read in conjunction with AES70 Part 1: Framework, and AES70 Part 3: OCP.1 Protocol for IP Networks. An AES standard implies a consensus of those directly and materially affected by its scope and provisions and is intended as a guide to aid the manufacturer, the consumer, and the general public. The existence of an AES standard does not in any respect preclude anyone, whether or not he or she has approved the document, from manufacturing, marketing, purchasing, or using products, processes, or procedures not in agreement with the standard. Prior to approval, all parties were provided opportunities to comment or object to any provision. Attention is drawn to the possibility that some of the elements of this AES standard or information document may be the subject of patent rights. AES shall not be held responsible for identifying any or all such patents. Approval does not assume any liability to any patent owner, nor does it assume any obligation whatever to parties adopting the standards document. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. This document is subject to periodic review and users are cautioned to obtain the latest edition. Audio Engineering Society Inc. 551 Fifth Avenue, New York, NY 10176, US. standards@aes.org page 1 of 21

4 Contents 0 Introduction General Documentation conventions Scope Normative references Terms, definitions and abbreviations Class structure Informative overview General Control classes Datatypes Worker classes Manager Classes Agent Classes Network classes Control Datatypes Control Class Construction Parameters...10 Annex A. (Normative) - UML Class Structure Definition...11 Annex B. (Normative) - Minimum compliant device model...12 B.1 Introduction...12 B.2 AES70 compliance...12 B.3 Required objects...12 B.3.1 General...12 B.3.2 Required Managers...12 B.3.3 Required Workers...13 B.3.4 Required Agents...13 B.3.5 Required Networks...14 B.4 Required Methods and Events for Required Objects...14 B.4.1 General...14 B.4.2 Base set...14 B.4.3 OcaDeviceManager...14 B.4.4 OcaSecurityManager...15 B.4.5 OcaSubscriptionManager...15 B.4.6 OcaNetworkManager...15 B.4.7 OcaMediaClockManager...15 B.4.8 OcaDeviceTimeManager...15 B.4.9 OcaCodingManager...15 B.4.10 OcaBlock...15 B.4.11 OcaMediaClock3 and OcaMediaClock...16 B.4.12 OcaTimeSource...16 B.4.13 OcaNetwork and OcaStreamNetwork...16 B.4.14 OcaControlNetwork...16 B.4.15 OcaMediaTransportNetwork...17 Annex C. (Informative) - Changes in AES from AES C.1 Control class versions...18 C.2 Connection Management 3 (CM3)...18 C.3 Improved support for clocking and time...18 C.4 WebSocket and UDP Protocol support...18 C.5 Improved object search features...19 Page 2 of 21

5 C.6 Upgraded ClassID format to support proprietary classes more completely...19 C.7 Reusable blocks...19 C.8 Better support for proprietary volume types in OcaLibrary...20 C.9 Support for nonexclusive locking of objects...20 C.10 The OcaPhysicalPosition class...20 C.11 The AES70 task mechanism...21 Page 3 of 21

6 Foreword This foreword is not part of this document, AES70, AES standard for audio applications of networks - Open Control Architecture - Part 2: Class structure. This document, AES70-2, is a member of the three-document set that defines AES70, the Open Control Architecture (OCA). AES70-2 defines the control class structure. Other parts define the overall framework and the specific protocols used. The development project for this standard was originally proposed by the Open Control Architecture Alliance (OCA Alliance) and initiated in October 2012 as project AES70 to be developed in task group SC L. The OCA Alliance also contributed to the task-group working draft and, as a result, there are various references to "OCA" in the protocol, in order to maintain compatibility with implementations already in the field. The members of the writing group that drafted this version of the document are: F. Bergholtz, J. Berryman, A. Gödeke, J. Grant, A. Kuzub, M. Lave, G. Linis, S. Price, M. Renz, A. Rosen, S. Scott, G. Shay, P. Stevens, P. Treleaven, S. van Tienen, and E. Wetzell. As well, the writing group was materially assisted by contributions from T. de Brouwer, B. Escalante, S. Jones, M. Smaak, and M. Versteeg. J. Berryman led the writing group. Morten Lave Chair, working group SC Note on normative language In AES standards documents, sentences containing the word "shall" are requirements for compliance with the document. Sentences containing the verb "should" are strong suggestions (recommendations). Sentences giving permission use the verb "may". Sentences expressing a possibility use the verb "can". Page 4 of 21

7 0 Introduction 0.1 General Proposed Call for Comment on DRAFT AES standard for Audio applications of networks - Open control architecture - Part 2: Class Structure This document defines the class structure of the Open Control Architecture (OCA) for the control and monitoring of media networks. The class structure defines the control repertoire. In what follows, the class structure is referred to as AES70 Open Control Class structure (OCC). The elements of the AES70 OCC are class definitions in the object-oriented design sense. Each class defines a particular control or monitoring interface element that is accessible over the media network via one or more communications protocols that AES70 defines. An AES70-controllable device may implement a set of these interface elements; the complete set constitutes the interface the device presents to the network for remote control and monitoring purposes. This interface is called the AES70 device model and is defined in [AES70-1]. To distinguish OCC classes from programming classes, this standard may where appropriate refer to OCC classes as control classes, and their instances as control objects, where it should be understood that "control" includes both control and monitoring functions. AES70 specifies system control and monitoring only. It may be integrated with any streaming media transport scheme, as long as the underlying communication network is capable of carrying AES70 control and monitoring traffic. AES70 does not define a complete device implementation model. For example, if a particular implementation element has no remotely controllable features, then that element is not represented in the AES70 device model. 0.2 Documentation conventions Numerical values are decimal unless otherwise stated. A Courier typeface is used to identify class names to distinguish them from regular text. Where new terminology is first introduced in body text, the term will be set in an italic typeface. 1 Scope AES70 defines a scalable control-protocol architecture for professional media networks. AES70 addresses device control and monitoring only; it does not define standards for streaming media transport. AES70 is divided into several parts. This Part 2 specifies the control class structure for AES70 that defines the control and monitoring functional capabilities of the standard and should be read in conjunction with AES70-1. Page 5 of 21

8 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. AES70-1 AES standard for audio applications of networks - Open Control Architecture - Framework, Audio Engineering Society, New York, NY., US. AES70-3 AES standard for audio applications of Networks - Open Control Architecture - Part 3: Protocol for TCP/IP Networks, Audio Engineering Society, New York, NY., US. ISO/IEC Ed.1:2005 Information technology XML Metadata Interchange (XMI), International Standards Organization (ISO), Geneva, Switzerland. ISO/IEC Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and basic multilingual plane. International Standards Organization (ISO), Geneva, Switzerland. ITU-1(8) Recommendation ITU-R BS (06/2017): Audio Definition Model. International Telecommunications Union, Geneva, Switzerland SMPTE SMPTE Profile for Use of IEEE-1588 Precision Time Protocol in Professional Broadcast Applications. Society of Motion Picture and Television Engineers, Piscataway, NJ, US. 3 Terms, definitions and abbreviations For the purposes of this document, the following terms, definitions, and abbreviations apply. See AES70-1, clause Terms, definitions, and abbreviations. 4 Class structure The class structure shall be defined by a Universal Modeling Language (UML) document in XML Metadata Interchange (XMI) 2.1 format as defined in ISO/IEC See Annex A for access data. NOTE 1 This XMI machine-readable format is intended to enable implementers to have direct access to the class model with maximum speed and the minimum risk of transcription errors compared with building individual class models from a traditional paper description. NOTE 2 The XMI class model can be viewed and edited in a suitable UML application, such as Enterprise Architect from Sparx Systems. 5 Informative overview 5.1 General This section gives a brief overview of OCC, the AES70 class structure. Page 6 of 21

9 5.2 Control classes OCC defines three categories of control classes, as follows: Workers Agents Managers Classes that represent signal processing and monitoring functions. Classes that represent control-flow processing functions. Classes that represent device housekeeping functions. An AES70 device model consists entirely of objects of classes from these categories. 5.3 Datatypes OCC also provides two sets of supporting definitions: Control Datatypes Control Class Construction Parameters Datatypes used by the control classes. Datatypes used in the construction of control classes An overview of the class structure is shown in Figure 1. Summaries of the class categories follow. Page 7 of 21

10 OCC Control Classes Workers Agents Networks Managers Control Datatypes (many) Actuators Sensors (many) (many) Blocks & Matrices (several) Control Class Construction Parameters (many) (many) Application Network Media Transport Network Control Network Device Manager Security Manager Firmware Manager Subscription Manager Network Manager Power Manager Media Clock Manager Library Manager Audio Processing Manager DeviceTime Manager Task Manager Coding Manager Diagnostic Manager Figure 1 - Class structure overview Page 8 of 21

11 5.4 Worker classes Worker classes describe device application functions. There are three kinds of Workers: Actuators Sensors Blocks and Matrices Signal processing and routing functions. Detectors and monitors of various types; for example, signal level, gain reduction, temperature. Classes that aggregate objects into structured collections. Used for modeling and managing structures of complex devices. For any given device, a Worker class may be instantiated as many times as necessary to model the device's functions. Where necessary, a Worker class may be refined and extended by a manufacturer-specific child class. This is explained further in AES Manager Classes Manager classes describe device housekeeping functions. For each device, manager classes are singletons; that is, each one is instantiated at most once per device. Some manager classes are required for AES70 compliance and shall be instantiated in every device; others are optional. Not all interface elements of all required classes are required. Minimum device requirements for AES70 compliance are defined in Annex B. The manager classes are: Device Manager Security Manager Firmware Manager Subscription Manager Network Manager Power Manager Media Clock Manager Library Manager Audio Processing Manager Device Time Manager Task Manager Coding Manager Diagnostic Manager 5.6 Agent Classes Contains manufacturer and model information and controls overall device state. Controls security features, or reports that there are none. Manages device firmware updating, or reports that it is not implemented. Manages the reporting of device data back to controllers. Holds a collection of the device's network interfaces, as defined by the network objects mentioned in clause 5.7. Allows control and monitoring of device's power supply or supplies. Gives access to device's media clocking features. Controls creation, management, and use of stored parameter sets (also known as "presets", "patches", and so on) Gives access to global parameters controlling audio processing. Gives access to the device's time-of-day clock, if any. Controls the device s execution of predefined execution sequences. Gives access to device s media encoding and decoding features. Placeholder for device-specific diagnostic functions. These are the classes that provide notable control features that are not directly related to signal processing. The agent classes are: Page 9 of 21

12 OcaGrouper OcaRamper OcaNumericObserver Supports control aggregation, allowing a single parameter change to affect many objects. Similar in effect to a VCA master on a mixing console. Provides incremental parameter changes - timed fades, for example. Also provides queuing of parameter changes to occur at specified times in the future. A "watcher" that observes a particular parameter, and alerts controllers when it reaches a particular value. Also supports periodic reporting of parameter values (for example, level meter readings) to controllers. OcaNumericObserverList Same as OcaNumericObserver, but observes a list of parameters. OcaLibrary OcaMediaClock3 OcaTimeSource OcaPhysicalPosition OcaEventHandler 5.7 Network classes OcaApplicationNetwork OcaControlNetwork OcaMediaTransportNetwork Control Datatypes Provides a range of functions for pre-storing sets of parameters in the device and applying them when desired. Describes an internal or external media clock that the device uses. Can be multiply instantiated for devices which support more than one media clock. Describes an internal or external time reference. Describes the physical position of the device or of some other point in space. Describes the controller interface that handles incoming notifications from controlled devices. Classes for control traffic and for connection management of incoming and outgoing media streams. OCC defines a range of control datatypes. These datatypes are used in the definitions of the classes listed above. Details are in annex A. 5.8 Control Class Construction Parameters Some DSP-based products allow controllers to define their processing topologies. AES70 refers to these as configurable devices. In some configurable devices, controllers can cause new processing objects to be created and deleted. AES70 refers to these as fully-configurable devices. When a controller creates an object in a fully configurable device, certain parameters may be required. For example, if a controller creates a multiposition switch, it needs to specify how many positions the switch has and, optionally, a text label for each position. Such parameters are called construction parameters. The number and kind of construction parameters varies from class to class. OCC contains a separate subtree that specifies the construction parameters that are required for each class. This subtree has an entry corresponding to every Worker class and every Agent class. AES70 does not support the runtime creation of Manager objects by fully-configurable devices, so these are not included in the construction parameter set. Page 10 of 21

13 Annex A. (Normative) - UML Class Structure Definition The content of the Annex is an external XMI 2.1 document, as described above in clause 4. It may be downloaded from: NOTE: as an informative equivalent, users may prefer to use a proprietary Enterprise Architect version, available from: Page 11 of 21

14 B.1 Introduction Annex B. (Normative) - Minimum compliant device model This Annex specifies the minimum device model that a device shall implement to be compliant with AES70. In what follows here, an AES70-compliant device is referred to as an AES70 device, and the device model of such a device is referred to as a compliant device model. B.2 AES70 compliance Every AES70-compliant device shall implement at least the minimum device model elements specified in this Annex, and shall implement at least one AES70 protocol. An AES70 protocol is defined in AES70-3. B.3 Required objects B.3.1 General This section identifies objects that are required for compliance. A 'minimum implementation' necessarily depends on whether the device is required to support encrypted command streams (secure); or send and receive digital media streams over a network (streaming); or both. An AES70 device may include optional objects as needed, to render some or all its functions accessible for control and/or monitoring from the connected network. NOTE AES70 compliance does not require a device to include AES70 Workers or Agents for all its functions; manufacturers may freely select which functions to make controllable via the network. In the tables to follow, the heading ONo means Object Number. B.3.2 Required Managers The manager objects that shall be implemented by an AES70 device are shown in table B.1. Each required object shall implement all the methods defined by its class. Many of these methods may return a "Not Implemented" status where appropriate. The model identified in clause 4 provides details. Table B.2 contains manager objects that shall be implemented if, and only if, certain conditions are met. The table indicates what conditions apply for these manager objects. Manager Object Table B.1 - Required manager objects ONo Required for devices: All Secure Streaming OcaDeviceManager 1 OcaSecurityManager 2 Page 12 of 21

15 Table B.2 - Conditionally required manager objects Manager Object ONo Required for devices: OcaSubscriptionManager 5 Mandatory if a device supports event subscriptions. Absence of this manager object indicates that a device does not support event subscriptions. A device may support (a) no subscriptions, (b) only lightweight subscriptions, or (c) all forms of subscriptions. OcaNetworkManager 6 Mandatory if a device contains more than one network object. OcaMediaClockManager 7 Mandatory if a device contains more than one clock object. OcaDeviceTimeManager 10 Mandatory if a device contains more than one time source object. OcaCodingManager 12 Mandatory if a device implements more than one encoding scheme or more than one decoding scheme. Optional if a device only implements one encoding and/or one decoding scheme. B.3.3 Required Workers The Worker objects that shall be implemented by all AES70 devices are shown in table B.3. Table B.3 - Required Worker objects Required for devices: Worker Object ONo All Secure Streaming OcaBlock (Root Block) 100 B.3.4 Required Agents The Agent objects that shall be implemented by AES70 devices are shown in table B.4. Table B.4 - Required Agent objects Required for devices: Agent Object ONo All Secure Streaming OcaMediaClock3 varies OcaTimeSource Varies NOTE implementations of earlier AES70 versions may also use an OcaMediaClock object, but in AES this is deprecated and should not be specified in new designs Page 13 of 21

16 B.3.5 Required Networks The Network objects that shall be implemented by all AES70 devices are shown in table B.5. Table B.5 - Required Network objects Required for devices: Network Object ONo All Secure Streaming OcaControlNetwork varies OcaMediaTransportNetwork varies NOTE earlier AES70 implementations may also use an OcaNetwork or OcaStreamNetwork Agent object, but in AES these are deprecated and should not be specified in new designs. B.4 Required Methods and Events for Required Objects B.4.1 General All methods that are defined by a required object s class shall be present in the device model. Where a method is not implemented in the particular device, it shall return a NotImplemented result. In the text that follows, all methods and events refer to all methods and events of the class being described, as specified in clause 4. B.4.2 Base set All objects shall implement the following methods, which are elements of the OcaRoot class and are therefore inherited by all classes: GetLockable( ) Lock(...) Unlock(...) LockReadonly(...) event PropertyChanged(...) B.4.3 OcaDeviceManager GetDeviceName(...) GetEnabled(...) SetEnabled(...) GetManagers(...) GetModelDescription(...) GetModelGUID(...) GetOcaVersion(...) GetSerialNumber(...) GetState(...) GetDeviceRevisionID(...) Only read-only objects may return False Implemented only if object is lockable Implemented only if object is lockable Implemented only if object is lockable. Implemented only if device supports subscriptions Page 14 of 21

17 B.4.4 OcaSecurityManager When an OcaSecurityManager object is implemented, it shall implement all methods and events of the OcaSecurityManager class. B.4.5 OcaSubscriptionManager When an OcaSubscriptionManager object is implemented, it shall implement the following methods of the OcaSubscriptionManager class: AddSubscription(...) RemoveSubscription(...) RemoveSubscriptionSpecific(...) AddPropertyChangeSubscription(...) RemovePropertyChangeSubscription(...) B.4.6 OcaNetworkManager When an OcaNetworkManager object is implemented, it shall implement all methods and events of the OcaNetworkManager class. B.4.7 OcaMediaClockManager When an OcaMediaClockManager object is implemented, it shall implement all methods and events of the OcaMediaClockManager class. B.4.8 OcaDeviceTimeManager When an OcaDeviceTimeManager object is implemented, it shall implement the following methods of the OcaDeviceTimeManager class: GetDeviceTime(...) GetTimeSources(...) GetCurrentDeviceTimeSource(...) SetCurrentDeviceTimeSource(...) B.4.9 OcaCodingManager When an OcaCodingManager object is implemented, it shall implement all methods and events of the OcaCodingManager class. B.4.10 OcaBlock Each OcaBlock object shall implement the following methods of the OcaBlock class: GetEnabled(...) SetEnabled(...) GetPorts(...) GetMembers(...) inherited from OcaWorker inherited from OcaWorker inherited from OcaWorker Page 15 of 21

18 B.4.11 OcaMediaClock3 and OcaMediaClock Each OcaMediaClock3 object shall implement the following methods: GetAvailability(...) GetTimeSourceONo(...) GetOffset(...) GetCurrentRate(...) GetSupportedRates(...) GetSupportedTimeSources(...) Each OcaMediaClock object shall implement the following methods: GetType(...) GetSupportedRates(...) GetRate(...) GetLockState(...) This class is deprecated and should not be specified in new designs. B.4.12 OcaTimeSource Each OcaTimeSource object shall implement the following methods: GetAvailability(...) GetProtocol(...) GetParameters(...) GetReferenceType(...) GetReferenceID(...) GetSyncStatus(...) B.4.13 OcaNetwork and OcaStreamNetwork Each OcaNetwork or OcaStreamNetwork object shall implement the following methods: GetLinkType(...) GetIDAdvertised(...) GetControlProtocol(...) GetMediaProtocol(...) GetSystemInterfaces(...) These classes are deprecated and should not be specified in new designs. B.4.14 OcaControlNetwork Each OcaControlNetwork object shall implement the following methods and events of the OcaControlNetwork class: GetIDAdvertised(...) GetSystemInterfaces(...) GetControlProtocol(...) Inherited from OcaApplicationNetwork Inherited from OcaApplicationNetwork Page 16 of 21

19 B.4.15 OcaMediaTransportNetwork Each OcaMediaTransportNetwork object shall implement the following methods and events of the OcaMediaTransportNetwork class: GetIDAdvertised(...) inherited from OcaApplicationNetwork GetSystemInterfaces(...) inherited from OcaApplicationNetwork ConnectorStatusChanged event GetMediaProtocol(...) GetPorts(...) GetMaxSourceConnectors(...) GetMaxSinkConnectors(...) GetMaxPinsPerConnector(...) GetMaxPortsPerPin(...) GetConnectorStatuses(...) GetConnectorStatus(...) DeleteConnector(...) In addition, if the device is capable of sending (sourcing) media streams, its OcaMediaTransportNetwork objects shall implement the following methods and events of the OcaMediaTransportNetwork class: SourceConnectorChanged event GetSourceConnectors(...) GetSourceConnector(...) AddSourceConnector(...) UpdateSourceConnector(...) In addition, if the device is capable of receiving (sinking) media streams, its OcaMediaTransportNetwork objects shall implement the following methods and events of the OcaMediaTransportNetwork class: SinkConnectorChanged GetMaxSinkConnectors(...) GetSinkConnectors(...) GetSinkConnector(...) AddSinkConnector(...) UpdateSinkConnector(...) event Page 17 of 21

20 Annex C. (Informative) - Changes in AES from AES AES is not a major upgrade to AES , but it does contain several important changes. C.1 Control class versions For AES , the version numbers of all AES control classes have been incremented. This will allow controllers to distinguish between AES and AES implementations. C.2 Connection Management 3 (CM3) In this context, connection management means setting up, configuring, controlling, monitoring, and taking down media stream connections between devices. The new connection management scheme of AES is called Connection Management 3 or CM3. The scheme in AES is known as Connection Management 2 (CM2). CM1 was a developmental scheme that was never standardized. In comparison to CM2, CM3 has lower storage requirements, better management of connection parameters, much better management of clocking, better and more flexible codec support, and is generally easier to implement in both devices and controllers. CM3 is described in Part 1, in clause Connection Management, and in Part 2, Annex A, in the UML definitions found in the packages Control Classes.Networks and Control Datatypes.Network Datatypes. AES still includes the specification of CM2, although CM2 classes are now deprecated. AES compliant devices can support coexisting CM2 and CM3 implementations with no conflicts. C.3 Improved support for clocking and time The new classes OcaTimeSource and OcaMediaClock3 provide improved ways of describing and controlling external time references and media clocks. For details, see their definitions in the Agents package in the UML class description in Part 2 Annex A. C.4 WebSocket and UDP Protocol support AES will now run over WebSocket and UDP links, as well as the TCP links used heretofore. Features and restrictions of these new link types are as follows: Encryption and authentication are supported only over TCP links, not WebSocket or UDP links. WebSocket and UDP versions use the same protocol data unit formats as the TCP version. WebSocket implementations need implement only a few webserver functions, not entire webservers. UDP links are for small, noncritical applications on single IP subnets. The UDP version uses fewer device resources, but is inherently less reliable. For UDP functions, the rules for supervision ( keepalive ) functions are a little different from the other versions. For details, see AES , Part 3. Page 18 of 21

21 C.5 Improved object search features AES includes features to help controllers locate objects by their Role properties. Role is a property of every AES70 object. It is designed to be a text description of the object s function in the device. Role is analogous to the text printed adjacent to a control knob, button, or indicator on the front-panel of a conventional manually-controlled device. Roles are fixed at object creation time, which means for most devices they will be set a time of manufacture. The new Role features in AES are: Method GetPath(...) in class OcaWorker and class OcaAgent. These methods return the Rolepath of an object. The Rolepath is the ordered list of the Roles of all an object s nested containing OcaBlocks followed by the Role of the object itself. The following methods in class OcaBlock: FindObjectsByRole(...) FindObjectsByRoleRecursive(...) FindObjectsByPath(...) FindObjectsByLabelRecursive(...) These methods find objects within blocks based on various search criteria. Using Roles to find objects means that controllers will not need to have prior knowledge of a device s set of object numbers, but instead can discover the object numbers at runtime by searching for the objects desired. This improves interoperability and makes object number management far simpler. For details, see clause Device Model / Worker Classes / Blocks in AES70 Part 1, and, in Part 2 Annex A, the definitions of the classes OcaWorker, OcaAgent, and OcaBlock. C.6 Upgraded ClassID format to support proprietary classes more completely Format of the ClassID has been revised (compatibly) to support proprietary classes (i.e., classes manufacturers add to the standard class tree for special purposes). The previous scheme, in AES , allowed proprietary ClassID values, but did not prevent clashes if proprietary classes from two different sources were combined in one device. The new scheme includes a unique company ID (an IEEE OUI or CID) in proprietary ClassID values, and therefore allows free mixing of such classes with no conflicts. For details, please see clause Top level design / Object orientation / Classes / Class identifiers in AES70 Part 1. The new ClassID scheme is upwards-compatible with the AES scheme, except that the class index value 65,535 = FFFF 16 is now reserved. C.7 Reusable blocks A manufacturer or other design source may now assign unique identifiers (global block identifier) to specific OcaBlock configurations. An OcaBlock so identified is termed a reusable block. Resuable blocks may be instantiated in multiple products, where controllers will recognize them by their global block identifiers, and invoke corresponding common controller codes. It is anticipated that companies using AES70 will develop libraries of reusable block specifications for deployment across their product lines. Global block identifiers include unique company identifiers Page 19 of 21

22 (IEEE OUI or CID), which ensures that companies can allocate identifier values without fear of clashing with others. C.8 Better support for proprietary volume types in OcaLibrary The agent object OcaLibrary is designed to store large binary objects( volumes ) of various types, including both standard types and proprietary types. Each volume type is identified by a unique code named OcaLibVolType. Under AES , the possibility existed for proprietary OcaLibVolType values to clash if proprietary libraries from multiple companies were installed in the same device. In AES , the structure of OcaLibVolType is changed to include an IEEE OUI or CID value that uniquely identifies the source, so that clashes are now impossible. For standard (i.e. non-proprietary) OcaLibVolType values, AES and AES are the same. The AES scheme is incompatible with the AES scheme. Controllers of devices that use OcaLibrary will need to distinguish between class version 1 of OcaLibrary, which is in AES , and class version 2, which is in AES For details, please see the Libraries clause of Part 1, and the definition of OcaLibVolType in package Control Datatypes.Library Datatypes of the UML class definition in Part 2, Annex A. C.9 Support for nonexclusive locking of objects AES now supports an object locking option that allows read-only access to locked objects. Previously, AES supported only exclusive locking, in which properties of locked objects could be neither retrieved nor changed by controllers other than the lock holder. AES now supports two locking options: LockTotal, which is identical to the exclusive lock defined in AES , and LockReadonly, which prevents change of locked objects, but allows retrieval of their properties values. This change is implemented compatibly. When an AES compliant controller locks an AES device via the Lock() method that is defined in AES , the resulting lock state is LockTotal, i.e. exclusive lock. For details, please see the definition of the OcaRoot class in the UML package Control Datatypes in Part 2, Annex A. C.10 The OcaPhysicalPosition class The new OcaPhysicalPosition class defines an agent that can report and, depending on implementation, change a physical position. This class has several expected usecases, including: 1. Reporting physical position of active loudspeakers and microphones that can sense their locations and orientations; 2. Allowing manipulation of object-based audio program entities; 3. Controlling position and/or orientation of automated mechanical devices; 4. Supporting geographically-aware devices. Page 20 of 21

23 To support these and other purposes, OcaPhysicalPosition has options for working in three kinds of coordinate systems: (a) six-axis robotic coordinates; (b) object-based audio coordinates of several types; and (c) world geographic coordinates such as are used in GPS. For details, see the definition of OcaPhysicalPosition in the Agents package of the UML class descriptions in Part 2, Annex A. C.11 The AES70 task mechanism AES defines a new architectural concept called the AES70 Task mechanism. This mechanism allows management and control of transient processes within a device. Examples of such processes include: Execution of predefined, prepackaged real-time actions. Such sequences are called cues in some contexts, edits in other contexts, and may have other names. They may be simple, or they may have many stages. Execution of timed control operations such as fades, crossfades, timed pans, and other segues. Execution of predefined system configuration changes. Execution of emergency procedures involving system state changes, control actions, and so on. Media playback. Execution of mechanical operations in articulated devices. The Task mechanism is based on two concepts: 1. The Program, a predefined entity that defines the action(s) to be performed; and 2. The Task, a container that executes the program. In AES , Programs are stored as OcaLibrary volumes whose OcaLibVolType is Program, and Tasks are defined in data structures collected by a new Manager class, OcaTaskManager. OcaTaskManager provides methods for defining Tasks, for assigning Programs to them, and for starting, stopping, and monitoring them. AES does not define a method for encoding the specific actions of Programs - conditions tested, steps executed, notifications generated, et cetera. Often defined by scripting languages, such specifications are outside AES70 s scope. AES only defines the means for storing Programs as OcaLibrary volumes, which are unstructured binary large objects. For details, see the Tasks and Library clauses of Part 1, and the definition of OcaTaskManager in the Managers package of the UML class descriptions in Part 2, Annex A. Page 21 of 21