GY T 322.3-2019 网络音频应用的开放式控制架构 第 3 部分：用于 TCP IP 网络的协议.pdf

1、 GY 中 华 人 民 共 和 国 广 播 电 视 行 业 标 准 GY/T 322.3 2019 网络音频应用 的 开放式控制架构 第 3 部分： 用于 TCP/IP 网络 的 协议 Audio applications of networks - open control architecture Part 3: Protocol for TCP/IP networks 2019 - 04 - 28 发布 2019 - 04 - 28 实施 国家 广播电视 总局 发布 GY/T 322.3 2019 I 目 次 前言 . II 引言 . III 0.1 概述 . III 0.2 文档约定

2、. III 1 范围 . 1 2 规范性引用文件 . 1 3 术语、定义和缩略语 . 1 3.1 术语和定义 . 1 3.2 缩略语 . 1 4 最小实现 . 1 5 协议细节 . 1 5.1 初始化 . 2 5.2 设备发现 . 2 5.3 设备监管 . 3 5.4 设备复位 . 4 5.5 约定 . 4 5.6 协议数据单元 . 5 5.7 协议特定数据类型 . 15 附录 A（资料性附录） 数据类型索引 . 17 附录 B（资料性附录） 协议数据单元（ PDU）的 UML描述 . 18 参考文献 . 19 GY/T 322.3 2019 II 前 言 GY/T 322 网络音频应用的开放

3、式控制架构 分为 以下 三 部分： 第 1部分：框架； 第 2部分：类结构； 第 3部分： 用于 TCP/IP网络 的 协议。 本部分为 GY/T 322的第 3部分。 本 部分 按照 GB/T 1.1 2009给出的规则起草。 本部分是参照 AES70-3-2015 网络音频应用的开放式控制架构 第 3部分： 用于 TCP/IP 网络 的 协 议 编制的。 请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。 本 部分 由全国广播 电影 电视标准化技术委员会 (SAC/TC 239)归口。 本部分 起草单位： 中央广播电视 总 台、国家广播电视 总局广播 电视 科学

4、研究院、国家 广播电视 总局 广播电视规划院、江苏省广播电视总台、浙江广播电视集团、苏州市福川科技有限公司、北京英夫美迪 科技股份有限公司、北京众和传新科技有限公司、杭州联汇科技股份有限公司、上海佰贝科技发展有限 公司、北京捷成世纪科技股份有限公司、苏州大学。 本部分 主要起草人： 钱岳林、朱峰 、罗攀、潘宇、张磊、王兰岚、庞超、唐峰、张伟、邓向冬、董 升来、何晶、孙岩君、李维民、陈武、董晓坡、陈沁、唐卫平、陈立德、赵崇峰、肖仲喆 。 GY/T 322.3 2019 III 引 言 0.1 概述 本部分 支持在 TCP/IP网络中实现符合 开放式控制架构 的 媒体设备的远程监控。 开放式控制架

5、构的第 1部分是参照 AES70-1-2015 网络音频应用的开放式控制架构 第 1部分：框架 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=101下载 。 开放式控制架构的第 2部分 定义了用于媒体网络监控的开放式控制架构的类结构。 第 2部分是参照 AES70-2-2015 网络音频应用的开放式控制架构 第 2部分：类结构 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=102下载 。 开放式控制架构的第 3部

6、分是参照 AES70-3-2015 网络音频应用的开放式控制架构 第 3部分： 用于 TCP/IP网络的协议 编制的，英文原文可从 http:/www.aes.org/publications/standards/search.cfm?docID=103下载 。 0.2 文档约定 本 部分 涉及的 通用数据类型 适 用于 所有 符合 开放式控制架构 的 协议，特定数据类型只适用于 本部 分 。为了便于区分，通用数据类型的名称使用 “ Oca” 前缀，而特定数据类型的名称使用“ Ocp1” 前缀。 GY/T 322.3 2019 1 网络音频应用的开放式控制架构 第 3 部分 ： 用于 TCP/

7、IP 网络 的 协议 1 范围 GY/T 322的 本部分 规定了 用于 TCP/IP网络 的 协议。 本部分适用于网络音频应用的监控。 2 规范性 引用 文件 下列文件对于 本 文件 的应用是必不可少的。 凡是注日期的引用文件，仅 注日期的版本适用于 本 文件 。 凡是不注日期的引用文件，其最新版本 (包括所有的修改单 )适用于 本 文件 。 GY/T 322.1 2019 网络音频应用的开放式控制架构 第 1部分：框架 GY/T 322.2 2019 网络音频应用 的 开放 式 控制架构 第 2部分：类结构 IETF RFC 3927 IPv4本地链路地址动态配置 （ Dynamic Co

8、nfiguration of IPv4 Link-Local Addresses） IETF RFC 4862 IPv6无状态地址自动配置 （ IPv6 Stateless Address Autoconfiguration） IETF RFC 6335 互联网数字分配机构（ IANA）为服务名称和传输协议端口号注册管理程序 （ Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Regist

9、ry） IETF RFC 6762 组播 DNS（ Multicast DNS） IETF RFC 6763 基于 DNS的服务发现 （ DNS-Based Service Discovery） 3 术语 、 定义和 缩略语 3.1 术 语和定义 下列术语和 定义 适用于本 文件 。 3.1.1 开放式控制协议 open control protocol； OCP 依据 开放式控制架构 定义的网络协议。 3.2 缩略语 下列缩略语适用于 本文件 。 PDU 协议数据单元 （ Protocol Data Unit） 4 最小实现 每个 符合 开放式控制架构 的 设备应实现本 部分 的 全部内容

10、。 本 部分 包含 的 特定可选项 见 第 5章 。 5 协议 细节 GY/T 322.3 2019 2 5.1 初始化 5.1.1 IP 地址初始化 在设备初始化 OcaNetwork或 OcaStreamNetwork对象（见 GY/T 322.2 2019）时，应进行 5.1.2、 5.1.3、 5.1.4所述的 初始化步骤。 上述对象 的 ControlProtocol属性值应为 “ OCP01” 。 5.1.2 IP 地址分配方法 符合 开放式控制架构 的 设备至少 应 实现 IPv4或 IPv6网络寻址标准。在本 部分 ，实现 IPv4网络寻址的 符 合 开放式控制架构 的 设备称

11、为 IPv4设备。实现 IPv6网络寻址的 符合 开放式控制架构 的 设备 称为 IPv6设备。 设备 可同时实现 IPv4和 IPv6，即它可同时是 IPv4设备和 IPv6的设备。 每个 IPv4设备宜实现 DHCP客户端并使用 DHCP服务器。每个 IPv6设备宜实现 DHCPv6客户端并使用 DHCPv6 服务器。在下文 中 ，这些客户端和服务器将分别统称为 IP地址客户端和 IP地址服务器。 如果设备属于多个 IP子网，它宜为每个子网设置一个 IP地址客户端。当设备连接一个子网时，设备宜 启动对应的 IP地址客户端。 如果在地址 分配超时 时段 内 IP地址客户端连接 到 IP地址服

12、务器，则该设备应使用该服务器分配的地址。 当在地址 分配超时 时段 内 未 发现 IP地址服务 器 ， 或设备未实现 IP地址客户端： a) IPv4设备宜使用在 IETF RFC 3927中定义的 IPv4本地链路地址； b) IPv6设备宜使用在 IETF RFC 4862中定义的由 IPv6自动生成 的 IPv6 本地链路地址。 当设备未实现本地链路地址时，应手工设置 IP地址。 5.1.3 套接字和端口 获得 IP地址后，设备应 建立 一个 TCP监听套接字接收不安全的 符合 本部分 的 会话，或一个 TCP监听套接 字接收安全的 符合 本部分的 会话，或两者同时打开。 设备应使用标准

13、 IANA动态端口范围（ 49152到 65535，见 IETF RFC 6335）内的 TCP端口号。在该范围内， 设备可以把不安全的监听套接字绑定到任何可用的 TCP端口，以及安全的监听套接字绑定到其他 可用的 TCP 端口。这些端口应公告， 见 5.2.2。 5.2 设备发现 5.2.1 概述 设备发现，是连接到网络的 符合 开放式控制架构 的 设备使自身被公共访问目录服务获知的机制，也是 网络中的其他设备可使用目录服务查找和寻址设备的 机制 。 符合开放式控制架构的设备 的 发现进程应具备服务发现架构，其中 符合 开放式控制架构 的 设备 应 到网 络 服务 目录中自行 注册 ，需要获

14、悉该设备 IP地址的网络实体 可 通过 此目录 获取到。 服务发现 应通过基于 DNS的服务发现实现（见 IETF RFC 6763）。 注： “ 发现 ” 一词的另一个常见用法是指设备功能的发现。在 开放式控制架构 中，功能发现是由设备的根块和 内部块 （ 如果有 ） 枚举的方法实现。这样的枚举是正常 开放式控制架构 的 命令响应序列 ,对网络类型没有特殊的依赖性。 因此，它们不在本 部分 的范围内。有关详细信息，见 GY/T 322.1 2019 和 GY/T 322.2 2019 的 OcaBlock 类的 详 细说明 。 5.2.2 服务发现 如果一个 符合 开放式控制架构 的 设备打

15、开了一 个监听 套接字来 建立符合本部分的不安全连接 ，应注册 成 以下服 务 类型： _oca._tcp 如果一个 符合 开放式控制架构 的 设备打开了一个监听 套接字来 建立符合本部分的安全连接 ，应注册成 以下服务 类型： GY/T 322.3 2019 3 _ocasec._tcp 对安全和不安全的服务，注册的服务 名 称 应与连接 所用的 OcaNetwork或 OcaStreamNetwork对象 NameAdvertised属性相同。如果该名称变更，设备应注销旧服务，并使用新名称注册 新服务 。 注册可在任何期望的域中进行，在大多数应用中，建议 在 本地域 注册 。 在本地域注册

16、应使用组播 DNS（ mDNS）协议（见 IETF RFC 6762）。 当 在本地域注册，服务名称冲突是由 DNS组播协议自动解决。当通过组播 DNS改变服务名称以 避免 冲突 时 ， 服务名称已更改的设备应自动更新 NameAdvertised属性 。 注： 在非本地域注册时，名称冲突不会自动解决。因此，如果 符合 开放式控制架构 的 设备 可能 在非本地域注册，宜选 择 唯一的缺省服务名称。 为服务注册的端口应与该设备在 5.1.3中选择的 端口相一致 。 遵循 IETF RFC 6763第 6章 版本标签的建议，不安全和安全注册的 TXT记录应至少包含两个键 /值对。第 一个键 /值对

17、应为： txtvers=1 OCA service registration version 第二键 /值对包含 开放式控制架构 的 版本，应按照以下格式： protovers=x x是设备 OcaDeviceManager对象指定的 开放式控制架构 版本十进制数（ 见 GY/T 322.2 2019）。 TXT记录可包含更多的数据，只要记录包含上面提到的两个键 /值对，且数据符合在 IETF RFC 6763第 6 章 阐述的规则。 TXT记录的 开始 字段 如图 1所示。如果 开放式控制架构 的 十进制版本大于 9，第二长度字段应 为 0C16。 0916 txtvers=1 0B16 p

18、rotovers=x 图 1 TXT 记录起始字段 控制器可以在 所需域内 通过执行一个 DNS-SD服务浏览发现网络中的 符合 开放式控制架构 的 设备，查找 “ _oca._tcp” 服务或 “ _ocasec._tcp” 服务， 或 两者。 在本地域中浏览应使用组播 DNS（见 IETF RFC 6762）。 5.3 设备监管 5.3.1 概述 设备监管意味着对网络上的设备可用性进行相对持续（通常是周期性 的 ）验证。 符合 本 部分 定义 的 设 备监管机制，可用来监管连接的 符合 开放式控制架构 的 设备。 5.3.2 规范 每个 符合 开放式控制架构 的 设备均应实现监管机制；按照

19、应用要求，控制器可以启 用或禁用该机制。 在 设备 建立安全或不安全的连接后 的任何时 刻，控制器可通过向设备发送 KeepAlive消息（见 5.6.5） 启动设备监管进程。从那一刻直到断电或设备复位，该设备和控制器应使用 HeartbeatTime值以确保设备和 控制器每 心跳时间 （ HeartbeatTime）发送一个消息。该消息可以是 KeepAlive消息或其他消息。 HeartbeatTime值应在 KeepAlive消息中指定，并可随时变更。设备应为不同的连接支持不同 HeartBeatTime值 。 一旦监管进程启动，对已建立的连接，控制器和设 备 应记录收到符合本部分的 消

20、息之间的时间间隔。 如果控制器或设备未接收消息的时间长度等于三倍 HeartBeatTime值，应认为 连接 丢失，控制器或设备应关 闭该连接。关键 开放式控制架构 的 应用应使用 KeepAlive机制，而不是靠 TCP/IP检测连接丢失。 示例： 如果控制器发送的第一个 KeepAlive消息中 HeartBeatTime值为 2秒，控制器和设备必须每两秒发送一个消息。如果 6秒 没有收到消息，设备和控制器将认为连接丢失。 GY/T 322.3 2019 4 注： 如果控制器在建立连接后未发送 KeepAlive 消息，则 该连接 不启动设备监管机制。在这 种情况下，除非检测到 TCP 保

21、持激活机制，否则不会对空闲连接进行连接丢失检测（即连接没有控制流量）。典型参数设置条件 下的 TCP 保 持激活机制的检测超时时长超长 ，是 不可 接受 的 ， 往往需要数小时。此外，并非所有的 TCP/IP 协议栈都能正确地 实现保持激活机制。 当连接丢失时，如果可能的话，控制器和设备应执行适当的终止处理。应删除连接上 的 锁和订阅，并 清除连接信息。 5.4 设备复位 5.4.1 概述 符合 开放式控制架构 的 设备可实现设备复位机制。 5.4.2 未实现复位 如果设备未 实现 复位机制，它应以 NotImplemented状态响应 SetResetKey消息，且不执行其他操作。 否 则

22、， 根据 5.4.3规定 的 操作 。 5.4.3 实现复位 上电复位后，设备应禁用复位机制。若要启用复位机制，控制器应先调用设备的 OcaDeviceManager对 象的 SetResetKey方法。当调用 SetResetKey时，控制器应传递以下参数： ResetKey：一个 128bit设备复位 校验码 ； ResetAddress：设备 应 监听 DeviceReset消息（见 5.6.6）的 OcaNetworkAddress（见 5.7.2）。该地址 应包含一个 UDP端口号的 数据类型 ，以及 ， 可选的一个 IPv4或 IPv6组播地址。 当收到 SetResetKey的消

23、息，该设备应配置相关机制，在 ResetAddress参数指定的 端口打 开 UDP套接字。 如果 ResetAddress参数同时指定一个组播地址，设备应加入指定的组播组。 如果收到多个 SetResetKey消息，应使用最新的 SetResetKey消息给出的参数。 一旦复位机制配置 完毕 ，设备应监听用于 获得 包含给定设备 复位校验码 的 DeviceReset消息的 UDP套接 字。如果接收到这样一个复位消息，设备应执行上电复位。如果给定的 ResetAddress不包含一个 组播地址， 复位消息将通过指定的端口直接发送到设备上。如果 ResetAddress包含一个组播地址，复位消

24、息将直接发 送到该设备的指定端口或组播组的指定端口。 如果收到的 DeviceReset消息包含指定消息以外的 复位校验码 值 ，消息应被忽略并不执行复位操作。 设备复位或关机后，设备应解除其复位机制。该机制可由上述过程重新配置。 注： 如果设备的 复位校验码 是通过不安全的 开放式控制协议 （ OCP） 连接发送，可能会被截获并被恶意使用，导致系统 破坏。当需要在有破坏 威胁 的 环境下 使用设备复位机制时， SetResetKey 消息只宜通 过安全的 OCP 连接发送。 实现设备复位机制的设备宜提供手动方式（例如：开关、跳线或面板命令）来禁用该功能。 5.5 约定 5.5.1 字节顺序

25、对 于 基本的 符合 开放式控制架构 的 整型数据类型和字长超过 1个字节的浮点数据类型， 本部分 应使用网 络字节顺序（即大端或高 位优先 ）。 5.5.2 封装规则 OcaBoolean类型应封装为单字节，其中值 0表示的布尔值 false，所有其他的值表示的布尔值 true。 在 GY/T 322.2 2019中定义的复合数据类型 （即转化为网络字节流） 的单条属性应使用 GY/T 322.2 2019中的 数据类型 定义进行 封 装 。 在 GY/T 322.2 2019中 定义的 接口 适用于 以下封装规则 ： 类方法输入参数的数量应通过 Ocp1Command 中的 Ocp1Par

26、ameters 结构中的 parameterCount 属性 传递 ， 见 5.6.2； GY/T 322.3 2019 5 方法的输入参数应按照 GY/T 322.2 2019规定的顺序，封装 在 Ocp1Command 中 的 Ocp1Parameters 结构中 ， 见 5.6.2； 类方法输出参数的数量应通过 Ocp1response中的 Ocp1Parameters结构中 的 parameterCount属性 传递 ， 见 5.6.3； 方法输出 参数应通过 GY/T 322.2 2019规定的 顺序 ， 封 装 在 Ocp1Response中 的 Ocp1Parameters 结构

27、中 ， 见 5.6.3； 事件参数的数量应加 到 Ocp1Notification 中 的 Ocp1ntfparams结构 中 parameterCount属性 ； 事件参数应通过 GY/T 322.2 2019 规定的顺序 ，封 装 在 Ocp1Notification 中的 Ocp1NtfParams 结构 中的 Ocp1EventData结构中 ， 见 5.6.4。 注： 本部分使用的数据类型索引参见附 录 A。 5.5.3 示例 考虑 OcaClassIdentification复合数据类型，在 OCC定义如下 ： OcaClassIdentification = OcaClassID

28、 ClassID, OcaClassVersionNumber ClassVersion OcaClassID = OcaUint16 FieldCount, OcaUint16 Fields OcaClassVersionNumber = OcaUint16 Value 现在考虑一个具有以下值的特定类标识实例： OcaClassIdentification classIdentification = ClassID = 2, 1,3 , ClassVersion = 1 通过上述封装规则，在 网络中 实例 将表示为 以下字节序列（十进制值，左侧的先发送）： 0, 2, 0, 1, 0, 3,

29、 0, 1 5.6 协议数据单元 5.6.1 消息格式 5.6.1.1 概述 每个 符合 本部分的 消息 格式 如 图 2所示 。 同步值 S y n c v a l u e 协议头 h e a d e r 数据 D a t a 协议版本 P r o t o c o l V e r s i o n 消息大小 M e s s a g e S i z e 消息类型 M e s s a g e T y p e 消息计数 M e s s a g e C o u n t 图 2 通用消息 格式 消息协议数据单元的 C语言风格定义 如下： struct OcaUint8 syncVal; / 消息同步值

30、GY/T 322.3 2019 6 Ocp1Header header; / OCP包头 OcaUint8 data; / 消息数据 Ocp1MessagePdu； 参数定义 见表 1。 表 1 消息协议数据单元参数定义 参数 定义 syncVal 消息同步值指示一个新 符合本部分的 消息的 开始 。同步值应 为常量 3B16 header 本部分 包头包含通用消息字段 data 存放实际消息数据的数据数组 接收器应始终检查每一个以 同步值开始的 符合本部分的 消息。如 果接收到的消息不以标准同步值开始， 则接收器应关闭与发送器的连接。 注 ： 连接 断开之后，所涉及的控制器可以选择重启连接。

31、 开放式控制架构没有定义标准的恢复程序。 协议数据单元可由 GB/T 28167 2011中定义的 XML元数据交换（ XMI） 2.1格式的通用建模语言（ UML） 文档定义。相关文件的获取途径参见附录 B。 5.6.1.2 包头 符合 本部分的 数据结构 的 C语言风格定义 如下： struct OcaUint16 protocolVersion; / 版本号 OcaUint32 pduSize; / PDU字节长度 OcaMessageType pduType; / PDU类型 OcaUint16 messageCount; / 消息数量 Ocp1Header; 参数定义 见 表 2。

32、表 2 包头参数定义 参数 定义 protocolVersion (长度 为 2 字节 ) 本部分的 协议版本号。 开放式控制架构 的 类有自己的版本号，因此只有在本 部分 中描述的 本部分的 协议更新时，协议版本才更新 pduSize (长度 为 4 字节 ) 完整 PDU 的字节 长度 ，包括包头，但不包括同步值 pduType (长度 为 1 字节 ) 表示 PDU 的类型； 即，包含的 PDU 消息类型。应使用下列消息类型之一（值在括号之间）： OcaCmd (0) 命令 -不需要响应 OcaCmdRrq (1) 命令 -需要响应 OcaNtf (2) 通知 OcaRsp (3) 响应

33、（对应命令或通知） OcaKeepAlive (4) 用于设备监管的保持激活消息 messageCount (长度 为 2 字节 ) 消息数量，显示在数据字段有多少消息（ pduType 类 型）。此消息数量应至少为 1。如果 pduType 等 于 OcaKeepAlive，消息数量应为 1 5.6.2 命令消息 5.6.2.1 格式 命令消息 格式 如 图 3所示 。 GY/T 322.3 2019 7 同步值 S y n c v a l u e 协议头 h e a d e r 命令 1 命令大小 C o m m a n d S i z e 命令句柄 H a n d l e 目标编号 T

34、a r g e t O N o 方法 ID M ethodID 命令 2 . 命令 C o m m a n d 参数 P arameters 类树层级 T reeLevel 方法索引 M ethodIndex 参数计数 Pa rameter Count 参数 1 参数 2 . 参数 P a r a m e t e r 图 3 命令 消息 命令消息协议数据单元的 C语言风格定义如下： struct OcaUint8 syncVal; / 消息同步 值 Ocp1Header header; / OCP包头 Ocp1Command commandsmessageCount; / 命令数组 Ocp1C

35、ommandPdu； 参数定义 见表 3。 表 3 命令消息参数定义 参数 定义 syncVal (长度 为 1 字节 ) 消息 同步 值 （ 见 5.6.1.1） header (长度 为 9 字节 ) 通用 消息 字段。见 5.6.1.2 的 Ocp1Header 定义 commands （可变长度 ） 命令（ messageCount） 数组。命令 格式由 Ocp1Command 类型 定义 ， 见 5.6.2.2 5.6.2.2 Ocp1Command Ocp1Command数据结构的 C语言风格定 义如下： struct OcaUint32 commandSize; / 单条命令的长

36、度 OcaUint32 handle; / 命令句柄 OcaONo targetONo; / 在控制器 设备中的目的对象编号 OcaMethodID methodID; / 被调用 方法的 ID Ocp1Parameters parameters; / 被调用消息 的输入参数 Ocp1Command； 参数 定义 见 表 4。 GY/T 322.3 2019 8 表 4 Ocp1Command 参数定义 参数 定义 commandSize (长度 为 4 字节 ) 单条 命令的长度， 以 字节为单位。应 包含 commandSize 字段 完整的 Ocp1Command 结构 的长度 hand

37、le (长度 为 4 字节 ) 强制 使用 32bit 作为 对于 命令 引用 “handle” 。 响应 应 使用同样的 handle 值 。控制器 可 自由 地为 命令分 配 handle 值 ， 设备应在对应的响应中匹配这些 handle 值。 在 控制器和设备之间 ，对于 每个 TCP 会话应 用 私有 handle targetONo (长度 为 4 字节 ) 在 控制器设备 中 的 目的对象编号 (OcaONo)。 OcaONo 应 使用 4字节（ 即 一个 OcaUint32） methodID (长度 为 4 字节 ) 被 调用 方法 的 ID（ OcaMethodID） （即

38、目标 对象调用的 方法 ） ， 见 5.6.2.3 parameters (可变长度 ) 被调用 消息的输入参数。 如果被调用的 方法 没有任何 参数，该结构 应保留 5.6.2.3 OcaMethodID OcaMethodID数据结构的 C语言风格定义如下： struct OcaUint16 treeLevel; /类树层级 OcaUint16 methodIndex; /方法 的索引 OcaMethodID; 元素 定义 见 表 5。 表 5 OcaMethodID 元素定义 元素 定义 treeLevel (长度 为 2 字节 ) 在 本方法中定义的 类 树层级 （ 1=root） m

39、ethodIndex (长度 为 2 字节 ) 方法 的索引。 定义 了方法的 类应 决定索引值。 对于 每个树层级，索引 应起始 于 1 类元素分类详见 GY/T 322.1 2019。 5.6.2.4 Ocp1Parameters Ocp1Parameters数据结构的 C语言风格定义如下： struct OcaUint8 parameterCount; /参数数量 OcaUint8 parameters; /参数数组 Ocp1Parameters; 元素 定义 见表 6。 GY/T 322.3 2019 9 表 6 Ocp1Parameters 元素定义 元素 定义 parameterC

40、ount (长度 为 1 字节 ) 在 参数数组中的 参数 数量 。若 没有参数数据， 该值 可为 0 parameters (可变长度 ) 命令 实际（ 封装 后） 参数 数组 。 参数 应 配置 特定的 调用方法。 对于 每个类 方法专门 的 参数定义 见 GY/T 322.2 2019 5.6.3 响应消息 5.6.3.1 格式 响应消息 格式 如 图 4所示 。 同步值 S y n c v a l u e 协议头 h e a d e r 响应大小 R e s p o n s e S i z e 句柄 H a n d l e 状态码 S t a t u s C o d e 响应 1 响应

41、 2 响应 R e s p o n s e 参数计数 Pa rameter Count 参数 1 参数 2 . 参数 P a r a m e t e r 图 4 响应消息 响应消息协议数据单元 的 C语言风格 定义如下： struct OcaUint8 syncVal; / 消息同步值 Ocp1Header header; / OCP包头 Ocp1Response responsesmessageCount; / 响应 数组 Ocp1ResponsePdu; 元素定义 见 表 7。 表 7 响应消息元素定义 元素 定义 syncVal (长度 为 1 字节 ) 消息 同步值 ， 见 5.6.1

42、.1 header (长度 为 9 字节 ) 通用 消息 字段 ，见 5.6.1.2 responses (可变长度 ) 响应 数组 （ messageCount） 。 响应格式由 Ocp1Response 数据 类型定义，见 5.6.3.2 5.6.3.2 Ocp1Response Ocp1Response数据结构的 C语言风格定义 如下： struct OcaUint32 responseSize; / 单条 响应的长度 OcaUint32 handle; /响应句柄 GY/T 322.3 2019 10 OcaStatus statusCode; / 状态代码 表示响应所述方法的调用结果

43、 Ocp1Parameters parameters; / 状态 参数 Ocp1Response; 元素 定义 见 表 8。 表 8 Ocp1Response 元素定义 元素 定义 responseSize (长度 为 4 字节 ) 单条 响应的长度（ 以 字节为单位） 。 应 包含 responseSize 字段 完整的 Ocp1Response 结构 的长度 handle (长度 为 4 字节 ) 强制 使用 32bit 作为 对于 命令 引用 “handle ” 。 响应 应 使用 与触发 该响应命令同样的 handle值 statusCode (长度 为 1 字节 ) 状态 代码表示 响应 所属方法 调用 结果 。 状态代码值定义 见 GY/T 322.2 2019 parameters (可变长度 ) 状态 参数（ 调用 方法的 输出 参数） 。 若方法 没有 任何输出参数， parameterCount 应为 0。 Ocp1Parameters 参数数据 类型 定义 见 5.6.