Path:
Home >
GY/T >
Page3 > GY/T 322.2-2019
Price & Delivery
US$299.00 · In stock · Download in 9 secondsGY/T 322.2-2019: Audio applications of networks-open control architecture - Part 2: Class structure
Delivery: 9 seconds. True-PDF full-copy in English & invoice will be downloaded + auto-delivered via email. See
step-by-step procedureStatus: Valid
| Std ID | Version | USD | Buy | Deliver [PDF] in | Title (Description) |
| GY/T 322.2-2019 | English | 299 |
Add to Cart
|
3 days [Need to translate]
|
Audio applications of networks-open control architecture - Part 2: Class structure
|
Click to Preview a similar PDF
Basic data
| Standard ID | GY/T 322.2-2019 (GY/T322.2-2019) |
| Description (Translated English) | Audio applications of networks-open control architecture - Part 2: Class structure |
| Sector / Industry | Radio, Film & TV Industry Standard (Recommended) |
| Classification of Chinese Standard | M60 |
| Word Count Estimation | 13,154 |
| Date of Issue | 2019 |
| Date of Implementation | 2019-04-28 |
| Issuing agency(ies) | State Administration of Radio and Television |
GY/T 322.2-2019: Audio applications of networks-open control architecture - Part 2: Class structure
---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 2. Class Structure)
GY
Radio and Television Industry Standards of the People's Republic of China
Open control architecture for network audio applications
Part 2. Class Structure
Audio applications of networks-open control architecture-
Part 2. Class structure
2019-04-28 released
2019-04-28 Implementation
Published by the State Administration of Radio and Television
Contents
Foreword ... II
Introduction ... III
1 Scope ... 1
2 Normative references ... 1
Class 3 structure ... 1
4 Information Overview ... 1
4.1 Overview ... 1
4.2 Control Class ... 1
4.3 Data types ... 2
4.4 Unit of work class ... 4
4.5 Management Unit Class ... 4
4.6 Agent ... 4
4.7 Control data type ... 5
4.8 Control class construction parameters ... 5
4.9 Control Class and Element Identification ... 5
Appendix A (Normative Appendix) Implementation of the Class Structure of the Minimal Open Control Architecture ... 6
A.1 Overview ... 6
A.2 Open Control Architecture Compatibility ... 6
A.3 Required objects ... 6
A.4 Firmware upgrade ... 7
A.5 Methods and events required by required objects ... 7
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 second part of GY/T 322.
This section is drafted in accordance with the rules given in GB/T 1.1-2009.
This section is compiled with reference to AES70-2-2015 "Open Control Architecture for Network Audio Applications Part 2. Class Structure".
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, and State Administration of Radio and Television
Radio and Television Planning Institute, Jiangsu Provincial Radio and Television General Station, Zhejiang Radio and Television Group, Suzhou Fuchuan Technology Co., Ltd., Beijing YingfuMeidi
Technology Co., Ltd., Beijing Zhonghechuan New Technology Co., Ltd., Hangzhou Union Technology Co., Ltd., Shanghai Baibei Technology Development Co., Ltd.
Company, Beijing Jebsen Century Technology Co., Ltd., and 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 Zhongxuan.
Introduction
This section defines the class structure of an open control architecture for media network monitoring. The class structure defines the contents of the control class.
The content of the class structure is a class defined according to the object-oriented design concept. Each class defines a specific monitoring interface element that can
Access from the entire media network through one or more interactive protocols defined by an open control architecture. Open control architecture controllable equipment can be realized
A collection of such interface elements; these collections constitute the destination interface for remote monitoring provided by the device to the network. Such an interface is called open
The equipment model of the control architecture is defined by GY/T 322.1.
In order to distinguish between the classification structure class and the programmable class, the class of the class structure involved in the open control architecture refers to the "control class", and their examples are
Control object. The control here should be understood as control and monitoring.
The class structure of the open control architecture consists of control classes, control data types, and control class construction parameters.
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
Open control architecture for network audio applications
Part 2. Class Structure
1 Scope
This part of GY/T 322 specifies the class structure of the open control architecture of network audio applications.
This section applies to the control and monitoring of network audio applications.
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 28167-2011 Information Technology XML Metadata Interchange (XMI) (ISO /IEC 19503..2005, IDT)
GY/T 322.1-2019 Open Control Architecture for Network Audio Applications Part 1. Framework
GY/T 322.3-2019 Open Control Architecture for Network Audio Applications Part 3. Protocols for TCP/IP Networks
Class 3 structure
The class structure shall be defined by the Universal Modeling Language (UML) document in XML Metadata Interchange (XMI) 2.1 format defined in GB/T 28167-2011
definition.
For access to related documents, see
Note 1. This XMI machine-readable format is designed to enable implementers to transcribe errors with maximum speed and minimal error compared to independent class models built with traditional text descriptions
Mistake risks directly obtain the class model.
Note 2. The XMI class model can be parsed with appropriate UML applications.
4 Information Overview
4.1 Overview
This chapter briefly describes the class structure of the open control architecture of network audio applications.
4.2 Control class
This section defines the following three control classes, as shown in Table 1.
Table 1 Three types of control
Control functions
Class of work unit responsible for signal processing and monitoring functions
The class of the agent responsible for flow control processing functions
Management unit is responsible for the class of device management functions
The device model of the open control architecture is composed of the objects of the classes in Table 1.
4.3 Data types
This section also provides two sets of supported data type definitions, as shown in Table 2.
Table 2 Supported data types
Data type function
Data types used by control classes
Control class construction parameters are used to build the data type of the control
An overview of the class structure is shown in Figure 1.
Class structure of open control architecture
Control class
Unit of work
Actuator
sensor
(Several)
Blocks and matrices
Network work unit
(Several)
(Several)
Media port
Snap-in
Equipment Management Unit
Security Management Unit
Firmware management unit
Subscription snap-in
Network Management Unit
Power Management Unit
Media Clock Management Unit
Audio processing management unit
Library Management Unit
proxy
Networks and streaming networks
Marshaller
Fade in and fade out unit
Numerical observer
Media clock
Power supply unit
Event processing unit
Controlling data types
Control class construction parameters
(Several)
(Several)
Explanation.
Represents the inheritance relationship. The flat-end object is a subclass of the arrow-end object.
Figure 1 Overview of Class Structures
4.4 Unit of work class
The unit of work class describes the application functions of the device. There are four types of work unit classes, see Table 3.
Table 3 Four classes of work units
Unit of work class function
Actuator signal processing and routing functions
Various monitoring functions of sensors. Such as signal level, gain attenuation, temperature, etc.
Blocks and matrices aggregate objects into classes in a structured collection. For modularization and management of complex structures
Network unit of work manages input and output media streams
For any given device, the work unit class can be instantiated multiple times as needed to simulate the functionality of the device.
When necessary, manufacturers can define subclasses to refine and extend the unit of work class. See GY/T 322.1-2019 for details.
4.5 Management Unit Class
The snap-in class describes device management functions. For each device, the snap-in class is single. That is, each snap-in
Classes can be instantiated only once per device.
A compatible open control architecture should implement part of the management unit class and should be instantiated on each device. The other part of the snap-in class is
Optional. It is not necessary to implement all interface elements of all required classes. Appendix A specifies the minimum equipment requirements for compatibility with open control architectures.
Management unit, see Table 4.
Table 4 Management unit
Snap-in Function
Device management unit contains manufacturer and model information and controls overall device status
The security management unit controls the security function, or reports that it is not available
The firmware management unit is responsible for device firmware updates, or reports unimplemented
The subscription snap-in manages device data reports returned to the controller
The network management unit maintains a collection of device network interfaces, defined by the network objects mentioned in 4.6
Power management unit allows monitoring of device power or power
Media clock management unit provides access to the device's media clock
Audio processing management unit provides global audio processing control parameters
The library management unit controls the creation, management and use of storage parameter sets (presets, patches, etc.)
Device time management unit allows access to the device's calendar clock (if available)
4.6 Agent Class
The proxy class provides significant control features that are not directly related to signal processing. See Table 5 for agent classes.
Table 5 Agent class
Agent functions
OcaNetwork indicates the connection to the control network
OcaStreamNetwork represents control and/or media network connection
OcaStreamConnector represents an OcaStreamNetwork connection point open to external media streams
Table 5 (continued)
Agent functions
OcaGrouper
Supports control aggregation, allowing changes in a single parameter to affect multiple objects. Effects and voltage control in the mixer
Big control
OcaRamper
Provides incremental parameter changes, such as timing fades. It also provides parameter changes that will occur at a specified time in the future.
Changing queue
OcaNumericObserver
Observe a specific parameter and sound an alarm when the parameter reaches a specific value. At the same time, it also supports to the controller regularly
Function to report parameter values (such as meter readings)
OcaNumericObserverList is the same as OcaNumericObserver, but can be used to observe a range of parameters
OcaLibrary provides a range of functions for pre-storing parameter sets in the device and applying presets when needed
OcaMediaClock
Describes an internal or external media clock used by the device. Available in devices that support multiple media clocks
Multiple instantiations
OcaEventHandler describes the controller interface that handles incoming notifications from the controlled device
4.7 Controlling data types
This section defines a series of control data types that are used in the definitions of the classes listed in 4.4, 4.5, 4.6. definition
4.8 Control Class Construction Parameters
Some DSP-based products allow the controller to define its processing topology. The open control architecture refers to such products as configurable devices.
In some configurable devices, the controller can cause new processing objects to be created and deleted. GY/T 322 refers to these devices as fully configurable devices.
When a controller in a fully configurable device creates an object, certain parameters may be required. For example, a controller creates a
Multi-throw switches, which need to specify the number of turns of the switch, and can also add a text label for each throw. Such parameters are called construction parameters.
The number and types of construction parameters are different between different classes, see GY/T 322.3-2019.
The open control architecture does not support the creation of management objects at runtime by fully configurable devices, so these are not included in the construction parameter set.
4.9 Control Class and Element Identification
GY/T 322.1-2019 4.2.2 describes the identification scheme for control classes and elements.
Appendix A
(Normative appendix)
Implementation of the class structure of the smallest open control architecture
A.1 Overview
This appendix specifies the minimum device model that should be implemented for devices that conform to the open control architecture.
In this appendix, a device conforming to the open control architecture is referred to as a device for short, and its device model is called a conforming device model.
A.2 Open Control Architecture Compatibility
Each device shall implement at least the minimum device model elements specified in this appendix, and shall implement at least one protocol consistent with the open control architecture.
Conference. The protocol of the open control architecture is defined by GY/T 322.3-2019.
A.3 Required objects
A.3.1 Overview
This chapter defines the objects required for compatibility.
"Minimum implementation" depends on whether the device supports encrypted command streams (secure) or whether to send and receive digital media streams over the network
(Streaming), or both.
As needed, the device can include optional objects to make some or all of its functions accessible for monitoring from the connected network.
Note. The compatibility of the open control architecture does not require the device to include all the functions of an open control architecture work unit or agent; the manufacturer can choose which
These functions can be controlled via the network.
A.3.2 Required management units
Table A.1 lists the snap-in objects that the device should implement.
Each required object should implement all methods defined by its class. Many of these methods may return "unimplemented" where appropriate
status. See the model specified in Chapter 3.
Table A.1 Required snap-in objects
Snap-in object
Object
Numbering
Equipment required
All flow into safety
OcaDeviceManager 1 ●
OcaSecurityManager 2 ●
OcaFirmwareManager 3 ●
OcaSubscriptionManager 5 ●
OcaNetworkManager 6 ●
OcaMediaClockManager 7 ●
Note. ● indicates the snap-in object required to support the function device.
A.3.3 Required work units
Table A.2 lists the unit of work objects that all devices should implement.
Table A.2 Required Worker Objects
Unit of work object object number
Equipment required
All flow into safety
OcaBlock 100 ●
OcaMediaClock multi-value ●
Note. “●” indicates the unit of work object that is required to support this functional device.
A.3.4 Required agents
The device should implement at least one proxy, a network object. The network object should be an instance in the OcaStreamNetwork class.
Note. Early implementations of the open control architecture can also use the OcaNetwork network object, but this object is deprecated in the new design.
A.4 Firmware upgrade
Devices that do not implement the open control architecture firmware upgrade function should provide a simplified OcaFirmwareManage class to provide device firmware
For the version number of the software part, see B.5.5.
A.5 Methods and events required by required objects
A.5.1 Overview
All methods defined by the required objects shall be represented in the device model. Specific devices that do not implement a method should return NotImplemented
result.
In the following, "all methods and events" refers to all methods and events of the described class, as specified in Chapter 3.
A.5.2 Basic collection
The methods and events that all classes should implement are shown in Table A.3.
Table A.3 Basic collection
Method and event notes
GetLockable (...) Only read-only objects can return False
Lock (...) Use this method only when the object can be locked
Unlock (...) Use this method only when the object can be locked
event PropertyChanged (...)
A.5.3 OcaDeviceManager
When implementing the OcaDeviceManager object, the methods and events that should be implemented are shown in Table A.4.
Table A.4 OcaDeviceManager
Method and event notes
GetDeviceName (...)
GetEnabled (...)
SetEnabled (...)
GetManagers (...)
GetModelDescription (...)
GetModelGUID (...)
GetOcaVersion (...)
GetSerialNumber (...)
GetState (...)
A.5.4 OcaSecurityManager
When implementing the OcaSecurityManager object, all methods and events in the OcaSecurityManager class should be implemented.
A.5.5 OcaFirmwareManager
The OcaFirmwareManager object should implement the GetComponentVersions (...) method for all devices.
For devices using the Open Control Architecture firmware upgrade function, the OcaFirmwareManager object should implement
All other methods and events of the OcaFirmwareManager class.
A.5.6 OcaSubscriptionManager
When implementing the OcaSubscriptionManager object, the methods and events that should be implemented are shown in Table A.5.
Table A.5 OcaSubscriptionManager
Method and event notes
AddSubscription (...)
RemoveSubscription (...)
A.5.7 OcaNetworkManager
The OcaNetworkManager object should implement all methods and events of the OcaNetworkManager class.
A.5.8 OcaMediaClockManager
When the device implements the OcaMediaClockManager object, all methods and events of the OcaMediaClockManager class should be implemented.
A.5.9 OcaBlock
When implementing the OcaBlock object, the methods and events that should be implemented are shown in Table A.6.
Table A.6 OcaBlock
Method and event notes
GetEnabled (...) inherits from OcaWorker
SetEnabled (...) inherits from OcaWorker
GetPorts (...) inherits from OcaWorker
GetMembers (...)
GetMembersRecursive (...)
A.5.10 OcaStreamNetwork and OcaNetwork
When the device implements the OcaStreamNetwork object, all methods and events of the OcaStreamNetwork class should be implemented.
When the device implements the OcaNetwork object, all methods and events of the OcaNetwork class should be implemented.
Note. OcaNetwork is a deprecated class.
A.5.11 OcaMediaClock
When the device implements the OcaMediaClock object, all methods and events of the OcaMediaClock class should be implemented.
People's Republic of China
Radio and television industry standards
Open control architecture for network audio applications
Part 2. Class Structure
Published by the Radio and Television Planning Institute of the State Administration of Radio and Television
Editor-in-chief. Wang Jiamei
No.2 Fuxingmenwai Avenue, Beijing
Phone. (010) 86093424 86092923
Postal code. 100866
Copyright must not be reproduced
...
