GigE Vision 20说明书Word文档下载推荐.docx

GigE Vision 20说明书Word文档下载推荐.docx

《GigE Vision 20说明书Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《GigE Vision 20说明书Word文档下载推荐.docx（29页珍藏版）》请在冰豆网上搜索。

在ML中，为达到负载平衡，可分别将多个流通道一一关联到不同的链路，以平衡这些链路所需的整体网络带宽。

1.1.3链路聚合组配置LAG

IEEE802.1AX标准规范了LAG的相关特性。

该标准下的电缆以太网交换机遵守IEEE规范，这样可能不会平衡负载GEV流输送到多个外向端口上，这些端口通常使用Ethernet帧的头部信息（有时为IP头）来作为其分配算法的输入参数，这些交换机在GVSP中是不可见的。

由于LAG显示单个MAC/IP，这些交换机不能指出怎样去分配GVSP输送，可能在某交换机的一个外向端口上就停止输送了。

网络接口：

只允许有一个聚合器，因此，所有与LAG关联的活动链接均绑定到该聚合器上。

若支持链路聚合配置，设备只允许静态和动态LAG两个配置中有一个聚合器，且其应该使用与LAG相关的具有最小编号物理网路接口的MAC地址。

故在引导寄存器中，只有一个“虚拟”网络接口可见。

GVCP影响：

一个GVCP通道必须总是在LAG同一物理链路上被发送。

GVSP影响：

定义比较宽松，使用round-robin分配算法平衡网络负载。

首个流数据包可以在该聚合器的任意接口上传送，也可在新的数据块边界上重启一个round-robin新循环。

静态LAG和动态LAG：

两者唯一区别在于IEEE802.1AX的LACP协议的使用。

静态LAG用于增加流的有效带宽，假定这些链路的所有电缆走向同一目的地（如多端口NIC）；

但如果布线不正确，LACP协议用来确保系统能正确绑定属于同一互连的物理链路，对于动态LAG，其保证了一个聚合器中所有链接都在同一伙伴间。

LAG事件：

由于聚合组中的一个物理链路连接上或断开，而引起聚合速度改变时，设备应发送一个GEV_EVENT_LINK_SPEED_CHANGE事件。

1.2IP地址配置

该过程即分配一个IP地址给设备。

GigEVision设备支持DHCP、LLA和静态IP（可选）三种方式分配IP。

该配置在设备启动或重启时执行。

1.2.1协议选择

每个IP配置协议的执行顺序必须是静态IP（若支持并启用）、DHCP（若启用）和LLA。

出厂默认静态IP禁用，DHCP启用，LLA一直可用。

1.2.2静态IP

静态IP相关的信息必须存储在设备的非易失内存中，如果没有该内存，则不能支持。

如果设置的IP与同一网络上的设备IP冲突，设备就不能使用该IP地址并应告知用户，这时，设备必须使用下一个IP配置方案。

RFC5227文档使用ARP协议来探测静态IP地址，以检测是否有潜在的冲突。

如果分配的IP地址不能识别，程序可修改引导寄存器的静态IP信息，设置为一个有效的状态或简单禁用静态IP。

1.2.3DHCP

一个DHCP可用标志存储在非易失内存中，如果没有储存介质，设备必须决定DHCP是否可用。

设备应支持DHCP选项：

子网掩码和路由选项。

DHCP重传策略：

使用DHCP，设备发送一个DHCPDISCOVER消息，DHCP服务器返回一个DHCPOFFER消息；

设备发送一个DHCPREQUEST消息，服务器返回一个DHCPACK或DHCPNAK消息。

若设备没有从服务器接收到任何回应，需要重传上述消息，至多允许2次重传（因为最坏情况下设备分别发送3个上述消息）。

如果没有DHCP服务器可用，设备在DHCP阶段一般会等待12s。

DHCP租借到期：

设备停止使用IP地址，并重启IP配置循环。

1.2.4链路本地地址LLA

即私有IP。

IP地址范围从169.254.1.0--169.254.254.255。

必须一直被激活。

1.3设备枚举

在设备获得一个IP后，PC端程序需要收集网络上所有设备相关信息，如设备id、制造商、制造日期等。

通过单播或组播UDP命令方式分别得到已知或未知IP的设备信息，并使用GVCP协议实现信息交互。

GigEVision提供2种机制来枚举设备：

GVCP设备发现（强制性）和组播DNS/DNS服务发现（可选）。

1.3.1GVCP设备发现

非强制性（有利于最小化带宽使用）。

如果设备没有完整的IP配置，则不能回应任一程序发出的设备发现请求消息，否则，在获得一个有效IP地址后，必须回应。

广播设备发现：

UDP广播消息，目的IP地址255.255.255.255，该消息不经过路由器。

若程序在一台多宿主机上，存在多个网卡，则可以使用一个子网定向广播。

在回应报文中，设备必须设置源IP地址、子网掩码和默认网关信息，这些在IP配置时已获得。

单播设备发现：

仅当设备IP地址被程序已知才使用该方式。

可直接发送一个UDP数据包到该设备IP地址。

设备对该类型消息必须返回一个单播回应报文给发送消息的程序。

将设备关联到枚举表：

为方便将一个设备关联到设备发现列表的对于条目中，设备外壳上应有一个序列号和MAC地址标签。

1.3.2零配置发现

结合组播DNS和DNS服务发现。

该机制将“主机”与“服务”这两个概念分开。

一个服务有3个主要部分：

类型（GVCP固定）、名称（识别特殊实例）及服务运行的UDP/TCP端口。

服务可以拥有一个包含特殊实例详细信息的唯一TXT记录表。

在GigEVision上下文中，每个服务实例对应一个GVCP控制通道。

标准设备：

通知具有一个服务的单台主机。

带链路聚合的标准设备：

同上，多路连接可视为一个逻辑连接。

带多链路无连接聚合的标准设备：

通知具有多个IP地址及一个服务的单台主机，并映射到ML配置。

要求程序决定连接哪一个链路，该实现已定义了。

单链路的多控制器设备：

通知具有多个GVCP服务的单台主机，每个服务被视为一个共享同一物理接口的SL配置。

在同一以太网端口和IP地址之后的所有独立的GVCP栈共享同一IP地址，因此，如果程序改变了一台设备的IP，其他台上的IP也会跟着变化。

多独立链路多控制器设备：

每条链路通知一个对应不同的主机，每个主机通知单个服务。

一般来说，每条链路只响应与该链路相应的唯一主机/服务名相匹配的查询，故在链路另一端的主机只能看到其连接上的接口，且能够通过特定链路降低可获得的服务数量。

这映射到一个SL配置中，但每个服务有一个不同的物理接口。

组播DNS（mDNS）：

查询类型如A/AAAA记录（IPv4/IPv6名称解析），查询服务为SRV记录。

在组播DNSInternet草案中，为mDNS分配的IPv4组播地址为224.0.0.251，IPv6链路本地组播地址为FF02:

FB，使用UDP端口5353，仅用UTF-8编码资源记录名，采用DNS顶级域名“.local.”。

设备主机名由设备制造商名+设备名+设备MAC地址（大写十六进制）+"

.local."

构成。

DNS服务发现：

使用DNS来查找特定的服务名称。

主要任务是列举服务名称列表，及将服务名翻译成相关联的IP地址。

合法的服务名需为“_gvcp._udp”。

若支持DNS-SD，其TXT记录必须至少支持如下键：

规范版本号、设备模式、MAC地址、设备供应商名、模型名、具体制造商版本信息、具体制造商串名、序列号、自定义名和实例号。

1.4设备添加与删除

程序应能够动态响应设备网络拓扑结构变化（在网络上添加或删除一个设备）。

1.4.1删除

现场删除主要由控制协议处理，然后程序暂停其发送的消息命令，或者一个控制与接收程序可暂停不再到来的GVSP发送端视频流。

1.4.2添加

有三种方法：

①程序发送DHCP请求给服务器，后者做出响应并通知添加设备的程序，但要求客户端与服务器端联系密切；

②程序定时发送一个DISCOVERY命令，但这会消耗一定的网络带宽，尤其是每次有很多设备需要回应，一种解决方案是提供给用户一个控件来刷新设备列表；

③执行组播DNS或DNS服务发现来发现新设备。

除了网络带宽要分配给新设备外，原来的设备不受新添加设备的影响。

第2章GVCP协议

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

2.1基本概念

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

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

GVCP是基于UDP无连接服务的，因此，设计了消息重传机制。

消息重试次数可以由用户设定，默认值为3。

req_d≠0，在控制通道关闭后，其值会被初始化。

此外，还启用了端到端连接，通过设置心跳计数来侦听链路是否断开。

同理，其值是可以自定义的。

一般来说，应用程序端的心跳频率应略低于设备端的1/3，这样可以在UDP包发送丢失时排除心跳因素的干扰。

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

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

2.2通道

通道即虚拟连接。

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

2.2.1控制通道

分两种类型：

主控制通道和第二控制通道。

在消息或流通道创建前，必须实例化一个控制通道。

例如，有程序请求对一个寄存器进行写操作，以实现一个图像捕获，设备应该在寄存器被写入时返回一个响应，而不是捕获已完成时。

特权：

独占访问，通过写CCP寄存器授权访问。

主程序能对设备进行读写，其他程序则不能，也不允许创建一个第二控制通道，除其发送的DISCOVERY_CMD、FORCEIP_CMD等少数命令，其他命令请求设备一概返回一个错误；

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

具备切换能力的控制访问，与控制访问不同在于，该模式允许具有正确凭据的程序控制设备；

监控访问，条件最弱，一般用于调试帮助。

只要无独占访问的程序连接设备就可以读该设备。

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

在程序端使用一个动态端口号（任意），设备端使用标准GVCP端口（除非通过mDNS通告了一个不同的端口）就可以创建控制通道，再通过GVCPDISCOVERY命令创建链接。

在软件开发阶段，对设备使用非独占方式访问，有助于其他调试工具监控该设备。

寄存器：

控制通道特权寄存器；

控制切换键寄存器；

心跳超时寄存器；

待定超时寄存器。

打开/关闭控制通道：

程序通过对CCP寄存器写请求特权，并检查设备ACK消息返回的状态，根据状态码内容决定是否有打开通道的资格。

允许主程序在不关闭控制通道时请求相同的特权类型，如可通过写CCP寄存器来直接切换到另一控制特权。

通过对CCP寄存器写0来关闭通道，并释放主程序的特权。

控制通道心跳：

使用心跳序列可以定期检测控制通道是否处于活动状态，心跳速率是可自定义的，默认每秒1次。

设备在接收到主程序任一有效命令后，必须重置心跳计数，少数命令除外，如ACTION_CMD。

心跳计数可通过读CCP寄存器来重置，且只能由主程序执行。

若设备在超过用户设置的心跳超时时间（默认3秒）后，且没有禁用心跳性能寄存器，仍没有收到一个控制消息，则必须断开控制通道。

如果主程序不能读CCP寄存器或读取非预期数值时，即可判定链路断开，此时，必须实例化控制通道以建立与设备的新链接。

设备控制：

主程序可以在打开通道后，发送任何受GVCP支持的命令，二级程序可发送READREG和READMEM命令读取设备速率。

DISCOVERY、ACTION和PACKETRESEND命令可以在任何时间由任一程序发送，且设备总是在收到后返回一个ACK消息。

使用待定应答：

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

①执行一个请求所需的最大执行时间；

②当请求执行时间将超过①中的值，使用使用PENDING_ACK消息通知程序使其可以等待额外必需的时间来完成该请求。

PENDING_ACK的ack_id值与程序初始请求的req_id值相同。

若设备支持该消息，则必需在一个PENDING_ACK和ACK命令发出之间响应DISCOVERY_CMD，且不能用该消息响应一个DISCOVERY_CMD、FORCEIP_CMD和PACKETRESEND_CMD。

控制通道字典

如果一个控制报文所在请求端没有所需特权，设备则返回一个只含包头的应答报文，其status字段必须为GEV_STATUS_ACCESS_DENIED，length字段值为0。

下面列出了在通道中各种类型的控制消息。

①DISCOVERY

DISCOVERY_CMD：

8字节，其中8-15位表示flag，其第3位说明设备是否允许广播其应答报文，ACKNOWLEDGE位（第7位）须设置；

DISCOVERY_ACK：

如果设备与程序在同一个子网，则必须单播一个该报文。

如果DISCOVERY_CMD报文并没有在设备所在子网接收，或者上段提到的flag字段，设备应该广播该报文。

当设备的静态IP与程序所在的子网IP不匹配时会发生。

如果flag第3位清零且设备与程序不在一个子网段，则设备对程序是不可见的。

其他说明见3.1.34节的DiscoveryACKDelay引导寄存器。

②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位时，设备应广播此应答消息。

③READREG

程序通过发送READREG消息来读设备寄存器。

可以在一个消息上串联多个读，只要其分组总大小≦576字节。

设备必须顺序执行这些读命令。

在GVCP性能寄存器的31位指示了是否可串联多个寄存器读操作（最多135个）。

若发生一个错误，读操作必须在错误发生的位置停止，并丢弃剩下的读操作，在应答消息中返回适合的错误码。

若无独占访问，设备须响应任意程序的该消息，否则，只响应主程序的消息，二级程序的消息则返回一个访问拒绝状态码，并将应答消息的length字段置0。

推荐读操作不修改当前寄存器的内容，这应由写操作实现。

READREG_CMD：

要执行的读操作数=该命令头的length字段值/4（每个寄存器提供4字节）；

READREG_ACK：

该应答消息长度必须反映成功读取的字节数，其长度必须是4字节的整数倍。

从其length字段可知成功读取了的字节数s_read，相应的读操作数，即有效数据负载部分寄存器数量=s_read/4。

④WRITEREG

与READREG命令类似，最多支持串联67个寄存器。

除发生主程序切换请求情况，只有主程序才可以发送写命令，相应设备也必须回应该命令，否则，对于二级程序设备须返回一个写拒绝状态码（也包括其没有正确的凭据）。

当没有主程序关联要写的设备，任何程序均可以写其CCP寄存器以获取独占或控制访问（含切换），获得独占或控制授权后，其他程序则不能写，切换式控制除外。

WRITEREG_CMD：

至少指定一个寄存器地址，要执行的写操作数=该命令头的length字段值/8；

WRITEREG_ACK：

其中的index字段指示了成功完成的写操作数，值67；

如果写操作时发生错误，该消息会给出表中发生错误的寄存器索引值（0-66），程序即可知成功执行了哪些写操作及每个操作关联的状态码。

若WRITEREG操作失败，该消息的status字段表示失败原因。

⑤READMEM

该消息用于读取设备连续8位的位置，有助于读取XML描述文档位置或一个机载XML描述文档。

若该位置数非4的倍数或该命令指定的地址没有按32位字长对齐，设备会返回一个无效对齐状态码。

可用一行READMEM命令读取的最大内存大小为536字节。

关于设备访问特权，与READREG情况类似。

READMEM_CMD：

其address字段表示要读的设备内存地址（32位对齐），对于连续数据，地址自动增加，count字段表示读取的字节数（必须是4字节倍数）；

READMEM_ACK：

其data字段表示从寄存器读取的8位数据，从设备内存按字节拷贝到该寄存器。

若设备不支持所请求的地址时（READMEM失败），设备返回一个合适状态并将length字段置0。

⑥WRITEMEM

程序应检查GVCP性能寄存器的30位确定设备是否支持该命令。

其他与READMEM类似。

WRITEMEM_CMD：

与READMEM_CMD类似；

WRITEMEM_ACK：

与WRITEREG_ACK类似，除了索引范围为0-535。

⑦PACKETRESEND

表示请求重发丢失的分组，可异步执行，有利于流数据的快重传。

在GVCP性能寄存器的29位指定设备是否支持该命令。

程序不能请求一个该命令的应答，故必须将GVCP头的ACKNOWLEDGE位清零。

设备需对该消息进行处理。

重发的GVSP分组被发送到SCDAx寄存器指定的IP地址，即初始GVSP分组使用的目的IP。

PACKETRESEND_CMD：

其中的last_packet_id值为0xFFFFFF（packet_id）或0xFFFFFFFF（packet_id32）时，表示重发从first_packet_id字段指定的分组一直到该数据追踪器；

PACKETRESEND响应

不存在PACKETRESEND_ACK！

（GVSP接收端的程序不允许请求一个重发分组的应答消息）

标准ID模式下的分组重传：

如果GVSP发送端工作在该模式下，其重发请求包或分组时，使用GEV_STATUS_PACKET_RESEND状态码表示该程序已使该发送端可以使用扩展状态码；

如果发送端不能重发分组数据，则必须发送只包含头（无数据）的流数据分组，并将状态码设置为4种原因标识，后者可通知GVSP接收端其请求的分组不再有效。

扩展ID模式下的分组重传：

与标准ID模式相比，该模式特点在于，若GVSP发送端可重发分组，必须设置GVSP分组的flag字段的GEV_FLAG_PACKET_RESEND标识（15位），表明该分组是一个分组重发请求结果；

若不可重发，则只发送仅包含头的分组，且其packet_format字段值为"

dontcare"

，并返回5种状态码，在标准模式基础上多添加了1个条目。

GVSP接收端分组重传处理：

需要GVSP接收端程序快速发送PACKETRESENF命令，以防要重传的分组在发送端中丢失。

一些网络拓扑保证了UDP分组按序到达，但UDP分组在传输中若存在多条路由（存在网关和路由器），则不能保证按序到达。

对于前者，GVSP接收端程序可使用分组ID向下跟踪包序列，如果某个包ID跳过了，程序立即请求重发丢失分组，可以使用超时器检测数据跟踪是否丢失；

对于后者，程序不能确定分组ID值是有序的，因此需要一个分组重传机制，可以有多种，如使用超时方案。

⑧PENDING

该消息表明一个命令需要更长的时间执行，其不能影响网络中其他程序进行设备枚举过程。

在PENDING_ACK发出后，需暂停设备的心跳超时计数器，直至发送一个ACK命令。

PENDING_ACK设置的超时时间或许比心跳超时要长些。

PENDING_ACK：

其中的time_to_completion字段表示完成待定请求需要的毫秒数，程序收到该消息后，可重置应答超时=该字段值+网络延时。

该字段长16位，最大超时65s。

如果设备不能在该时间内完成，允许再发送一个PENDING_ACK，数量不限。

⑨ACTION

程序应检查GVCP性能寄存器的25位确定设备是否支持该命令，检查14位确定设备是否支持预定的动作命令。

可向设备单播或广播该命令以触发各种动作。

可同时向一个子网内多台设备发送同一动作，设备根据请求特点决定触发哪种动作，动作执行有可能在之后被延误。

ACTION_CMD：

包含标志位、设备键、组键、组掩码（具体在2.3.3节介绍）和执行时间（可用性与flag相关，当指定一个后来的动作时间时，该字段唯一表示预定动作命令）。

该命令可由主程序或二级程序单播或广播；

若设备时间戳与该请求命令指定的动作时间相同时，设备需将其入队等待执行；

否则该动作命令的时间<

设备的时间戳，并且其是一个有效动作命令，则：

设备必须立即执行该命令（无需入队），并返回一个动作迟到的状态码（如果请求一个ACK），若消息通道以打开，则应该发送一个动作迟到的事件。

ACTION_ACK：

设备仅在执行ACTION的条件满足时返回该动作，且当其是一个预定动作命令时，一旦入队等待执行时，必须尽快发送。

在某个时间段内（不确定）不阻塞控制通道前提下执行。

2.2.2流通道

允许使用GVSP协议使数据从一个GVSP发送端转移到接收端。

若产品支持GVSP流则必须支持从索引0顺序启动的流