Path: Home > GY/T > Page3 > GY/T 322.1-2019

Price & Delivery

US$1179.00 · In stock · Download in 9 seconds
GY/T 322.1-2019: Audio applications of networks-open control architecture - Part 1: Framework
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See step-by-step procedure
Status: Valid

Std ID	Version	USD	Buy	Deliver [PDF] in	Title (Description)
GY/T 322.1-2019	English	1179	Add to Cart	8 days [Need to translate]	Audio applications of networks-open control architecture - Part 1: Framework

GY/T 322.1-2019: Audio applications of networks-open control architecture - Part 1: Framework

---This is a DRAFT version for illustration, not a final translation. Full copy of true-PDF in English version (including equations, symbols, images, flow-chart, tables, and figures etc.) will be manually/carefully translated upon your order.
(Open control architecture for network audio applications Part 1. Framework) GY Radio and Television Industry Standards of the People's Republic of China Open control architecture for network audio applications Part 1. The framework Audio applications of networks-open control architecture- Part 1. Framework 2019-04-28 released 2019-04-28 Implementation Published by the State Administration of Radio and Television

Contents

Foreword ... III Introduction ... IV 0.1 Overview ... IV 0.2 Architectural goals and constraints ... IV 1 Scope ... 1 2 Normative references ... 1 3 Terms, definitions and abbreviations ... 1 3.1 Terms and definitions ... 1 3.2 Acronyms ... 1 4 Top-level design ... 2 4.1 Overview ... 2 4.2 Object-oriented ... 2 4.3 Messages ... 5 5 Device model ... 6 5.1 Device configurability ... 6 5.2 Object addressing ... 6 5.3 Equipment model ... 7 5.4 Unit of work class ... 9 5.5 Proxy class ... 17 5.6 Snap-in class ... 23 5.7 Standard object number ... 23 5.8 Object text identification ... 23 5.9 Constructing objects ... 24 5.10 Deleting objects ... 24 6 Events and subscriptions ... 24 6.1 Subscriptions, events, senders, and notifications ... 24 6.2 PropertyChanged event ... 25 6.3 Using the Numeric Viewer ... 25 7 Network system ... 26 7.1 Overview ... 26 7.2 Media transmission connection management ... 28 7.3 Adaptation of Open Control Architecture ... 28 8 Sessions ... 30 9 Safety ... 30 10 Concurrency Control ... 31 11 Reliability ... 31 11.1 Overview ... 31 11.2 Availability ... 32 11.3 Robustness ... 32 12 Device reset ... 32 13 Firmware and software updates ... 32 13.1 Overview ... 32 13.2 Update types ... 33 13.3 Update mode ... 33 13.4 Update mechanism ... 33 Appendix A (informative) Examples of actuators ... 35 A.1 Overview ... 35 A.2 Properties, methods, and events ... 35 Appendix B (Informative) Block Examples ... 38 B.1 Simple microphone channel ... 38 B.2 Two-Channel Microphone Mixer ... 38 B.3 Mixer with Nested Blocks ... 39 Appendix C (informative) Example of network connection management ... 41 C.1 Example of stream-based connection ... 41 C.2 Example of channel-based connection ... 43

Foreword

GY/T 322 "Open Control Architecture for Network Audio Applications" is divided into the following three parts. -Part 1. Framework; -Part 2. Class structure; -Part 3. Protocols for TCP/IP networks. This part is the first part of GY/T 322. This section is drafted in accordance with the rules given in GB/T 1.1-2009. This section is prepared with reference to AES70-1-2015 "Open Control Architecture for Network Audio Applications Part 1. Framework". Please note that some elements of this document may involve patents. The issuer of this document is not responsible for identifying these patents. This section is under the jurisdiction of the National Radio, Film and Television Standardization Technical Committee (SAC/TC 239). Drafting units of this section. China Central Radio and TV Station, State Administration of Radio and Television Academy of Radio and Television Science, State Administration of Radio and Television Broadcasting and Television Planning Institute, Jiangsu Provincial Radio and Television General Station, Zhejiang Radio and Television Group, Suzhou Fuchuan Technology Co., Ltd., Beijing Infineon Technology Co., Ltd., Beijing Zhonghechuan New Technology Co., Ltd., Hangzhou Lianhui Technology Co., Ltd., Shanghai Baibei Technology Development Co., Ltd., Beijing Jebsen Century Technology Co., Ltd., Suzhou University. The main drafters of this section. Qian Yuelin, Zhu Feng, Luo Pan, Pan Yu, Zhang Lei, Wang Lanlan, Pang Chao, Tang Feng, Zhang Wei, Deng Xiangdong, Dong Sheng Lai, He Jing, Sun Yanjun, Li Weimin, Chen Wu, Dong Xiaopo, Chen Qin, Tang Weiping, Chen Lide, Zhao Chongfeng, Xiao Zhongyi.

Introduction

0.1 Overview The Open Control Architecture (OCA) specifies an extensible control protocol architecture for professional media network monitoring. Open control architecture only Regarding device monitoring, there are no defined standards for transmitting streaming media or describing media content. As long as the underlying communication network can carry open control Monitoring architecture, it can be integrated with any streaming media transmission protocol. The open control architecture does not provide a complete device implementation model. The open control architecture establishes the monitoring function model of the device and does not include Its all signal paths. If certain elements of the equipment do not have remote controllable features, it is not necessary to It is expressed in the protocol interface. The first part of the open control architecture is based on AES70-1-2015 "Open control architecture for network audio applications Part 1. Framework" The second part of the open control architecture defines the class structure of the open control architecture for media network monitoring. Part 2 is a reference Prepared by AES70-2-2015 "Open Control Architecture for Network Audio Applications Part 2. Class Structure" The third part of the open control architecture is based on AES70-3-2015 "Open control architecture for network audio applications Part 3. For "TCP/IP Network Protocol", the original English text can be obtained from 0.2 Architecture goals and constraints The open control architecture is based on the following functional requirements and requirements. a) Functional The open control architecture supports the following functions. 1) Discover devices connected to the network that conform to the open control architecture; 2) Define or undefine the media stream path between devices; 3) Perform control operations and parameter configuration for devices that conform to the open control architecture; 4) Perform monitoring operations and parameter configuration for devices that conform to the open control architecture; 5) For devices with reconfigurable signal processing and/or control capabilities, define and manage configuration parameters; 6) Upgrade the software and firmware of the controlled device. Includes fail-safe upgrade capabilities. b) Security The open control architecture supports the following security measures for data control and monitoring. 1) entity authentication; 2) Anti-eavesdropping; 3) integrity protection; 4) Freshness-"Freshness" here refers to the authenticity of the replay message detected in the replay attack. c) scalability The open control architecture supports networks with at least 10,000 application devices. Open control architecture applies physical distribution of equipment Line minimum limit. d) availability The open control architecture supports high availability by providing the following features. 1) Device management of devices that conform to the open control architecture; 2) Manage the network connected to the equipment that complies with the open control architecture; 3) Efficient network re-initialization after errors and configuration changes. e) Robustness The open control architecture supports robustness by providing. 1) Operation confirmation mechanism; 2) Handle mechanisms for controlling data loss; 3) Mechanisms for handling equipment failures that conform to the open control architecture; 4) Suggestions on network robustness mechanisms that network implementers can use. f) Safety standards The open control architecture allows implementation of media networks that comply with emergency safety standards. g) compatibility During the development of open control architecture, compatibility between different versions will be maximized. Based on open control architecture One version of the controller will run on another version of an open control architecture-compliant device based on. 1) For devices based on the old version, the new version of the controller works according to the same version as the device; 2) For devices based on the newer version, the older version of the controller can monitor all the functions of the same version of the device in the device, It does not interfere with functions defined only in the device version. h) Analysability The open control architecture defines diagnostic functions that allow access to the following information. 1) Version information of all components, hardware and software of each device; 2) Network parameters of the device (such as MAC address, IP address); 3) Device status (including device network interface status); 4) media stream parameters (for each activity of the device to receive and/or send media streams); 5) Communication error. Open control architecture for network audio applications Part 1. The framework

1 Scope

This part of GY/T 322 specifies the model and mechanism of the open control architecture of network audio applications. These models and mechanisms make up The framework of an open control architecture. This section applies to the monitoring of network audio applications. It does not apply to streaming media or describing media content.

2 Normative references

The following documents are essential for the application of this document. For dated references, only the dated version applies to this document. For undated references, the latest version (including all amendments) applies to this document. GB/T 13000-2010 Information Technology Universal Multi-octet Coded Character Set (UCS) (ISO /IEC 10646..2003, IDT) GY/T 322.2-2019 Open Control Architecture for Network Audio Applications Part 2. Class Structure GY/T 322.3-2019 Open Control Architecture for Network Audio Applications Part 3. Protocols for TCP/IP Networks 3 Terms, definitions and abbreviations 3.1 Terms and definitions The following terms and definitions apply to this document. 3.1.1 Controller A networked software unit that monitors equipment through an interface that conforms to an open control architecture. Note. The controller can be hosted in a dedicated computer or a software unit running in a device or some other environment. 3.1.2 Control protocol Application protocol for remote monitoring of network device application functions. 3.2 Acronyms The following abbreviations apply to this document. OCA Open Control Architecture ONo Object Number PDU Protocol Data Unit VCA Voltage-controlled Amplifier 4 Top-level design 4.1 Overview The open control architecture supports monitoring of devices that conform to the open control architecture at the application layer. It does not provide audio and video signal transmission, and It needs to be integrated with various audio and video signal transmission schemes. The protocol provided by the open control architecture is extensible, and it can orderly merge new device types and device upgrades to support various media networks. Improve the upgrade of the functions in the network in an upward compatible way. The open control architecture is suitable for professional media networks. For a simple network of no more than 100 nodes, when using the recommended switch, set The installation process should not require technical staff to have advanced network knowledge. Specific requirements are as follows. a) the network of open control architecture can be run using industry standard data network equipment; b) Equipment conforming to the open control architecture can coexist harmlessly with equipment not conforming to the open control architecture; c) The network of open control architecture can be operated in safe or unsafe mode according to the needs of products and applications. 4.2 Object-oriented 4.2.1 Concept The open control architecture describes the control interface of a communication device as a collection of objects. Each object is a software unit that is class-specific Instantiates and has states (called properties) and programmatic actions (called methods) defined by this class. All actions and characteristics of the protocols of the open control architecture are defined in a class manner. The functional scope of the protocol is equivalent to that of the classes it implements. Energy bank. The collection of classes completely determines what types of objects can be instantiated in a communication device. A protocol defined in this way is called an object-oriented protocol and is defined as follows. a) Class definition. defines the types of objects that can exist in the device; b) Naming and addressing rules. define how to identify objects and their attributes; c) Protocol data unit (PDU) format. specifies the actual format of the transmitted and received data; d) Protocol data unit exchange rules. define the communication sequence used to implement the information exchange (see 4.3). Note. This section is expressed in object-oriented design terminology, but does not require that these protocols be implemented in an object-oriented programming style. Optional object-based implementation Or non-object-based. 4.2.2 Class 4.2.2.1 Overview 4.2.2.1.1 Class Content The classes of the open control architecture should all contain the following. a) collection of elements (attributes, methods and events, see 4.2.2.3); b) a unique class identifier; c) The exact parent class (except the root class, because it has no parent class). Note. Standard class names (see GY/T 322.2-2019) all begin with "Oca". 4.2.2.1.2 Inheritance Open control architecture classes should be defined as nodes in a hierarchical tree structure. The hierarchical tree structure should start with a single base node (root class), It should be in the order of inheritance. Inheritance means that each class derives from a more specific class (parent) with a more specific entity (child) class). A class should exhibit (inherit) all the characteristics of its parent class, unless the original inherited characteristics are explicitly rewritten in the class definition. 4.2.2.1.3 Proprietary In the life cycle of an open control architecture, there are often specific products, especially complex products, that require specialized control Classes, which are not suitable for inclusion in the standard class tree, that is, proprietary classes. This can be achieved with the following four strategies. a) Proprietary classes may inherit from any standard class or another proprietary class; b) proprietary classes should be added to the standard class tree at the most appropriate and explicit level; c) the number of the proprietary class shall be used for the proprietary class; d) Proprietary classes shall be defined in accordance with the inheritance rules listed in 4.2.2.4. 4.2.2.1.4 Include In an open control architecture, a class sometimes contains another class, and the objects of the containing class merge the objects of the class it contains. If you delete an object that contains a class, you should also delete the object of the class that it contains. 4.2.2.1.5 Collection In an open control architecture, a class sometimes collects another class whose objects reference the objects of the class it is collecting. If you delete objects that collect classes, you should not delete objects of the classes that it collects. 4.2.2.2 Class identifier 4.2.2.2.1 Overview The class identifier (class ID) should consist of a pedigree key value and a version number. The class ID is represented as {n; i1 · i2 · i3 ...}, where n is the version number of the class and i1 · i2 · i3 ... is the pedigree key value. 4.2.2.2.2 Pedigree Keys Each class should be identified by a hierarchical key value of the form i1 • i2 • i3 ... A positive non-zero integer value that uniquely identifies the class. i1, i2, i3, etc. are called class indexes. Class index values can be non-contiguous. The pedigree key for each class should consist of a set of class indexes. The class index starts from the root class, extends down through all related subclasses, and ends Restricted to this class, this set of class indexes identifies the complete pedigree of the class. This key can contain as many class indexes as needed for the description level. Example. For a class X with a pedigree key value of 1 • 2 • 12 • 7, the pedigree key value should be interpreted from left to right as follows. 1 indicates the root class. 1 • 2 represents a subclass of the root class. 1 • 2 • 12 indicates that the parent is a child of 1 • 2. 1 • 2 • 12 • 7 represents class X, and its parent class is 1 • 2 • 12. 4.2.2.2.3 Standard Class ID The ID of each class includes a version number that uniquely identifies the revision of the class. Standard IDs should be divided according to GY/T 322.2-2019 With continuous revision, GY/T 322.2-2019 contains new classes and new versions of existing classes. 4.2.2.2.4 Proprietary Class ID The proprietary class ID can be set by the device manufacturer. The manufacturer of the device should be in the Open Control Architecture Device Management Unit (OcaDeviceManager) Identified in the properties of the object. The controller of a device containing a proprietary object should query its corresponding OcaDeviceManager object to obtain the device mechanism Manufacturer information, and take corresponding actions accordingly. Note 1. It is inevitable that two manufacturers use the same private class index value for different objects. If a particular index ik in the proprietary class ID {n; i1 • i2 • i3 ... ik ...} is proprietary, then all indexes to the right of it should also be proprietary. Note 2. According to the above rules, standard classes should not inherit from proprietary classes. Any changes to the proprietary class definition should be identified by a higher class version number. 4.2.2.3 Class properties, methods, and events 4.2.2.3.1 Overview The classes of the open control architecture should have elements that allow access to their data and operational status. The elements of the class are. a) Attributes. The class should define several attributes that represent variables of the class's monitorable parameters and can be accessed by the control network; b) Method. The class should define several methods. These are programs. The controller can be adjusted by protocol commands conforming to the open control architecture. Use these programs to get and change property values, change the running state of the class, and perform other operations; c) Event. The class can define one or more events. Events are callback functions that are fired by the device to notify the controller that a specific event has occurred. number. To receive events, the controller should subscribe to them in advance, see Chapter 6. These elements should be used to define the data exchange protocol between the device and the controller. How the class element is represented in the elements of the communication protocol depends on For each specific protocol that conforms to an open control architecture, see GY/T 322.3-2019. 4.2.2.3.2 Element ID In the class tree, each attribute, method, and event should not only be assigned a name, but also be given a feature ID, such as. LLtNN, which in. LL should be a two-digit class tree hierarchy. For example, the global root class OcaRoot is defined at level 01. OcaRoot subclasses will be defined at level 02. Grandchildren will be defined at level 03. and many more. t should be a type code, with p for attributes, m for methods, and e for events. NN should be the serial number of each type in each class, starting with 01. The value of the feature ID should be unique within each class. Example 1. 01p01 is the first attribute of a class defined on the 01 level of the class tree. In this case, since OcaRoot is the only class of level 01, 01p01 Is the first property of OcaRoot. Example 2. 03m02 is the second method of a class defined on the 03 level of the class tree. Multiple classes are defined on level 03, this ID will apply to the second of any of these classes method. Note 1. The rule for feature IDs is intended to provide a method for uniquely identifying all new and inherited features of any given class, taking into account the future The class tree is expanded at the same level without duplicate identification. Note 2. For an example of this method, see class OcaGain in Appendix A. Note 3. The feature ID can be an attribute ID, a method ID, or an event ID, depending on the type of feature it identifies. 4.2.2.3.3 Protocol Invariance For any given class, the following items should remain the same regardless of which protocol conforms to the open control architecture. a) a collection of attributes, methods and events; b) Feature ID set. 4.2.2.3.4 Text format All text in the properties, method parameters and event parameters of the open control architecture shall be in UTF-8 format (see GB/T 13000-2010). 4.2.2.4 Class inheritance and update rules Inheritance rules ensure that by creating new classes from existing classes, new functionality is added to the protocol in a way that does not affect existing products or system operations. Inheritance ensures that the new child class can support at least the functions and interfaces of its parent class. The class inheritance rules of the open control architecture are. a) Any given class other than the root class should inherit exactly from another class. b) A child class shall implement all properties, methods and events of its parent class. c) The child class can extend the definition of the parent class in the following ways. 1) Add new properties, methods and/or events; 2) Enhance existing definitions of properties, methods and/or events. In this case, the enhanced definition should support the definition by the parent class All functions. d) The methods and events inherited by subclasses shall retain the feature ID corresponding to their parent class. e) Standard classes should not inherit from proprietary classes. When updating existing classes, the following rules apply. a) The class version number should be incremented. b) The updated class should implement all properties, methods, and events of the existing class. c) The updated class can extend the definition of the existing class by. 1) Add new properties, methods and/or events; 2) Enhance the definition of existing properties, methods and/or events. In this case, the enhanced definition should support those defined by existing classes All functions. d) The methods and events of the updated class shall retain the feature ID corresponding to their parent class. 4.2.3 class instantiation As needed to create its network control interface, the device should instantiate the class as an object. Each object shall be identified by a unique object number (ONo). 4.3 Message 4.3.1 Overview Monitoring operations shall be performed by messages in the protocol data unit (PDU). PDU is passed between two objects, which can be different Device. An open control architecture message should be one of three types. a) Command. request the device to return data and/or perform an operation. b) Response. Report success or failure of command execution. If so, the requested data is returned. c) Notification. Report specific events that occur inside the device and provide relevant data. Except for the device reset message (see Chapter 12), the command messages of the open control architecture shall be answered by corresponding response messages. Notice The message should not respond. 4.3.2 Message Distribution Service The open control architecture supports two types of message distribution services. reliable services and fast services. Reliable distribution services should use guaranteed transmission means provided by the network. Reliable services should not be used for multicast. For example, in a TCP/IP network, Reliable services use TCP. Fast distribution services can use lower-overhead, lower-reliability transmission methods. If supported by the network, fast services can be used for multicast. E.g, In TCP/IP networks, fast services use UDP. All command and response messages of the open control architecture should be delivered using a reliable distribution service. Notification messages can use either of the two services What kind of service. The subscription mechanism can use the fast distribution service, see Chapter 6. The device reset mechanism should use the fast distribution service, see Chapter 12. Note. For some types of networks, reliable and fast services may be the same.

5 Equipment model

5.1 Device configurability The configurability of devices conforming to the open control architecture can be divided into fixed, pluggable, partially configurable and fully configurable, see Table 1. Table 1 Configurability Configurability type description Fixed static devices permanently assign object libraries and signal flow topologies... ...