GIGE 协议摘录 —— GVCP 协议(二)(下)

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
云防火墙,500元 1000GB
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: GIGE 协议摘录 —— GVCP 协议(二)

GIGE 协议摘录 —— GVCP 协议(二)(上):https://developer.aliyun.com/article/1598395

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)

  1. 流通道源端口寄存器(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 推荐来管理,如一个设备接收一个软件错误时不能关闭连接,因为还要考虑接收硬件错误的情况。

目录
相关文章
|
网络协议 算法 数据库
计算机网络实验(华为eNSP模拟器)——第十四章 RIP协议和OSPF协议
计算机网络实验(华为eNSP模拟器)——第十四章 RIP协议和OSPF协议
计算机网络实验(华为eNSP模拟器)——第十四章 RIP协议和OSPF协议
|
3月前
|
传感器
GIGE 协议摘录 —— GVSP 协议(三)(上)
GIGE 协议摘录 —— GVSP 协议(三)
166 1
|
3月前
|
存储
GIGE 协议摘录 —— GVSP 协议(三)(下)
GIGE 协议摘录 —— GVSP 协议(三)
82 1
|
3月前
|
传感器 XML 编解码
GIGE 协议摘录 —— GVSP 协议(三)(中)
GIGE 协议摘录 —— GVSP 协议(三)
88 1
|
3月前
|
监控
GIGE 协议摘录 —— GVCP 协议(二)(上)
GIGE 协议摘录 —— GVCP 协议(二)
114 2
|
3月前
|
存储 网络协议 Linux
GIGE 协议摘录 —— 设备发现(一)
GIGE 协议摘录 —— 设备发现(一)
82 3
|
3月前
GIGE 协议摘录 —— 引导寄存器(四)(下)
GIGE 协议摘录 —— 引导寄存器(四)
41 1
|
3月前
|
存储 XML 前端开发
GIGE 协议摘录 —— 引导寄存器(四)(上)
GIGE 协议摘录 —— 引导寄存器(四)
42 1
|
3月前
GIGE 协议摘录 —— 引导寄存器(四)(中)
GIGE 协议摘录 —— 引导寄存器(四)
43 1
|
设计模式 缓存 网络协议
Linux网络编程 --- 以太网帧格式简析
Linux网络编程 --- 以太网帧格式简析
137 0