GIGE 协议摘录 —— GVCP 协议（二）

本文主要是介绍GIGE 协议摘录 —— GVCP 协议（二），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

系列文章目录

GIGE 学习笔记
GIGE 协议摘录 —— 设备发现（一）
GIGE 协议摘录 —— GVCP 协议（二）
GIGE 协议摘录 —— GVSP 协议（三）
GIGE 协议摘录 —— 引导寄存器（四）
GIGE 协议 2.0 中文版

---

---

    GVCP 协议描述了程序与设备之间遵守的通信规范，重点介绍了三种类型的通道，即控制通道、消息通道和流通道，并列举了各种事件命令。

概览

    GVCP 是一种依赖于 UDP 传输层协议的应用层协议。它基本上允许应用程序在设备上配置设备（通常是照相机），并在设备上实例化流通道（ GVSP 发射器或接收器，如果适用），以及设备在特定事件发生时通知应用程序。

    GVCP 仅为一个应用程序（主应用程序）提供必要的支持，以控制设备（写入设备）。然而，如果主应用程序允许这样做，那么许多应用程序就可以监视一个设备（从一个设备中读取）。应用程序也可以请求对已经在主应用程序控制下的设备的控制，前提是设备支持并且主应用程序允许这样做。在 GVCP 下，应用程序是主程序，设备是从程序。命令请求总是由应用程序发起的。

    命令和确认消息必须分别包含在一个数据包中。应用程序必须等待确认消息（当请求时）才能发送下一个命令消息。这就创建了一个非常基本的握手，以确保最小的流量控制。确认消息提供设备实际接收到命令的反馈，它还提供命令请求的任何响应数据。

    该规范的当前版本使用 UDP IPv4作为传输层协议。由于 UDP 是不可靠的， GVCP 定义了机制来保证数据包传输的可靠性和确保最小的流量控制。

一、 基本概念

    在 GVCP 协议报文中，最大传输单元 MTU 定义为 576byte ，包括 IP 头、 UDP 头、 GVCP 头以及数据负载部分。

    GVCP 控制头和数据段部分大小必须是4字节的倍数。

    GVCP 是基于 UDP 无连接服务的，因此，设计了消息重传机制。消息重试次数可以由用户设定，默认值为 3 。reg_d≠0 ，在控制通道关闭后，其值会被初始化。此外，还启用了端到端连接，通过设置心跳计数来侦听链路是否断开。同理，其值是可以自定义的。一般来说，应用程序端的心跳频率应略低于设备端的 13，这样可以在 UDP 包发送丢失时排除心跳因素的干扰。

    GVCP 头包含了键值 0x42，用于设备与应用程序识别 GVCP 包。

    设备的第一个 GVCP 端口号必须为 3956 。

二、通道

    通道即虚拟连接。在本说明中包含 1 个控制通道，0-512 个流通道，0 或 1 个消息通道。

（1） 控制通道

    控制通道被应用程序用于与设备进行通信。 GVCP 定义了两种类型的控制通道：

1. 主控制通道：主控制通道由主应用程序创建。主应用程序是指允许写入设备寄存器的应用程序。只允许一个应用程序作为一个设备的主要应用程序。
2. 辅助控制通道：任何辅助应用程序都会创建辅助控制通道。辅助应用程序只能从设备寄存器中读取（它们不能写入其中）。这可以用于监视或调试。一个设备可能支持许多辅助应用程序。一个设备不允许支持任何辅助应用程序。

    在消息或流通道创建前，必须实例化一个控制通道。例如，有程序请求对一个寄存器进行写操作，以实现一个图像捕获，设备应该在寄存器被写入时返回一个响应，而不是捕获已完成时。

1、控制通道权限

    GVCP 定义了四个级别的特权：

1. 独家访问，通过写 CCP 寄存器授权访问。主程序能对设备进行读写，其他程序则不能，也不允许创建一个第二控制通道，除其发送的 DISCOVERY_CMD、FORCEIP_CMD 等少数命令，其他命令请求设备一概返回一个错误。

2. 控制访问权限，与前者不同在于，其他程序可以读设备，也允许具有控制访问权的二级程序创建一个控制通道。

3. 具备切换能力的控制访问，与控制访问不同在于，该模式主程序能对设备进行读写，允许具有正确凭据的其他程序控制设备。

4. 监控访问，条件最弱一般用于调试帮助。只要无独占访问的程序连接设备就可以读该设备。

    设备必须记录主程序相关的上下文信息，至少包括程序 IP 地址、源 UDP 端口和授予特权类型，以确定其是否可授权给其他程序（如果收到的命令消息合法）。

    在程序端使用一个动态端口号（任意），设备端使用标准 GVCP 端口（除非通过 mDNS 通告了一个不同的端口）就可以创建控制通道，再通过 GVCP DISCOVERY 命令创建链接。在软件开发阶段，对设备使用非独占方式访问，有助于其他调试工具监控该设备。

2、控制通道寄存器

1. 控制通道特权寄存器（Control Channel Privilege register ( CCP )）
2. 控制切换键寄存器（Control Switchover Key register）
3. 心跳超时寄存器（Heartbeat Timeout register）
4. 待定超时寄存器（Pending Timeout register）

3、打开/关闭控制通道

    程序通过对 CCP 寄存器写请求特权，并检查设备 ACK 消息返回的状态，根据状态码内容决定是否有打开通道的资格。允许主程序在不关闭控制通道时请求相同的特权类型，如可通过写 CCP 寄存器来直接切换到另一控制特权。通过对 CCP 寄存器写 0 来关闭通道，并释放主程序的特权。

4、控制通道心跳

    使用心跳序列可以定期检测控制通道是否处于活动状态，心跳速率是可自定义的，默认每秒 1 次。设备在接收到主程序任一有效命令后，必须重置心跳计数，少数命令除外，如 ACTIONCMD 。心跳计数可通过读 CCP 寄存器来重置，且只能由主程序执行。若设备在超过用户设置的心跳超时时间（默认 3 秒）后，且没有禁用心跳性能寄存器仍没有收到一个控制消息，则必须断开控制通道。如果主程序不能读 CCP 寄存器或读取非预期数值时，即可判定链路断开，此时，必须实例化控制通道以建立与设备的新链接。

5、设备控制

    主程序可以在打开通道后，发送任何受 GVCP 支持的命令，二级程序可发送 READREG 和 READMEM 命读取设备速率。DISCOVERY、ACTION 和 PACKETRESEND 命令可以在任何时间由任一程序发送，且设备总是在收到后返回一个 ACK 消息。

6、使用待定应答

    若设备执行命令时间比程序预期的要长，则下述机制有助于相互间通信：

1. 执行一个请求所需的最大执行时间。
2. 当请求执行时间将超过①中的值，使用使用 PENDING_ACK 消息通知程序使其可以等待额外必需的时间来完成该请求。
   PENDING_ACK 的 ack_id 值与程序初始请求的 reg_id 值相同。若设备支持该消息，则必需在一个PENDING_ACK 和 ACK 命令发出之间响应 DISCOVERY_CMD，且不能用该消息响应一个DISCOVERY_CMD、FORCEIP_CMD 和 PACKETRESEND_CMD。

7、控制通道字典

    如果一个控制报文所在请求端没有所需特权，设备则返回一个只含包头的应答报文，其 status 字段必须为 GEV_STATUS_ACCESS_DENIED，length 字段值为0。下面列出了在通道中各种类型的控制消息。

1. DISCOVERY
   DISCOVERY_CMD：8 字节，其中 8-15 位表示 flag，其第 3 位说明设备是否允许广播其应答报文，ACKNOWLEDGE 位（第7位）须设置。
      
   DISCOVERY_ACK：如果设备与程序在同一个子网，则必须单播一个该报文。如果 DISCOVERY_CMD 报文并没有在设备所在子网接收，或者上段提到的 flag 字段，设备应该广播该报文。当设备的静态 IP 与程序所在的子网 IP 不匹配时会发生。如果 flag 第 3 位清零且设备与程序不在一个子网段，则设备对程序是不可见的。其他说明见 Discovery ACK Delay 引导寄存器。

2. FORCEIP
   该消息要求将一个静态 IP 地址强制赋给 MAC 地址被识别的设备。
      
   FORCEIP_CMD：必须在非主程序的 GVCP 端口上广播该消息，包含要访问设备的 MAC 地址，若该地址与设备的 MAC 地址不匹配，或存在独占或控制访问（含可切换控制）程序时，该消息都必须被设备丢弃。可用于实现指定 MAC 地址的设备两种不同的动作。若该消息的 static_IP 字段为0，设备必须重启其所有网络接口上的 IP 配置周期，而不用发送给程序一个 FORCE_ACK 命令，否则，设备须将其 IP 地址设置为该字段的值，成功分配后，返回 FORCEIP_ACK（若程序请求）。如果该静态 IP 需要设备重置其通信栈及内部状态，则该 IP 必须在重置后保持不变。该命令 flag 字段的第3位表明设备是否应广播 FORCE_ACK 消息，若该位被清零，则不能广播应答消息，这在该命令执行期间所在子网变动时有效。
      
   FORCEIP_ACK：当一个强制性静态IP 地址被赋给一个设备后，可以返回一个 FORCEIP_ACK 消息。当程序设置了 FORCEIP_CMD 的 flag 字段的第 3 位时，设备应广播此应答消息。

3. READREG
   

4. WRITEREG
   

5. READMEM
   

6. WRITEMEM
   

7. PACKETRESEND
   

    GVSP 接收端分组重传处理：需要 GVSP 接收端程序快速发送 PACKETRESENF 命令，以防要重传的分组在发送端中丢失。一些网络拓扑保证了 UDP 分组按序到达，但 UDP 分组在传输中若存在多条路由（存在网关和路由器），则不能保证按序到达。对于前者，GVSP 接收端程序可使用分组ID向下跟踪包序列，如果某个包ID跳过了，程序立即请求重发丢失分组，可以使用超时器检测数据跟踪是否丢失，对于后者，程序不能确定分组ID 值是有序的，因此需要一个分组重传机制，可以有多种，如使用超时方案。

8. PENDING
   

9. ACTION
   

（2）流通道

    使用 GVSP 协议使数据从一个 GVSP 发送端转移到 GVSP 接收端。若产品支持 GVSP 流则必须支持从索引 0 顺序启动的流通道，不允许索引中间有间隔。发送数据的流通道使用比接收流通道更低的索引，该索引可在相关引导寄存器中找到。

流通道寄存器

    一个给定的流通道可以是发射机或接收器。以下寄存器与发射器和接收器流通道相关联：

1. 流通道端口寄存器（Stream Channel Port register，SCPx）
2. 流通道数据包大小寄存器（Stream Channel Packet Size register，SCPSx）
3. 流通道目的地址寄存器（Stream Channel Destination Address register，SCDAx）
4. 流通道配置寄存器（Stream Channel Configuration register，SCCFGx）

    除此之外，以下寄存器还与发送端流通道相关联。

5. 流通道分组延迟寄存器（Stream Channel Packet Delay register，SCPDx）
6. 流通道源端口寄存器（Stream Channel Source Port register，SCSPx）

标签数据块

    在流通道上传输的相机图像被拆分成合适大小的数据块，接收端可通过查找与每个数据块相关联的块 ID 来追踪图像。

    一个 GigE Vision 2.0 兼容的 GVSP 发送端和接收端，如果只支持 64 位 block id64 和 32 位 packet id32，则称为纯 GigE Vision 2.0；若支持 16 位 block id 和 64 位 block id64 ，称为双模式 GigE Vision 2.0，这种情况考虑了向后兼容性。

打开一个流通道

    只有主程序可配置流通道，通过将主机端口写入 SCPx 寄存器、目的地址写入 SCDAx 寄存器即可打开一个流通道。对于一个给定流通道，GVSP 发送端应使用任意的动态端口号作为 UDP 源端口，端口号范围 [49152, 65535] 。流通道必须在程序置 SCPx 寄存器的 host port 字段为一个非 0 值时，才被激活。当通道打开时，当前数据块的索引 block id/block id64 必须被重置为 1 。

操纵一个流通道

    当 SCPx 值非 0 时，SCSPx 必须返回一个非 0 值对应 GVSP 发送端流通道的源 UDP 端口。只要其对于控制会话的持久不变，其值在先前的任何时候为非 0 值也依然有效。若 SCPx 为非 0 值时，设备必须默认所有的 UDP 流量来自于设备 SCSPx 端口的 SCDAx 和 SCPx 寄存器列表中的地址和口。

关闭一个流通道

    主程序必须通过将 SCPx 寄存器清零来关闭一个流通道。打开通道，SCPx 是最后一个被访问的寄存器；关闭通道，则为第一个。GVSP 发送端不能发送一个不完整的流分组。相机可通过提供采集启动和采集停止特征来停止流的传送。若当前分组是最后一个发送时，GVSP 发送端不需要发送数据追踪，该分组行为类似一个退出。

分组大小

    通过发送流测试分组来确定 IP 不分段情况下的最大分组大小，用一个简单的二分迭代搜索算法，对 SCPSx 寄存器写各种大小的分组，以寻找一个最优的分组大小。

组播

    在数据流须发送到多个地方时使用。当在 SCDAx 寄存器的一个组播选项中设置了 GVSP 发送端的目的 IP，即可激活组播。

多网络接口影响

    允许流通道上多个网络接口以增加流的可用带宽，具体见 2.2.4 节。

穿越防火墙或网络地址转换（NAT）设备

    设计了 SCSPx 寄存器，以允许一个 GVSP 接收端相关的程序通知其上的远程 UDP 端口，在 GVSP 收发端流通道上创建一个模拟的双向通行会话。可采用 SCPx 中的源端口，在其上发送一个 UDP 分组到 SCSPx 指定的端口，通过防火墙的相关配置，程序可定时发送类似第一个分组以保持回话，间隔推荐 30s。该机制可以使程序在防火墙中打开 UDP 端口，但程序不应指望设备回应其发送到设备消息通道上的分组。

无条件流

    在以太网中存在大量视频分布系统，尤其一些同时包含多个 GVSP 接收端时，需强制确保 GVSP 发送端可以一直持续流动数据，而不用关心其主程序或网络的状态，如主程序崩溃或关闭或移动到不同的主机上，只要该发送端受其主程序支配即可。

（3）消息通道

    消息通道与控制通道非常相似，但是请求会以相反的方向发出。该设备总是在消息通道上启动事务。因此，消息通道标头与控制通道标头相同。设备对消息通道的支持是可选的。

    允许设备发送一个异步消息到程序。如一个相机触发器被检测到，设备可发送一个信号。设备总是初始化该通道上的事务。与控制通道使用的头是相同的，但请求发送的方向相反（设备 ——> 程序）。若通道的消息增加时，相应 req_id =（req_id + 1）mod 65535 + 1 。允许程序检测一个 UDP 报文是否丢失，即使没有请求应答。

消息通道寄存器

    消息通道将提供以下寄存器：

• 消息通道端口寄存器（Message Channel Port register，MCP）
• 消息通道目的地址寄存器（Message Channel Destination Address register，MCDA）
• 消息通道传输超时寄存器（Message Channel Transmission Timeout register，MCTT）
• 消息通道重试计数寄存器（Message Channel Retry Count register，MCRC）
• 消息通道源端口寄存器（Message Channel Source Port register，MCSP）

打开/操纵/关闭一个消息通道

    通过向 MCDA 寄存器写目的 IP 并将主机端口写入 MCP 寄存器，来打开消息通道，只允许主程序打开。其他要求与打开流通道类似。

    如果请求超时，设备需重传相同消息，重发次数存在 MCRC 寄存器中，若该值为 0 ，则不允许重传。通过设置 MCTT 寄存器的 ACKNOWLEGDE 位来控制是否支持产生应答消息。当 MCP 值非 0 时，MCSP 必须返回一个非 0 值对应 GVSP 发送端流通道的源 UDP 端口。只要其对于控制会话的持久不变，其值在先前的任何时候为非 0 值也依然有效。当 MCSP 为非 0 值时，若所有的 UDP 流量来自于设备 MCSP 端口的 MCDA 和 MCP 寄存器列表中的地址和端口，其与一个 EVENT_ACK 或 EVENTDATA_ACK 消息不匹配时，设备必须默认将其丢弃。关闭操作与流通道类似，但消息通道是写 MCP 来关闭的。此时，如果在设备端正准备发送一个分组，则其应该被完整发送，但若程序端收到一个消息时，就应该丢弃它。

异步事件

    设备可以在消息通道上发送异步事件消息。每个事件都用一个 16 位的 ID 来表示。本文档定义了两类事件：

• GigE Vision 标准事件（值 0 ~ 36863）
• 设备特定的事件（值 36864 ~ 65535）

    制造商特定的寄存器用于启用/禁用这些事件。XML 设备描述文件描述了要启用/禁用的事件、其索引和寄存器。请注意，即使是标准事件，也可以使用制造商特定的寄存器来启用/禁用。

组播

    当消息需要发送到多个地方，即可使用组播，此时不允许发送应分组。当在 MCDA 寄存器的一个组播选项中设置了设备目的 IP，即可激活组播，此时，MCTT 必须置 0 以禁用应答。

穿越防火墙或NAT设备

    与流通道采用的机制相同，不过其中的源端口在 MCP 寄存器中指定，目的端口则在 MCSP 中指定。

消息通道字典

    程序读消息通道数寄存器来验证消息通道是否有效，在打开该通道前，应检查该寄存器 27 位和 28 位以确定设备是否支持 EVENT 和 EVENTDATA 。通过写可用寄存器位来控制相应的事件或事件组是否启用，应在 XML 描述文档中提供该寄存器。

1. EVENT
       设备使用 EVENT 消息通知程序发生了异步事件，可在该消息中串联多个事件，且全部分组大小必须 ≦ 576 字节。
   （1）若使用 16 位 block_id，消息中事件数量 = 消息头“length feld/16”;
   （2）若使用 64 位 block_id64，消息中事件数量 = "lengih field/24”。
      
   每个 EVENT 命令必须贴上 64 位时间戳 timestamp，表示设备上生成的事件时间。
   （1）值范围在 0-36863 的时间标识符保留给 GigE Vision 使用，
   （2）其中 32769-36863 的事件用于设备异步地报告一个错误，
   （3）36864-65535 的事件与具体设备相关，在 XML 描述文档中定义。
      
   EVENTCMD：主要包括标志位、事件 ID、流通道索引、block_id 和 block_id64、时间戳信息。
      
   EVENT ACK：不要求设备请求一个应消息。

2. EVENTDATA
   与 EVENT 作用类似，不同在于可以将与设备相关的数据附加到 EVENTDATA 消息，且不能将多个事件串联进一个该消息命令中，只能存储 1 个事件。
      
   EVENTDATA CMD：与 EVENT_CMD 类似，但多了一项 data，表示原始数据，在 XML 设备描述文档中指定：
      
   EVENTDATA_ACK：与 EVENT_ACK 类似。

（4）多网络接口设备

影响控制通道

    程序必须在设备接口 #0 上实例化该通道，并获得设备控制权；设备不能回应来自非 #0 接口的 GVCP 请求，该报文默认被丢弃。

影响流通道

    在指定流通道上输送数据时，GVSP 发送端必须使用相应的 SCPx 寄存器 network_interface_index 字段指定的网络接口；如果 GVSP 接收端是一个设备，则在指定流通道上接收数据时，也必须使用上述接口，如果不是设备，则不需要实现引导寄存器。由于 #0 是唯一支持 GVCP 的接口，故程序必须在其上发送 PACKETRESEND_CMD 命令，该接口存放在 SCPx 的 stream_channel_index 字段。

影响消息通道

    如果支持该通道，则其必须在接口 #0 上实例化。

三、其他

2.3.1 获取 XML 设备描述文件

    每个设备必须有一个 XML 设备描述文件，程序必须支持无压缩（xml）和压缩（ZIP）的 XML 文件，支持压缩算法 deflate 和 store 。XML 文件可从下面三种位置中找到：

1. 设备非易失内存：URL 格式 “local:<filename>.<extension>;<address in hex>;<length inhex>，文件名格式推荐用设备提供商_设备名_修订版本”。
2. 供应商网址。
3. 程序所在机器的本地路径：格式 “local:<filename>.<extension>”。
   程序使用 READMEM 命令读取一级 URL 和二级 URL 寄存器存储的 XML 文件 URL，设备必须按 32 位字长对齐 XML 文件的起始地址，以简化使用 READMEM 检索过程。该命令在 GVCP 中是强制性的，使用 READMEM 方法十分类似于 TFTP 协议。清单表：表中每个条目表示 XML 文件及其基于 GenApi 方案的版本号，以及一对 URL 寄存器的地址，清单表只支持 GenICam XML 文件。

2.3.2 设备同步

    IEEE1588-2008 原理：使用精确时间协议 PTP 同步时钟。IEEE1588 网络使用一个最佳主时钟选择算法，使设备可以选择具有最高精度的时钟作为超级主时钟。IEEE1588 基本理念即相互交换时间戳报文，即发送端和接收端记录各自精确的发送和接收时间，接收端可以根据发送端的时间戳信息计算本地时钟的漂移、延时和偏差，并用于将本地时钟调谐和同步到超级主时钟。

时间戳同步：方法是将 IEEE1588 时间映射到 GigE Vision 时间戳计数器。IEEE1588 定义了三种计数器来存储和传输时间信息，结构表示如下：

    epoch_number 在 seconds 计数器滚动溢出时增加，与其结合表示全部秒数；seconds 是时间戳的整数部分（单位：s）；nanoseconds 则为小数部分（单位：ns），如果其值为负，则表示一个早于纪元的时间。整个结构可支持 PTP 和 ARB 时间刻度。若设备支持 IEEE1588-2008， 则必须禁用时间戳控制寄存器的重置位。该标准可与 GieE Vision 实现时间格式相互转换。

IEEE 1588 配置：定义了可在运行时配置的选项，以调整系统的行为。IEEE1588 状态寄存器（接口中描述）包含该标准的时钟状态信息。

IEEE1588配置文件：用于支持 IEEE1588 的设备或程序。在这种情况下，该设备必须也支持采用延时请求——响应机制的 PTP 配置文件。

2.3.3 动作命令

2.3.4 主程序切换

2.3.5 GVCP 头

1. 命令头：共 8 字节。一个命令消息的接收者应对命令头执行最小化验证，即只验证该分组头字节 0x42 键是否存在，没有该键的分组不是 GVCP 报文且默认丢弃；如果该命令的接收者不支持 command 字段的命令请求，则接收方在请求一个应答时应该返回一个 GEV_STATUS_NOT_IMPLEMENTED 状态码；若命令消息头的其他字段无效，应返回一个 GEV_STATUS_INVALID_HEADER 状态码。

2. 应答头：共 8 字节。应报文的接收方应该对应头执行最小化验证，包含对于先前发送的 req_id 进行回应的 ack_id 验证，但其也包含 acknowledge 字段所列值的验证。

2.3.6 字序

    GVCP 必须使用网络字节顺序，即大端存储次序。包头数据发送次序如下：

    按从左到右，从上到下的次序逐个发送字节。使用 socket API 函数实现依赖的标准字节定序函数：ntohl() 将网络 32 位字转换为主机字节次序，htonI() 作用与前者相反，ntohs() 和 htons() 与上面对应，但是针对 16 位字的。

2.3.7 命令与应答值

    本说明定义了每个消息相关的数值，共 21 个命令与应答值。对于 GVCP，值为 0-32767 与设备相关的消息，值为 32768-65535。应报文的值总是比与其相关的命令报文（如果存在）值大 1 。

2.3.8 状态码

    在一个应答报文或 GVSP 头中返回某个状态码，该说明定义了两种状态码：标准状态码和设备相关状态码。例如，在 GVSP 发送的一块内存或数据溢出错误，应发送一个数据追踪包，并将其 status 字段设为 GEV_STATUS_DATA_OVERRUN 。

    状态寄存器映射如下：

2.3.9 事件

    若支持消息通道，必须使用 EVENTDATA 命令（若支持）发送事件数据标识符。

2.3.10 ICMP

    Echo 应答、Echo 和目的地址不可达为强制规范，其余可选。例如，设备需支持分组可达 576 字节的 “ping” 命令，因此，设备必须正确接收一个 ICMP Echo 报文，且正确发送一个 ICMP Echo 响应报文。

    关于目的地址不可达报文必须依据 RFC 推荐来管理，如一个设备接收一个软件错误时不能关闭连接，因为还要考虑接收硬件错误的情况。

   
 

☆

这篇关于GIGE 协议摘录 —— GVCP 协议（二）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---