GigE Vision 20说明书.docx
《GigE Vision 20说明书.docx》由会员分享，可在线阅读，更多相关《GigE Vision 20说明书.docx（29页珍藏版）》请在冰豆网上搜索。
GigEVision20说明书
引言
GigEVision是一种通信接口标准，可用于各种网络拓扑上的视觉软件与视频流设备间的交互。
该标准是基于UDP/IP协议体系，并构成了GigeVision协议（工作在应用层，包括GVCP和GVSP两个协议）。
需要的设备包括IP网络上各种软硬件摄像机、处理器、路由器等。
本说明中，设备指的是一个GigEVision兼容的可控设备，而应用程序指运行在一台主机上的一个与GigEVision兼容的控制程序。
本说明分三部分，即设备发现、GVCP协议和引导寄存器，分别在对应的章节中介绍。
第1章设备发现
PC在接入设备时，需要一种机制发现设备，即链路选择、IP地址配置、设备枚举。
1.1链路选择
设备在接入PC后，需要确定所有通信链路哪些是可用的，然后与PC端协调选择相应速率的链路。
共提供了4种不同类型的物理链路配置：
①单链路配置SL
②多链路配置ML
③静态链路聚合组配置sLAG
④动态链路聚合组配置dLAG
其中，头2个配置中，每个物理链路接口都有1个不同的IP地址；对于后2个配置，物理接口经过重组后，只有1个IP地址在程序中可见，物理链路的分组在MAC层执行，对于应用软件是透明的。
1.1.1单链路配置
最简单的配置，所有的流通道加到一个有效物理链路上，所有设备必须支持SL配置。
1.1.2多链路配置
一个设备必须最多支持4个不同的网络接口。
接口#0（唯一支持GVCP）为主接口来控制设备的控制与消息通道，如设备发现总是在#0上执行，以确保设备使用不同的IP地址而不被多次发现。
其他接口只支持附加的流通道，如发送或接收GVSP数据包。
只能在#0中使用FORCEIP消息，其他接口必须使用静态IP、DHCP或LLA来获取其IP配置信息。
可以认为ML配置中的一个链接就是一个LAG。
若支持多链路配置，必须在SCPx寄存器中指定流通道使用的具体接口，其network_interface_index字段在流通道与网络接口间提供了映射机制，如果映射采用硬编码，则该字段只读。
允许将每个网络接口视为一个不同的GigEVision设备，则每个接口是独立的且具有合适的资源，这等价于将多个设备组合成一个单元。
负载平衡：
网际协议IP会设计好一个路由使数据包到达接收端的正确接口上。
在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顺序启动的流
升级会员 