GY T 322.1-2019 网络音频应用的开放式控制架构 第 1 部分：框架.pdf

1、 GY 中 华 人 民 共 和 国 广 播 电 视 行 业 标 准 GY/T 322.1 2019 网络 音频 应用的开放式 控制架构 第 1 部分：框架 Audio applications of networks - open control architecture Part 1: Framework 2019 - 04 - 28 发布 2019 - 04 - 28 实施 国家广播电视 总局 发布 GY/T 322.1 2019 I 目 次 前言 . III 引言 . IV 0.1 概述 . IV 0.2 架构目标与约束 . IV 1 范围 . 1 2 规范性引用文件 . 1 3 术语、

2、定义和缩略语 . 1 3.1 术语和定义 . 1 3.2 缩略语 . 1 4 顶层设计 . 2 4.1 概述 . 2 4.2 面向对象 . 2 4.3 消息 . 5 5 设备模型 . 6 5.1 设备的可配置性 . 6 5.2 对象寻址 . 6 5.3 设备模型 . 7 5.4 工作单元类 . 9 5.5 代理类 . 17 5.6 管理单元类 . 23 5.7 标准对象编号 . 23 5.8 对象文本标识 . 23 5.9 构造对象 . 24 5.10 删除对象 . 24 6 事件和订阅 . 24 6.1 订阅、事件、发送器和通知 . 24 6.2 PropertyChanged事件 . 25

3、 6.3 数值观察器的用法 . 25 7 网络系统 . 26 7.1 概述 . 26 7.2 媒体传输连接管理 . 28 7.3 开放式控制架构适配 . 28 8 会话 . 30 9 安全 . 30 GY/T 322.1 2019 II 10 并发控制 . 31 11 可靠性 . 31 11.1 概述 . 31 11.2 可用性 . 32 11.3 鲁棒性 . 32 12 设备复位 . 32 13 固件和软件更新 . 32 13.1 概述 . 32 13.2 更新 类型 . 33 13.3 更新模式 . 33 13.4 更新机制 . 33 附录 A（ 资料性附录 ） 执行器实例 . 35 A.

4、1 概述 . 35 A.2 属性、方法和事件 . 35 附录 B（ 资料性附录 ） 块实例 . 38 B.1 简单传声器通道 . 38 B.2 两通道传声器调音台 . 38 B.3 采用嵌套块的调音台 . 39 附录 C（资料性附录） 网络连接管理示例 . 41 C.1 基于流连接示例 . 41 C.2 基于通道连接示例 . 43 GY/T 322.1 2019 III 前 言 GY/T 322 网络音频应用的开放式控制架构 分为 以下 三 部分： 第 1部分：框架； 第 2部分：类结构； 第 3部分： 用于 TCP/IP网络 的 协议。 本部分为 GY/T 322的第 1部分 。 本 部分

5、按照 GB/T 1.1 2009给出的规则起草。 本部分是参照 AES70-1-2015 网络音频应用的开放式控制架构 第 1部分：框架 编制的 。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本 部分 由全国广播 电影 电视标准化技术委员会 （ SAC/TC 239） 归口。 本部分 起草单位： 中央广播 电视总台 、国家 广播电视 总局广播 电视 科学研究院、 国家 广播电视 总局 广 播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪科技 股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科

6、技发展有限公司、 北京捷成世纪科技股份有限公司、苏州大学。 本部分 主要起草人： 钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董升 来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆 。 GY/T 322.1 2019 IV 引 言 0.1 概述 开放式控制架构 （ OCA） 规定了用于专业媒体网络监控的可扩展的控制协议架构。 开放式控制架构 仅 涉及设备监控，没有定义用于传送流媒体或描述媒体内容的标准。 只要底层的通信网络能够承载 开放式控 制架构 的监控流量，它就可以与任何流媒体传输协议一起使用集成。 开放式控制架构 未提供完整的设备实现模型

7、。 开放式控制架构 建立了设备的监控功能模型，并不包括 其全部的信号路径。如果设备特定部分要素不具备远程可控的特征，则不必在该设备的符合 开放式控制架 构 协议接口中表述。 开放式控制架构 的 第 1部分是参照 AES70-1-2015 网络音频应用的开放式控制架构 第 1部分：框架 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=101下载 。 开放式控制架构的 第 2部分 定义了用于媒体网络监控的开放式控制架构的类结构。 第 2部分是参照 AES70-2-2015 网络音频应用的开放式控制架构 第 2

8、部分：类结构 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=102下载 。 开放式控制架构的 第 3部分是参照 AES70-3-2015 网络音频应用的开放式控制架构 第 3部分： 用于 TCP/IP网络的协议 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=103下载 。 0.2 架构目标与约束 开放式控制架构 基于以下 功能需求 和要求： a) 功能性 开放式控制架构 支持以下功能： 1) 发现与网络连接的 符

9、合 开放式控制架构 的 设备； 2) 对设备间的媒体流路径进行定义或取消定义； 3) 对 符合 开放式控制架构 的 设备进行控制操作和参数配置； 4) 对 符合 开放式控制架构 的 设备进行监测操作和参数配置； 5) 对于具有可重配置信号处理 和 /或控制能力的设备，定义和管理配置参数； 6) 升级受控设备的软件和固件。包括故障安全升级功能。 b) 安全性 开放式控制架构 支持以下对数据控制和监测采取的安全措施： 1) 实体认证； 2) 防窃听； 3) 完整性保护； 4) 新鲜度 这里的 “新鲜度” 是指 对重放攻击中的检测出的重放消息的真实性 。 GY/T 322.1 2019 V c) 可

10、扩展性 开放式控制架构 支持 具有 至少有 10000个应用设备的网络。 开放式控制架构 对设备的物理分布施 行最小限制。 d) 可用性 开放式控制架构 通过提供以下特性来支持高可用性： 1) 对 符合 开放式控制架构 的 设备的设备 管理 ； 2) 对 与 符合 开放式控制架构 的 设备相连的网络进行 管理 ； 3) 在错误和配置更改后，进行高效的网络重新初始化。 e) 鲁棒性 开放式控制架构 通过提供以下特性来支持鲁棒性： 1) 操作确认机制； 2) 处理控制数据丢失的机制； 3) 处理 符合 开放式控制架构 的 设备失效的机制； 4) 网络实施者可使用的网络鲁棒性机制的建议 。 f) 安

11、全标准 开放式控制架构 允许 实现 符合生命安全紧急标准的媒体网络。 g) 兼容性 在 开放式控制架构 的 发展过程中将最大限度地 实现 不同版本之间的兼容性。基于 开放式控制架构 的 一个版本的控 制器将基于下列方式在另一个版本的 符合 开放式控制架构 的 设备上运行： 1) 对 于基于旧版本的设备，新版本的控制器按照与该设备相同版本进行工作； 2) 对于基于更新版本的设备，旧版本的控制器能够 监控 设备中与控制器相同版本的所有功能， 且不妨碍仅在设备版本中定义的功能。 h) 可分析性 开放式控制架构 定义 了 允许访问以下信息的诊断功能： 1) 每个设备的 所有组件 、 硬 件和软件的版本

12、信息； 2) 设备的网络参数 （ 如 MAC地址， IP地址 ） ； 3) 设备状态（包括设备网络接口状态） ； 4) 媒体流参数 （用于 设备的每个 活动的 接收 和 /或发送 媒体流） ； 5) 通信错误 。 GY/T 322.1 2019 1 网络音频应用 的 开放式控制架构 第 1 部分：框架 1 范围 GY/T 322的 本部分规定了网络 音频 应用的开放式控制架构的模型和机制。这些模型和机制共同组成 了 开放式控制架构的框架。 本部分适用于 对 网络音频 应用 的监控 ， 不适用于 传送流媒体或描述媒体内容 。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的

13、引用文件，仅注日期的版本适用于 本文件 。 凡是不注日期的引用文件，其最新版本 (包括所有的修改单 )适用于本文件 。 GB/T 13000 2010 信息技术 通用多八位编码字符集 （ UCS） （ ISO/IEC 10646:2003， IDT） GY/T 322.2 2019 网络音频应用的开放式控制架构 第 2部分：类结构 GY/T 322.3 2019 网络音频应用的开放式控制架构 第 3部分： 用于 TCP/IP网络 的 协议 3 术语、定义和缩略语 3.1 术语和定义 下列术语和定义适用于 本文件 。 3.1.1 控制器 controller 通过一个符合 开放式控制架构 的接口

14、来监控设备的联网的软件单元。 注： 控制器可托管在专用计算机中，也可是运行于某个设备或某些其他环境中的软件单元。 3.1.2 控制协议 control protocol 用于远程监控 网络 设备应用功能的应用协议。 3.2 缩略语 下列缩略语适用于 本文件 。 OCA 开放式控制架构（ Open Control Architecture） GY/T 322.1 2019 2 ONo 对象编号（ Object Number） PDU 协议数据单元 （ Protocol Data Unit） VCA 压控放大器（ Voltage-controlled Amplifier） 4 顶层设计 4.1 概

15、述 开放式控制架构支持在应用层对符合 开放式控制架构 的设备进行监控。它 不提供音视频信号 传输，而 需 与各种音视频信号的传输方案一起集成使用。 开放式控制架构规定 的协议 具有 可扩展 性 ， 可 有序 的 合并 新的设备类型和 设备升级 ，支持各种媒体网 络中的功能的以向上兼容的方式 改进升级 。 开放式控制架构 适用于专业 媒体网络。对 于 不大于 100个节点的简单网络，在使用推荐的交换机时，设 置过程不宜要求技术人员具备高级网络知识 。 具体 要求如下 ： a） 开放式控制架构 的 网络可使用符合工业标准的数据网络设备来运行； b） 符合 开放式控制架构 的设备可与不符合 开放式控

16、制架构 的 设备无害共存； c） 开放式控制架构 的网络可以根据产品及应用的需要，在安全或不安全模式下运行。 4.2 面向对象 4.2.1 概念 开放式控制架构 将通信设备的控制接口描述为对象的集合。每个对象是一个软件单元，它是特定类的 实例化，并具有由该类定义的状态（ 称为属性 ）和程序化动作（称为方法）。 开放式控制架构 的协议的所有动作和特征均以类的方式定义。协议的功能范围相当于它实现的类的功 能库。类的集合完全决定了 通信设备中可实例化 什么类型的对象。 以这种方式定义的协议称为面向对象的协议，定义 如下 ： a） 类定义 ： 定义可存在于设备中的 对象类型； b） 命名和寻址规则 ：

17、 定义如何识别对象及其属性； c） 协议数据单元 （ PDU） 的格式 ： 指定发送和接收数据的实际格式； d） 协议数据单元的交换规则 ： 定义用于实现信息交换的通信序列（见 4.3）。 注： 本部分 以面向对象的设计术语表述 ，但并不要求 使用面向对象的编程风格 实现这些协议。实 现时 可选择基于对象 或非基于对象的方式。 4.2.2 类 4.2.2.1 概述 4.2.2.1.1 类的内容 开放式控制架构 的类均应包含以下内容： a） 要素集合（属性、方法和事件 ， 见 4.2.2.3） ； b） 唯一的类标识符； GY/T 322.1 2019 3 c） 确切 的父类（根类除外，因为它没

18、有父类）。 注： 标准的类名（见 GY/T 322.2 2019） 均 以“ Oca”开头。 4.2.2.1.2 继承 开放式控制架构 的类应定义为层次树结构中的节点。该层次树结构应从单一的基础节点（根类）开始， 并应按继承顺序排列。继承意味着类均从一个特殊性相对较弱的类（父类）派生出的特殊性更强的实体（子 类）。一个类应展示（继承）其父类的所有特征，除非在该类定义中明确重写了原有的继承特征。 4.2.2.1.3 专有类 在 开放式控制架构 的生命周期中，往往会出现特定的产品，尤其是复杂的产品，需要用到专门的控制 类，这些类不适合包含在标准的类树中 ，即专有类 。 可 通过以下四个策略来实现：

19、 a） 专有类可从任何的标准类或另外的专有类 继承； b） 专有类宜以 最恰当明确的层级附加到标准类树中； c） 对专有类应使用专有类的编号； d） 专有类应根 据 4.2.2.4中所列的继承规则定义。 4.2.2.1.4 包含 在 开放式控制架构 中，一个类有时会包含另一个类 ，该 包含类的对象合并了被它包含类的对象。 如果删除包含类的对象， 也 应删除被它包含的类的对象。 4.2.2.1.5 收集 在 开放式控制架构 中，一个类有时会收集另一个类 ，该 收集类的对象 引用了 被它收集类的对象。 如果删除收集类的对象，不应删除被它收集的类的对象。 4.2.2.2 类标识符 4.2.2.2.1

20、 概述 类标识符（类 ID）应由谱系键值和版本号组成。 类 ID表示为 n;i1 i2 i3.，其中 n是类版本号， i1 i2 i3.是谱系键值。 4.2.2.2.2 谱系键值 每个类均应用形如 i1i2i3.的层级键值来标识，其中 i1i2i3.应为类树的特定层级的兄弟节点中 能唯一标识该类的正的非零整数值。 i1， i2， i3等被称为类索引。类索引值可非连续。 每个类的谱系键值均应由一组类索引组成。类索引从根类开始，向下延伸通过所有相关的子类，并结 束于该类，这一组类索引标识了该类的完整谱系。这个键值可以根据描述层级的需要包含足够多的类索引。 示例： 对于谱系键值为 12127的类 X

21、，谱系键值应按如下方式从左到右解释： 1表示根类。 12表示根类的一个子类。 1212表示父类是 12的一个子类。 GY/T 322.1 2019 4 12127表示类 X，其父类为 1212。 4.2.2.2.3 标准类 ID 每个类的 ID包括一个版本号，用于唯一标识类的修订版本。标准类的 ID应依据 GY/T 322.2 2019来分 配， 且通过不断地修订， GY/T 322.2 2019包含新的类以及现有类的新版本。 4.2.2.2.4 专有类 ID 专有类 ID可由设备制造商设置。设备的制造商应在 开放式控制架构设备管理单元 （ OcaDeviceManager） 对象的属性中标识

22、。包含专有对象的设备的控制器宜查询其对应的 OcaDeviceManager对象，以获得设备制 造商信息，并据此作出相应的操作。 注 1： 两个制造商对不同的对象使用相同的专有类的索引值 的现象是不可避免的 。 如果专有类 IDn;i1i2i3 .ik.中某个特定的索引 ik是专有的，则其右侧的所有索引也应是专有的。 注 2： 根据以上规则， 标准类不应从专有类继承。 对专有类定义上的任何更改，应用更高的类版本号来标识。 4.2.2.3 类 的 属性 、 方法 和事件 4.2.2.3.1 概述 开放式控制架构 的 类应具有允许访问其数据和操作状态的要素。类的要素 有 ： a) 属性：类应定义若

23、干属性， 代表 类的 可 监控 参数的变量，并能被控制网络所访问 ； b) 方法：类应定义若干种方法，它们是一些程序，控制器可由符合 开放式控制架构 的协议命令来调 用这些程序去获取和更改属性值、改变类的运行状态以及执行其他的操作； c) 事件：类可以定义一个或多个事件，事件 是 由设备激发以通知控制器发生了特定的事件的回调函 数。为了接收事件，控制器应事先订阅它们 ， 见 第 6章 。 这些要素应用于定义设备和控制器之间的数据交换协议。在通信协议的要素中表示类要素的方式取决 于每个特定的符合 开放式控制架构 的协议， 见 GY/T 322.3 2019。 4.2.2.3.2 要素 ID 在类

24、树中，每个 属性、方法和事件 不仅应分配一个名称，而且还要赋予一个要素 ID，形如： LLtNN，其 中 ： LL应为两位数表示的类树层级。 例如，全局根类 OcaRoot在层级 01定义。 OcaRoot的子类将在层级 02定义。孙类将在层级 03定义。等等。 t应为类型代码 ，用 p表示属性， m表示方法， e表示事件。 NN应为每个类中的每个类型的序列号，起 始值为 01。 在每个类中，要素 ID的值应是唯一的。 示例 1： 01p01 是定义在类树 01 层级上的类的第一个属性。在这种情况下，由于 OcaRoot 是层级 01 的唯一的类，因此 01p01 是 OcaRoot 的第一个

25、属性。 示例 2： GY/T 322.1 2019 5 03m02 是定义在类树的 03 层级上的类的第二个方法。在 03 层级上定义了多个类 ， 此 ID 将适用于任何这些类的第二个 方法。 注 1： 要素 ID 的规则旨在提供一种方法，用于唯一标识任何给定类的所有新增和继承要素的方法，并考虑到将来在不 同层级上对类树进行扩充，同时不会带来标识的重复。 注 2： 关于这种方法的一个例子， 参 见附录 A 中的类 OcaGain。 注 3： 要素 ID 可以是属性 ID，方法 ID 或事件 ID，具体取决于其标识的要素的类型。 4.2.2.3.3 协议不变性 对于任何给定的类，无论使用哪种符合

26、 开放式控制架构 的协议，以下项目应保持不变： a） 属性、方法和事件集合； b） 要 素 ID 集 合。 4.2.2.3.4 文本格式 开放式控制架构 的属性、方法参数和事件参数中的所有文本均应采用 UTF-8格式（见 GB/T 13000 2010）。 4.2.2.4 类 的 继承和更新规则 继承规则确保通过从现有类创建新类，以不影响现有产品或系统操作的方式将新功能添加到协议中。 继承能确保新的子类至少能支持其父类的功能和接口。 开放式控制架构 的类继承规则是： a） 除了根类之外的任何给定类，都应确切地从另一个类继承。 b） 子类应实现其父类所有的属性，方法和事件。 c） 子类可通过以下

27、方式扩充父类的定义： 1) 添加新的属性、方法 和 /或事件 ； 2) 增强现有的属性、方法 和 /或事件的定义。在这种情况下，所增强的定义应支持由父类定义的 所有功能。 d） 子类继承的方法和事件应保留其父类对应的要素 ID。 e） 标准类不应从专有类继承。 当更新现有类时，应遵守以下规则 ： a） 类版本号应递增。 b） 更新的类应实现现有类的所有属性、方法和事件。 c） 更新的类可通过以下方式扩充现有类的定义： 1) 添加新的属性、方法 和 /或事件 ； 2) 增强现有属性、方法 和 /或事件的定义。在这种情况下，所增强的定义应支持由现有类定义的 所有功能。 d） 被更新类的方法和事件应

28、保留其父类对应的要素 ID。 4.2.3 类的实例化 正如创建其网络控制接口所需，设备应将类实例化为对象。每个对象应由唯一的对象编号（ ONo）标识。 4.3 消息 GY/T 322.1 2019 6 4.3.1 概述 监控操作应由协议数据单元（ PDU）中的消息来执行。 PDU在两个对象之间传递， 这两个对象可在不同 设备中。 开放式控制架构 的消息应是以下 三 种类型之一： a) 命令：请求设备返回数据 和 /或执行操作。 b) 应答：报告命令执行成功或失败。如果有，则返回所请求的数据。 c) 通知：报告设备内部发生的特定事件，并提供相关数据。 除了设备复位消息（见第 12章）外， 开放式

29、控制架构 的命令消息均应由对应的应答消息应答。通知消 息不应 响应 。 4.3.2 消息分发服务 开放式控制架构 支持两种消息分发服务：可靠服务和快速服务。 可靠分发服务应使用网络提供的有保证的传输手段。可靠服务不应用于组播。例如，在 TCP/IP网络中， 可靠服务使用 TCP。 快速分发服务可使用较低开销，较低可靠性的传输手段。如果网络支持，快速服务可用于组播。例如， 在 TCP/IP网络中，快速服务使用 UDP。 开放式控制架构 的所有命令和应答消息应使用可靠分发服务来传递。通知消息可使用两种服务中的任 何一种服务。订阅机制可使用快速分发服务，见 第 6章；设备复位机制应使用快速分发服务，

30、见第 12章。 注： 对于某些类型的网络，可靠服务和快速服务可能相同。 5 设备模型 5.1 设备的可配置性 符合 开放式控制架构 的设备的可配置性可分为固定，可插拔，部分可配置和完全可配置， 见 表 1。 表 1 可配置性 可配置性 类型 描述 固定 静态 设备在固件编程时就永久地指配对象库和信号流拓扑 可插拔 静态 当设备离线时，通过插入和拔出硬件模块，调整物理控制，重新加载或重新调整软件或通过其他手动方法，可改变设备的对象库和信号流拓扑 部分可配置 动态 设备在线时，控制器可改变设备的信号流拓扑 完全可配置 动态 在“部分可配置”的基础上，设备在线时，控制器还可创建和删除设备内部对象 固

31、定和可插拔设备称为静态设备，因为控制器不能改变 其 配置项 。部分可配置和完全可配置设备 称为 动态设备， 因为 控制器 可在线改变 其配置项 。 配置管理的详细内容见 5.4.3和 GY/T 322.2 2019。创建和删除对象见 5.9和 5.10。 5.2 对象寻址 GY/T 322.1 2019 7 在符合 开放式控制架构 的设备中，每个对象（即特定类的每个实例化）应由对象编号进行唯一标识。 根据设备的可配置性，对象编号应在不同时刻进行分配，见表 2。 注： 在特定实现中，开发人员可使用特定的对象编号方案来优化设备性能 和 /或简化对象管理。例如，开发者可选择设 备的对象编号值与内部表

32、索引值相对应，以便于对输入命令的快速解码。 表 2 对象编号分配 可配置性 ONo 分配时间刻 固定 设备制造时 可插拔 设备启动时 部分可配置 设备制造时 完全可配置 对象创建时 在完全可配置的设备中，当对象被删除 并 重新创建 ，且设备没有复位 时，对象编号值不能被重新使用。 极端 情况下如果对象编号地址空间耗尽，对象编号值宜从最初值重新开始。 开发设备的人员可以根据需要选择对象编号值，但应遵守以下规则： a) 对象编号应为 32 位整数。 b) 每个对象应有唯一的对象编号。 c) 对象编号不应为 0。 d) 从 01 到 4095 的对象编号值应给管理单元（ 见 5.6）和 其他 需要预

33、定义对象编号的对象保留。它 们应保留用于 开放式控制架构 的标准化。 e) 不同的对象编号不能指向同一个对象。 注： 与一些其他媒体控制协议不同， ONo 不是基于某种分层级的多字段（ ijk.）值。使用简单的 32 位 ONo 值是一 种设计选择，旨在最大限度地提高协议效率，并最大限度地减少解析对象引用、处理命 令响应和管理错误时的设 备开销。 5.3 设备模型 5.3.1 概述 图 1是 开放式控制架构 的设备模型。加框的元素表示对象。这些对象的类的定义 见 GY/T 322.2 2019。 5.3描述 可用类，举出 示 例 和 特有的结构布局。 GY/T 322.1 2019 8 设备管

34、理单元 电源管理单元 安全管理单元 固件管理单元 订阅管理单元 工作单元 网络管理单元 媒体时钟管理单元 音频处理管理单元库管理单元 代理 图 1 开放式控制架构 的 设备模型 5.3.2 管理单元、工作单元和代理 开放式控制架构 的设备模型包含如下三类对象： a) 管理单元 ：该 对象应是控制对象，它影响或报告设备的基本属性和总体状态。在每个设备中，每 种管理单元类只应有一个实例（即一个设备管理单元，一个安全管理单元等）。每个管理单元应 有一个标准对象编号。 部分管理单元是 必需的 ，其他是可选的 ， 见 5.6和 GY/T 322.2 2019。 b) 工作单元 ：该 对象应直接控制设备的

35、应用功能 ， 见 5.4。包括：音频静音开关，增益控制，均衡 器，电平监测，过载监测器 ， 视频摄像机控制，信号属性，图像处理参数和信号处理功能等。工 作单元 应按 表 3分类 。 表 3 工 作单元 类型 类型 功能 执行器 控制应用功能 (例如：开关 ) 传感器 检测信号参数和 其他 数值 ，并将其 报告给控制器 块及块工厂 允许将相关对象组合成集合 矩阵 允许将对象集合作为二维数组来寻址处理 网络 描述数字网络连接特性 GY/T 322.1 2019 9 c) 代理 ：该 对象应提供对 同一 设备中工作单元的间接控制。代理不应映射信号处理功能，但可影响 一个或多个相关联的工作单元对象的信

36、号处理参数，或提供其他应用控制功能。 代理的详细描述 见 5.5。 示例 ： 名字为 OcaGrouper的代理以类似于模拟系统中压控放大器分组的方式实现控制参数的复杂分组。 这三 类对象 中所有类的详细定义见 GY/T 322.2 2019。 5.4 工作单元类 5.4.1 执行器 执行器应控制设备内的信号处理和常规处理功能。执行器类 见 GY/T 322.2 2019。示例参见附录 A。 在任何设备中，任何执行器类可根据 控制 应用功能的需要进行多次实例化。 执行器 示例见表 4。 表 4 执行器示例 执行器类 功能 OcaGain 控制增益的功能 参见附录 A OcaMute 控制信号静音的功能 OcaSwitch 控制多掷 开关 OcaFilterParametric 控制 参数 均衡器区段 OcaDelay 控制信号延时 OcaDynamics 控制限幅器、压缩器、门控器或扩展器 OcaTemperatureActuator 控制温度设置 5.4.2 传感器 传感器应检测一些参数值并回传给控制器。传感器类在 G