Powered by Google-Search & Google-Books Chinese Standards Shop Database: 169760 (Jul 4, 2020)
HOME  COVID-19   Quotation   Tax   Examples Standard-List   Contact-Us   View-Cart


Chinese Standard: 'GYT322.1-2019'
Standard IDContents [version]USDSTEP2[PDF] delivered inStandard Title (Description)StatusRelated Standard
GY/T 322.1-2019English1039 Add to Cart Days<=8 Audio applications of networks-open control architecture - Part 1: Framework Valid GY/T 322.1-2019
GY/T 322.1-2019Chinese35 Add to Cart <=1-day [PDF from Chinese Authority, or Standard Committee, or Publishing House]  

 GYT322.1-2019 -- Click to view similar PDF/Books...  

Standard ID GY/T 322.1-2019 (GY/T322.1-2019)
Description (Translated English) (Open control architecture for network audio applications Part 1: Framework)
Sector / Industry Radio, Film & TV Industry Standard (Recommended)
Word Count Estimation 51,515
Date of Issue 2019-04-28
Date of Implementation 2019-04-28
Regulation (derived from) Natural Resources Department Announcement No. 7 of 2019

GY/T 322.1-2019
(Open control architecture for network audio applications Part 1. Framework)
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
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
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.
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.
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.
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 Overview Class Content
The classes of the open control architecture should all contain the following.
a) collection of elements (attributes, methods and events, see;
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". 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. 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 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. 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. Class identifier 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. 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.
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. 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. 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. Class properties, methods, and events 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. 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
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
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. 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. 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). 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 during firmware programming
Pluggable static
When the device is offline, insert and remove hardware modules, adjust physical controls, reload or readjust
Software or other manual methods to change the object library and signal flow topology of the device
When some configurable dynamic devices are online, the controller can change the signal flow topology of the device
Fully configurable dynamically On a "partially configurable" basis, the controller can also create and delete internal objects of the device when the device is online
Fixed and pluggable devices are called static devices because the controller cannot change its configuration items. Partially configurable and fully configurable devices are called
Dynamic devices because the controller can change its configuration items online.
For details of configuration management, see 5.4.3 and GY/T 322.2-2019. See 5.9 and 5.10 for creating and deleting objects.
5.2 Object addressing
In devices that conform to the open control architecture, each object (that is, every instantiation of a particular class) should be uniquely identified by an object number.
According to the configurability of the device, the object number should be assigned at different times, see Table 2.
Note. In a specific implementation, developers can use a specific object numbering scheme to optimize device performance and/or simplify object management. For example, developers can choose
The prepared object number value corresponds to the internal table index value to facilitate fast decoding of the input command.
Table 2 Object number assignment
Configurability ONo allocation time tick
When manufacturing fixed equipment
When the pluggable device starts
When some configurable equipment is manufactured
Fully configurable when created
In a fully configurable device, when an object is deleted and recreated, and the device is not reset, the object number value cannot be reused.
In extreme cases, if the object number address space is exhausted, the object number value should be restarted from the original value.
The person developing the device can choose the object number value as needed, but should follow the rules below.
a) The object number shall be a 32-bit integer.
b) Each object shall have a unique object number.
c) The object number should not be zero.
d) Object number values from 01 to 4095 shall be reserved for the management unit (see 5.6) and other objects requiring a predefined object number. it
We should retain standardization for open control architectures.
e) Different object numbers cannot point to the same object.
Note. Unlike some other media control protocols, ONo is not based on some hierarchical multi-field (i • j • k ...) value. Simple 32-bit ONo value is one
This design choice is designed to maximize the efficiency of the protocol and to minimize the design of parsing object references, handling command responses, and managing errors.
Equipment overhead.
5.3 Equipment model
5.3.1 Overview
Figure 1 is a device model of an open control architecture. Framed elements represent objects. The definitions of these object classes are given in GY/T 322.2-2019.
5.3 Describe the available classes, give examples and specific structural layouts.
Equipment Management Unit
Power Management Unit
Security Management Unit
Firmware snap-in subscription snap-in
Unit of work
Network Management Unit
Media clock management unit Audio processing management unit Library management unit
Figure 1 Device model of open control architecture
5.3.2 Management units, work units and agents
The device model of the open control architecture includes the following three types of objects.
a) Management unit. This object should be a control object that affects or reports the basic attributes and overall status of the device. In every device, every
There should be only one instance of this type of management unit (ie, a device management unit, a security management unit, etc.). Each snap-in shall
There is a standard object number. Some management units are required, others are optional, see 5.6 and GY/T 322.2-2019.
b) Unit of work. This object shall directly control the application functions of the equipment, see 5.4. Includes. Audio mute switch, gain control, equalization
Monitor, level monitor, overload monitor, video camera control, signal properties, image processing parameters and signal processing functions. work
The operating unit should be classified according to Table 3.
Table 3 Units of work
Type function
Actuator controls application functions (eg switches)
The sensor detects signal parameters and other values and reports them to the controller
Blocks and block factories allow related objects to be combined into collections
Matrix allows addressing a collection of objects as a two-dimensional array
Network description digital network connection characteristics
c) Agent. This object shall provide indirect control of the unit of work in the same equipment. Agents should not map signal processing functions, but can affect
Signal processing parameters for one or more associated work unit objects, or provide other application control functions. Detailed description of the agent
See 5.5.
The agent named OcaGrouper implements complex grouping of control parameters in a manner similar to the grouping of voltage controlled amplifiers in analog systems.
See GY/T 322.2-2019 for detailed definitions of all classes in these three types of objects.
5.4 Unit of work class
5.4.1 Actuator
The actuator shall control signal processing and general processing functions within the equipment. For actuators, see GY/T 322.2-2019. See Appendix A for examples.
In any device, any actuator class can be instantiated as many times as needed to control application functionality.
Examples of actuators are shown in Table 4.
Table 4 Examples of actuators
Actuator-like functions
OcaGain control gain function-see Appendix A
OcaMute control signal mute function
OcaSwitch controls multi-throw switch
OcaFilterParametric control parameter equalizer section
OcaDelay control signal delay
OcaDynamics controls limiters, compressors, gaters or expanders
OcaTemperatureActuator controls temperature settings
5.4.2 Sensor
The sensor should detect some parameter values and return them to the controller. The sensor class is defined in GY/T 322.2-2019. See Table 5 for sensor examples.
Table 5 Sensor examples
Sensor functions
OcaLevelSensor detects signal level
OcaAudioLevelSensor uses the average and trace of a standard VU or PPM meter to detect audio signal levels
OcaTemperatureSensor detects temperature
Sensor values can be used periodically or conditionally (for example, when it exceeds a defined threshold) using OcaNumericObserver
Agents (see 5.5.5 and 6.3) transfer automatically.
5.4.3 Block Overview
A block should be a specific type of unit of work that can contain unit of work objects (including other block objects) and/or proxy objects. Blocks are also available
Describe the signal flow topology between the units of work it contains. For definitions of standard block classes, see GY/T 322.2-2019.
Objects within a block are called members of the block. The block that contains an object is called the container of that object. Blocks can be nested at any depth.
Any unit of work and agent should be a member of a block. Each device should contain at least one block called a root block, which should contain the
All units of work and agents of the device. In simple devices, all units of work and agents can belong to the root block. In complex equipment,
Units and agents can be deployed into nested blocks.
Snap-in objects should not belong to blocks.
Each block should be described by a class (block class). The root class of all block classes should be OcaBlock.
Note 1. A block is an abstract container that makes minimal assumptions about device structure and control flow. There is no pre-limitation of what block types a block can contain, and there is no
Assume what kind of objects a block can contain. The device can arbitrarily set blocks or only root blocks.
Note 2. The intended use of the block includes.
a) Provide enumeration function (see;
b) store signal flow information (see;
c) support library functions (see 5.5.6);
d) For reconfigurable devices, allows creation and deletion of objects and signal paths, and provides an organizational mechanism for creating and deleting aggregate processing functions (see
5.9). Block enumeration
The set of units of work and agents contained in a block is called the object set of the block. The member list of an object set is called the object list.
OcaBlock should provide a method to retrieve a list of objects for any specified block. The device should also be given the option to enumerate only directly contained objects,
Or recursively enumerate all directly contained objects and all objects in nested blocks at any level.
Note. In order to discover each unit of work object in the device, the controller only needs to request a recursive enumeration of the root block. Block management
Fully configurable devices allow the creation, modification and deletion of blocks. The open control architecture defines the functions that the controller can use to implement these functions
Deleting a block should delete all objects it contains.
See 5.9 for object and block creation. Block and object addressing
Object addressing should be handled strictly according to the object number.
Note 1. The open control architecture does not define a block-based hierarchical object addressing scheme.
Note 2. If required, the manufacturer is free to choose the value of the object number used to represent the device block structure. This choice is beyond the scope of open control architecture. Block and control aggregation
Blocks should not aggregate control functions such as linkage, grouping, or mastering.
Note. The aggregation of control functions of the open control architecture is provided by the OcaGrouper class. OcaGrouper's mechanism has nothing to do with block boundaries, and fully supports partial repetition
For stacking functions, see 5.5.3. Signal flow Port
Each unit of work object can contain one or more ports to define the signal flow. Ports are used by units of work when implementing processing functions
A data element that describes an input or output signal channel.
The input port should indicate the signal flow into the processing function; the output port should indicate the signal flow out of the processing function.
Note. This section uses objects that represent signal processing functions to describe those signal connections between signal processing functions. For example, to represent the place described from object A
The signal connection from the processing function to the processing function described by object B will be written as "signal connection from object A to object B". Block port
A block is a unit of work and therefore can have ports. Such ports are called block ports. The block port should be used as an intermediary port, its existence is used for
Define the signal connection points between objects inside the block and objects outside the block, as shown in Figure 2.
Root block
Internal path
This path
For root blocks
Internal road
External path
Note. In the figures in this section, the small circles represent the ports of the object, the large circles represent the ports of the block, the lines represent the signal path, the rounded boxes represent the blocks, and the right-angle boxes
Figure 2 Signal flow
The input port of the block should be the connection point where the signal enters the block. For objects within a block, the input port of the block should appear as a signal source.
The block output port should be the connection point for signals leaving the block. For objects within a block, the output port of the block should behave as a signal receiver.
The internal signal path is the signal path between two objects in the same block. The external signal path is the signal between two objects in different blocks
No. path, as shown in Figure 2. Signal path
The signal path should represent the connection between a specific output port and a specific input port within the same device. Signal path input and output ports
Can be in different objects or in the same object. Signal paths between objects in different blocks may or may not include block ports.
Note. Although the use of block ports is not mandatory, the use of block ports is encouraged. The open control architecture allows direct connection of objects in different blocks. Block signal flow
The signal flow of a block shall include a collection of all signal paths with at least one end within the block. A list of signal paths in a signal flow is called a signal flow
The signal flow of the block should not include signal paths that extend from the block port to other ports outside the block. Such paths belong to the block that contains them as a whole.
In simple cases, this block is the root block.
A media transmission connection between a device and another device should not be considered as part of the device signal flow. See media connections between devices
OcaBlock should provide a method to retrieve a list of signal flows for any given block. The following options should be provided. only enumerate directly included signal paths,
Or recursively enumerate all directly contained signal paths and all signal paths in any level of nested blocks.
Figure 2 shows a typical signal flow. Example
See Appendix B for examples of blocks and signal flows. Block Factory
In a fully configurable device, the controller should be able to build blocks, assemble the blocks with objects, and then connect signal paths between these objects.
These basic mechanisms are done by the block factory.
A block factory should be a unit of work whose job is to build fully assembled and "wired" blocks. Each block factory should be
An instance of the OcaBlockFactory class, which has been configured to construct a specific type of block with a predefined set of objects and signal paths.
Note. A block factory is useful when the controller must create multiple blocks of the same type.
A block factory should be a container for object prototypes and signal flow prototypes that it implements when building each block.
The open control architecture provides the following two methods for creating a block factory.
a) One or more block factories can be defined when the device is manufactured or when the pluggable device is started. In this case, these block factories should report to the control
The controller provides predetermined instantiable block type instructions.
b) Controllers can create block factories, which use specific commands of the open control architecture to define the configuration of the blocks they will create. At this
In this case, the controller should be free to define new block types that will be instantiated later.
Depending on the device type, one or both of these two methods of creating a block factory can be implemented. Creating Blocks Without a Block Factory
The controller can create an block by instantiating an object of the OcaBlock class without using a block factory. In this case, you need to send a command to the device to create the block.
And connect the specific objects inside this new block. The OcaBlock class should provide the necessary methods.
5.4.4 Matrix Overview
The matrix involved in the open control architecture should be a generalization of the cross-node audio matrix concept. The matrix of open control architecture is the same job
A rectangular array of cells. These work cells share one or more common input and output buses on rows and columns, respectively. Matrix addressing
Matrix elements should be addressed by coordinates. The open control architecture uses (x, y) coordinates, where x is the horizontal (column) number and y is the vertical (row)
Number, as shown in Figure 3.
(1,1) (2,1)
(1,2) (2,2)
(1,3) (2,3)
(1,1) (2,1)
(1,2) (2,2)
(1,3) (2,3)
1 input corresponds to 1 output
1 input corresponds to 3 outputs
Figure 3 Matrix of open control architecture
Coordinate values should range from 1 to the number of rows or columns.
The special value 0 should be used to represent the entire row or column. So, for example, (0,2) means the entire second line. The use of this feature will be demonstrated in
Show. Complex Matrix
If the working unit in the matrix is a switch, the matrix can be represented as a regular switch matrix. If the working unit is gain control, the moment
The matrix can represent a regular mixing matrix. In an open control architecture, the unit of work of a matrix can be any class, even a block.
For example, FIG. 4 shows a block matrix in which each block is shown in FIG. 5.
Note. "M" in the figure means mute, "G" means gain, "E" means equalizer, and "D" means delay.
Figure 4 Matrix of complex elements
Silent Gain Equalizer Delay
Figure 5 Complex matrix elements Matrix structure
The matrix should be an instance of the OcaMatrix class, but the instance should not contain units of work that make up all or part of the matrix elements. Matrix elements should
Instantiated separately and identified as members of the matrix. Their classes are called member classes of the matrix. In short, the matrix should collect its members,
Without including them.
All members of the matrix should be of the same class and instantiated on the same device as the matrix.
In addition to the matrix and its members, the matrix should contain an additional instance of a member class called a matrix proxy. The controller should use matrix generation
Managers access the settings of matrix members by coordinates.
The complete matrix is shown in Figure 6.
Matrix proxy
Controller (s)
Member member
(x, y)
Figure 6 Matrix structure Accessing matrix elements
The controller should use the two methods SetCurrentXY (x, y) and SetCurrentXYLock (x, y) to access the matrix members of (x, y) coordinates.
a) The controller should call the SetCurrentXY (x, y) or SetCurrentXYLock (x, y) method of OcaMatrix to specify the target coordinates
set. If SetCurrentXYLock (x, y) is called, OcaMatrix should lock the matrix element addressed.
b) The controller shall call the Get or Set methods of one or more matrix agents for the required attributes. If Get is called, the attribute should be returned
The current value of sex. If Set is called, the new value of the property should be set.
If SetCurrentXYLock (x, y) is called in step a), the controller should call OcaMatrix's Unlock (x, y) method to solve
The matrix element to which the lock is addressed.
The special values x = 0 and y = 0 can be used to specify aggregate set operations, see Table 6.
Table 6 SetCurrentXY ...
Related standard:   GY/T 322.2-2019  GY/T 322.3-2019
Privacy   ···   Product Quality   ···   About Us   ···   Refund Policy   ···   Fair Trading   ···   Quick Response
Field Test Asia Limited | Taxed in Singapore: 201302277C | Copyright 2012-2020