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

GY

中华人民共和国广播电视行业标准

GY/T322.1—2019

网络音频应用的开放式控制架构

第1部分：框架

Audioapplicationsofnetworks-opencontrolarchitecture—

Part1:Framework

2019-04-28发布2019-04-28实施

国家广播电视总局发布

GY/T322.1—2019

目次

前言...............................................................................III

引言................................................................................IV

0.1概述.........................................................................IV

0.2架构目标与约束...............................................................IV

1范围..............................................................................1

2规范性引用文件....................................................................1

3术语、定义和缩略语................................................................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.2PropertyChanged事件..........................................................25

6.3数值观察器的用法.............................................................25

7网络系统.........................................................................26

7.1概述.........................................................................26

7.2媒体传输连接管理.............................................................28

7.3开放式控制架构适配...........................................................28

8会话.............................................................................30

9安全.............................................................................30

I

GY/T322.1—2019

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.1概述..........................................................................35

A.2属性、方法和事件..............................................................35

附录B（资料性附录）块实例.........................................................38

B.1简单传声器通道................................................................38

B.2两通道传声器调音台............................................................38

B.3采用嵌套块的调音台............................................................39

附录C（资料性附录）网络连接管理示例...............................................41

C.1基于流连接示例................................................................41

C.2基于通道连接示例..............................................................43

II

GY/T322.1—2019

前言

GY/T322《网络音频应用的开放式控制架构》分为以下三部分：

——第1部分：框架；

——第2部分：类结构；

——第3部分：用于TCP/IP网络的协议。

本部分为GY/T322的第1部分。

本部分按照GB/T1.1—2009给出的规则起草。

本部分是参照AES70-1-2015《网络音频应用的开放式控制架构第1部分：框架》编制的。

请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。

本部分由全国广播电影电视标准化技术委员会（SAC/TC239）归口。

本部分起草单位：中央广播电视总台、国家广播电视总局广播电视科学研究院、国家广播电视总局广

播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪科技

股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限公司、

北京捷成世纪科技股份有限公司、苏州大学。

本部分主要起草人：钱岳林、朱峰、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董升

来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆。

III

GY/T322.1—2019

引言

0.1概述

开放式控制架构（OCA）规定了用于专业媒体网络监控的可扩展的控制协议架构。开放式控制架构仅

涉及设备监控，没有定义用于传送流媒体或描述媒体内容的标准。只要底层的通信网络能够承载开放式控

制架构的监控流量，它就可以与任何流媒体传输协议一起使用集成。

开放式控制架构未提供完整的设备实现模型。开放式控制架构建立了设备的监控功能模型，并不包括

其全部的信号路径。如果设备特定部分要素不具备远程可控的特征，则不必在该设备的符合开放式控制架

构协议接口中表述。

开放式控制架构的第1部分是参照AES70-1-2015《网络音频应用的开放式控制架构第1部分：框架》

编制的，英文原文可从/publications/standards/search.cfm?docID=101下载。

开放式控制架构的第2部分定义了用于媒体网络监控的开放式控制架构的类结构。第2部分是参照

AES70-2-2015《网络音频应用的开放式控制架构第2部分：类结构》编制的，英文原文可从

/publications/standards/search.cfm?docID=102下载。

开放式控制架构的第3部分是参照AES70-3-2015《网络音频应用的开放式控制架构第3部分：用于

TCP/IP网络的协议》编制的，英文原文可从

/publications/standards/search.cfm?docID=103下载。

0.2架构目标与约束

开放式控制架构基于以下功能需求和要求：

a)功能性

开放式控制架构支持以下功能：

1)发现与网络连接的符合开放式控制架构的设备；

2)对设备间的媒体流路径进行定义或取消定义；

3)对符合开放式控制架构的设备进行控制操作和参数配置；

4)对符合开放式控制架构的设备进行监测操作和参数配置；

5)对于具有可重配置信号处理和/或控制能力的设备，定义和管理配置参数；

6)升级受控设备的软件和固件。包括故障安全升级功能。

b)安全性

开放式控制架构支持以下对数据控制和监测采取的安全措施：

1)实体认证；

2)防窃听；

3)完整性保护；

4)新鲜度—这里的“新鲜度”是指对重放攻击中的检测出的重放消息的真实性。

IV

GY/T322.1—2019

c)可扩展性

开放式控制架构支持具有至少有10000个应用设备的网络。开放式控制架构对设备的物理分布施

行最小限制。

d)可用性

开放式控制架构通过提供以下特性来支持高可用性：

1)对符合开放式控制架构的设备的设备管理；

2)对与符合开放式控制架构的设备相连的网络进行管理；

3)在错误和配置更改后，进行高效的网络重新初始化。

e)鲁棒性

开放式控制架构通过提供以下特性来支持鲁棒性：

1)操作确认机制；

2)处理控制数据丢失的机制；

3)处理符合开放式控制架构的设备失效的机制；

4)网络实施者可使用的网络鲁棒性机制的建议。

f)安全标准

开放式控制架构允许实现符合生命安全紧急标准的媒体网络。

g)兼容性

在开放式控制架构的发展过程中将最大限度地实现不同版本之间的兼容性。基于开放式控制架构

的一个版本的控制器将基于下列方式在另一个版本的符合开放式控制架构的设备上运行：

1)对于基于旧版本的设备，新版本的控制器按照与该设备相同版本进行工作；

2)对于基于更新版本的设备，旧版本的控制器能够监控设备中与控制器相同版本的所有功能，

且不妨碍仅在设备版本中定义的功能。

h)可分析性

开放式控制架构定义了允许访问以下信息的诊断功能：

1)每个设备的所有组件、硬件和软件的版本信息；

2)设备的网络参数（如MAC地址，IP地址）；

3)设备状态（包括设备网络接口状态）；

4)媒体流参数（用于设备的每个活动的接收和/或发送媒体流）；

5)通信错误。

V

GY/T322.1—2019

网络音频应用的开放式控制架构

第1部分：框架

1范围

GY/T322的本部分规定了网络音频应用的开放式控制架构的模型和机制。这些模型和机制共同组成了

开放式控制架构的框架。

本部分适用于对网络音频应用的监控，不适用于传送流媒体或描述媒体内容。

2规范性引用文件

下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。

凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。

GB/T13000—2010信息技术通用多八位编码字符集（UCS）（ISO/IEC10646:2003，IDT）

GY/T322.2—2019网络音频应用的开放式控制架构第2部分：类结构

GY/T322.3—2019网络音频应用的开放式控制架构第3部分：用于TCP/IP网络的协议

3术语、定义和缩略语

3.1术语和定义

下列术语和定义适用于本文件。

3.1.1

控制器controller

通过一个符合开放式控制架构的接口来监控设备的联网的软件单元。

注：控制器可托管在专用计算机中，也可是运行于某个设备或某些其他环境中的软件单元。

3.1.2

控制协议controlprotocol

用于远程监控网络设备应用功能的应用协议。

3.2缩略语

下列缩略语适用于本文件。

OCA开放式控制架构（OpenControlArchitecture）

1

GY/T322.1—2019

ONo对象编号（ObjectNumber）

PDU协议数据单元（ProtocolDataUnit）

VCA压控放大器（Voltage-controlledAmplifier）

4顶层设计

4.1概述

开放式控制架构支持在应用层对符合开放式控制架构的设备进行监控。它不提供音视频信号传输，而

需与各种音视频信号的传输方案一起集成使用。

开放式控制架构规定的协议具有可扩展性，可有序的合并新的设备类型和设备升级，支持各种媒体网

络中的功能的以向上兼容的方式改进升级。

开放式控制架构适用于专业媒体网络。对于不大于100个节点的简单网络，在使用推荐的交换机时，设

置过程不宜要求技术人员具备高级网络知识。具体要求如下：

a）开放式控制架构的网络可使用符合工业标准的数据网络设备来运行；

b）符合开放式控制架构的设备可与不符合开放式控制架构的设备无害共存；

c）开放式控制架构的网络可以根据产品及应用的需要，在安全或不安全模式下运行。

4.2面向对象

4.2.1概念

开放式控制架构将通信设备的控制接口描述为对象的集合。每个对象是一个软件单元，它是特定类的

实例化，并具有由该类定义的状态（称为属性）和程序化动作（称为方法）。

开放式控制架构的协议的所有动作和特征均以类的方式定义。协议的功能范围相当于它实现的类的功

能库。类的集合完全决定了通信设备中可实例化什么类型的对象。

以这种方式定义的协议称为面向对象的协议，定义如下：

a）类定义：定义可存在于设备中的对象类型；

b）命名和寻址规则：定义如何识别对象及其属性；

c）协议数据单元（PDU）的格式：指定发送和接收数据的实际格式；

d）协议数据单元的交换规则：定义用于实现信息交换的通信序列（见4.3）。

注：本部分以面向对象的设计术语表述，但并不要求使用面向对象的编程风格实现这些协议。实现时可选择基于对象

或非基于对象的方式。

4.2.2类

概述

.1类的内容

开放式控制架构的类均应包含以下内容：

a）要素集合（属性、方法和事件，见）；

b）唯一的类标识符；

2

GY/T322.1—2019

c）确切的父类（根类除外，因为它没有父类）。

注：标准的类名（见GY/T322.2—2019）均以“Oca”开头。

.2继承

开放式控制架构的类应定义为层次树结构中的节点。该层次树结构应从单一的基础节点（根类）开始，

并应按继承顺序排列。继承意味着类均从一个特殊性相对较弱的类（父类）派生出的特殊性更强的实体（子

类）。一个类应展示（继承）其父类的所有特征，除非在该类定义中明确重写了原有的继承特征。

.3专有类

在开放式控制架构的生命周期中，往往会出现特定的产品，尤其是复杂的产品，需要用到专门的控制

类，这些类不适合包含在标准的类树中，即专有类。可通过以下四个策略来实现：

a）专有类可从任何的标准类或另外的专有类继承；

b）专有类宜以最恰当明确的层级附加到标准类树中；

c）对专有类应使用专有类的编号；

d）专有类应根据中所列的继承规则定义。

.4包含

在开放式控制架构中，一个类有时会包含另一个类，该包含类的对象合并了被它包含类的对象。

如果删除包含类的对象，也应删除被它包含的类的对象。

.5收集

在开放式控制架构中，一个类有时会收集另一个类，该收集类的对象引用了被它收集类的对象。

如果删除收集类的对象，不应删除被它收集的类的对象。

类标识符

.1概述

类标识符（类ID）应由谱系键值和版本号组成。

类ID表示为{n;i1·i2·i3...}，其中n是类版本号，i1·i2·i3...是谱系键值。

.2谱系键值

每个类均应用形如i1•i2•i3...的层级键值来标识，其中i1•i2•i3...应为类树的特定层级的兄弟节点中

能唯一标识该类的正的非零整数值。i1，i2，i3等被称为类索引。类索引值可非连续。

每个类的谱系键值均应由一组类索引组成。类索引从根类开始，向下延伸通过所有相关的子类，并结

束于该类，这一组类索引标识了该类的完整谱系。这个键值可以根据描述层级的需要包含足够多的类索引。

示例：

对于谱系键值为1•2•12•7的类X，谱系键值应按如下方式从左到右解释：

1表示根类。

1•2表示根类的一个子类。

1•2•12表示父类是1•2的一个子类。

3

GY/T322.1—2019

1•2•12•7表示类X，其父类为1•2•12。

.3标准类ID

每个类的ID包括一个版本号，用于唯一标识类的修订版本。标准类的ID应依据GY/T322.2—2019来分

配，且通过不断地修订，GY/T322.2—2019包含新的类以及现有类的新版本。

.4专有类ID

专有类ID可由设备制造商设置。设备的制造商应在开放式控制架构设备管理单元（OcaDeviceManager）

对象的属性中标识。包含专有对象的设备的控制器宜查询其对应的OcaDeviceManager对象，以获得设备制

造商信息，并据此作出相应的操作。

注1：两个制造商对不同的对象使用相同的专有类的索引值的现象是不可避免的。

如果专有类ID{n;i1•i2•i3...ik...}中某个特定的索引ik是专有的，则其右侧的所有索引也应是专有的。

注2：根据以上规则，标准类不应从专有类继承。

对专有类定义上的任何更改，应用更高的类版本号来标识。

类的属性、方法和事件

.1概述

开放式控制架构的类应具有允许访问其数据和操作状态的要素。类的要素有：

a)属性：类应定义若干属性，代表类的可监控参数的变量，并能被控制网络所访问；

b)方法：类应定义若干种方法，它们是一些程序，控制器可由符合开放式控制架构的协议命令来调

用这些程序去获取和更改属性值、改变类的运行状态以及执行其他的操作；

c)事件：类可以定义一个或多个事件，事件是由设备激发以通知控制器发生了特定的事件的回调函

数。为了接收事件，控制器应事先订阅它们，见第6章。

这些要素应用于定义设备和控制器之间的数据交换协议。在通信协议的要素中表示类要素的方式取决

于每个特定的符合开放式控制架构的协议，见GY/T322.3—2019。

.2要素ID

在类树中，每个属性、方法和事件不仅应分配一个名称，而且还要赋予一个要素ID，形如：LLtNN，其

中：

LL应为两位数表示的类树层级。

例如，全局根类OcaRoot在层级01定义。OcaRoot的子类将在层级02定义。孙类将在层级03定义。等等。

t应为类型代码，用p表示属性，m表示方法，e表示事件。

NN应为每个类中的每个类型的序列号，起始值为01。

在每个类中，要素ID的值应是唯一的。

示例1：

01p01是定义在类树01层级上的类的第一个属性。在这种情况下，由于OcaRoot是层级01的唯一的类，因此01p01

是OcaRoot的第一个属性。

示例2：

4

GY/T322.1—2019

03m02是定义在类树的03层级上的类的第二个方法。在03层级上定义了多个类，此ID将适用于任何这些类的第二个

方法。

注1：要素ID的规则旨在提供一种方法，用于唯一标识任何给定类的所有新增和继承要素的方法，并考虑到将来在不

同层级上对类树进行扩充，同时不会带来标识的重复。

注2：关于这种方法的一个例子，参见附录A中的类OcaGain。

注3：要素ID可以是属性ID，方法ID或事件ID，具体取决于其标识的要素的类型。

.3协议不变性

对于任何给定的类，无论使用哪种符合开放式控制架构的协议，以下项目应保持不变：

a）属性、方法和事件集合；

b）要素ID集合。

.4文本格式

开放式控制架构的属性、方法参数和事件参数中的所有文本均应采用UTF-8格式（见GB/T13000—2010）。

类的继承和更新规则

继承规则确保通过从现有类创建新类，以不影响现有产品或系统操作的方式将新功能添加到协议中。

继承能确保新的子类至少能支持其父类的功能和接口。

开放式控制架构的类继承规则是：

a）除了根类之外的任何给定类，都应确切地从另一个类继承。

b）子类应实现其父类所有的属性，方法和事件。

c）子类可通过以下方式扩充父类的定义：

1)添加新的属性、方法和/或事件；

2)增强现有的属性、方法和/或事件的定义。在这种情况下，所增强的定义应支持由父类定义的

所有功能。

d）子类继承的方法和事件应保留其父类对应的要素ID。

e）标准类不应从专有类继承。

当更新现有类时，应遵守以下规则：

a）类版本号应递增。

b）更新的类应实现现有类的所有属性、方法和事件。

c）更新的类可通过以下方式扩充现有类的定义：

1)添加新的属性、方法和/或事件；

2)增强现有属性、方法和/或事件的定义。在这种情况下，所增强的定义应支持由现有类定义的

所有功能。

d）被更新类的方法和事件应保留其父类对应的要素ID。

4.2.3类的实例化

正如创建其网络控制接口所需，设备应将类实例化为对象。每个对象应由唯一的对象编号（ONo）标识。

4.3消息

5

GY/T322.1—2019

4.3.1概述

监控操作应由协议数据单元（PDU）中的消息来执行。PDU在两个对象之间传递，这两个对象可在不同

设备中。开放式控制架构的消息应是以下三种类型之一：

a)命令：请求设备返回数据和/或执行操作。

b)应答：报告命令执行成功或失败。如果有，则返回所请求的数据。

c)通知：报告设备内部发生的特定事件，并提供相关数据。

除了设备复位消息（见第12章）外，开放式控制架构的命令消息均应由对应的应答消息应答。通知消

息不应响应。

4.3.2消息分发服务

开放式控制架构支持两种消息分发服务：可靠服务和快速服务。

可靠分发服务应使用网络提供的有保证的传输手段。可靠服务不应用于组播。例如，在TCP/IP网络中，

可靠服务使用TCP。

快速分发服务可使用较低开销，较低可靠性的传输手段。如果网络支持，快速服务可用于组播。例如，

在TCP/IP网络中，快速服务使用UDP。

开放式控制架构的所有命令和应答消息应使用可靠分发服务来传递。通知消息可使用两种服务中的任

何一种服务。订阅机制可使用快速分发服务，见第6章；设备复位机制应使用快速分发服务，见第12章。

注：对于某些类型的网络，可靠服务和快速服务可能相同。

5设备模型

5.1设备的可配置性

符合开放式控制架构的设备的可配置性可分为固定，可插拔，部分可配置和完全可配置，见表1。

表1可配置性

可配置性类型描述

固定静态设备在固件编程时就永久地指配对象库和信号流拓扑

当设备离线时，通过插入和拔出硬件模块，调整物理控制，重新加载或重新调整

可插拔静态

软件或通过其他手动方法，可改变设备的对象库和信号流拓扑

部分可配置动态设备在线时，控制器可改变设备的信号流拓扑

完全可配置动态在“部分可配置”的基础上，设备在线时，控制器还可创建和删除设备内部对象

固定和可插拔设备称为静态设备，因为控制器不能改变其配置项。部分可配置和完全可配置设备称为

动态设备，因为控制器可在线改变其配置项。

配置管理的详细内容见5.4.3和GY/T322.2—2019。创建和删除对象见5.9和5.10。

5.2对象寻址

6

GY/T322.1—2019

在符合开放式控制架构的设备中，每个对象（即特定类的每个实例化）应由对象编号进行唯一标识。

根据设备的可配置性，对象编号应在不同时刻进行分配，见表2。

注：在特定实现中，开发人员可使用特定的对象编号方案来优化设备性能和/或简化对象管理。例如，开发者可选择设

备的对象编号值与内部表索引值相对应，以便于对输入命令的快速解码。

表2对象编号分配

可配置性ONo分配时间刻

固定设备制造时

可插拔设备启动时

部分可配置设备制造时

完全可配置对象创建时

在完全可配置的设备中，当对象被删除并重新创建，且设备没有复位时，对象编号值不能被重新使用。

极端情况下如果对象编号地址空间耗尽，对象编号值宜从最初值重新开始。

开发设备的人员可以根据需要选择对象编号值，但应遵守以下规则：

a)对象编号应为32位整数。

b)每个对象应有唯一的对象编号。

c)对象编号不应为0。

d)从01到4095的对象编号值应给管理单元（见5.6）和其他需要预定义对象编号的对象保留。它

们应保留用于开放式控制架构的标准化。

e)不同的对象编号不能指向同一个对象。

注：与一些其他媒体控制协议不同，ONo不是基于某种分层级的多字段（i•j•k...）值。使用简单的32位ONo值是一

种设计选择，旨在最大限度地提高协议效率，并最大限度地减少解析对象引用、处理命令响应和管理错误时的设

备开销。

5.3设备模型

5.3.1概述

图1是开放式控制架构的设备模型。加框的元素表示对象。这些对象的类的定义见GY/T322.2—2019。

5.3描述可用类，举出示例和特有的结构布局。

7

GY/T322.1—2019

设备管理单元安全管理单元

工作单元

固件管理单元订阅管理单元

代理

网络管理单元电源管理单元

媒体时钟管理单元库管理单元音频处理管理单元

图1开放式控制架构的设备模型

5.3.2管理单元、工作单元和代理

开放式控制架构的设备模型包含如下三类对象：

a)管理单元：该对象应是控制对象，它影响或报告设备的基本属性和总体状态。在每个设备中，每

种管理单元类只应有一个实例（即一个设备管理单元，一个安全管理单元等）。每个管理单元应

有一个标准对象编号。部分管理单元是必需的，其他是可选的，见5.6和GY/T322.2—2019。

b)工作单元：该对象应直接控制设备的应用功能，见5.4。包括：音频静音开关，增益控制，均衡

器，电平监测，过载监测器，视频摄像机控制，信号属性，图像处理参数和信号处理功能等。工

作单元应按表3分类。

表3工作单元类型

类型功能

执行器控制应用功能(例如：开关)

传感器检测信号参数和其他数值，并将其报告给控制器

块及块工厂允许将相关对象组合成集合

矩阵允许将对象集合作为二维数组来寻址处理

网络描述数字网络连接特性

8

GY/T322.1—2019

c)代理：该对象应提供对同一设备中工作单元的间接控制。代理不应映射信号处理功能，但可影响

一个或多个相关联的工作单元对象的信号处理参数，或提供其他应用控制功能。代理的详细描述

见5.5。

示例：

名字为OcaGrouper的代理以类似于模拟系统中压控放大器分组的方式实现控制参数的复杂分组。

这三类对象中所有类的详细定义见GY/T322.2—2019。

5.4工作单元类

5.4.1执行器

执行器应控制设备内的信号处理和常规处理功能。执行器类见GY/T322.2—2019。示例参见附录A。

在任何设备中，任何执行器类可根据控制应用功能的需要进行多次实例化。

执行器示例见表4。

表4执行器示例

执行器类功能

OcaGain控制增益的功能——参见附录A

OcaMute控制信号静音的功能

OcaSwitch控制多掷开关

OcaFilterParametric控制参数均衡器区段

OcaDelay控制信号延时

OcaDynamics控制限幅器、压缩器、门控器或扩展器

OcaTemperatureActuator控制温度设置

5.4.2传感器

传感器应检测一些参数值并回传给控制器。传感器类在GY/T322.2—2019中定义。传感器示例见表5。

表5传感器示例

传感器类功能

OcaLevelSensor检测信号电平

OcaAudioLevelSensor用标准的VU表或PPM表的平均值和轨迹来检测音频信号电平

OcaTemperatureSensor检测温度

传感器值可通过周期性或条件性（例如，当其超过限定的阈值时）的方式，使用OcaNumericObserver

代理（参见5.5.5和6.3）自动传送。

5.4.3块

概述

9

GY/T322.1—2019

块应为一种特定类型的工作单元，它可包含工作单元对象（包括其他块对象）和/或代理对象。块也可

描述其所包含的工作单元之间的信号流拓扑。标准块类的定义见GY/T322.2—2019。

块内的对象称为该块的成员。包含对象的块称为该对象的容器。块可被任意深度地嵌套。

任何工作单元和代理都应是一个块的成员。每个设备均至少应包含一个称为根块的块，它应当包含该

设备的所有工作单元和代理。在简单设备中，所有的工作单元和代理均可属于根块。在复杂的设备中，工

作单元和代理可部署到嵌套的块中。

管理单元对象不应属于块。

每个块都应用一个类（块类）描述。所有块类的根类应为OcaBlock。

注1：块是一个抽象容器，它对设备结构和控制流做了最小的假定。没有预先限制块可以包含什么样的块类型，也没有

假设块可以包含什么样的对象。设备可以任意