Gigabit Ethernet standard is coming to life

The most recent revision of the GigE standard for machine vision offers an application-layer protocol and support for UDP.

By Andrew Wilson, Editor

For two years, the GigE Vision Standard Committee of the Automated Imaging Association (AIA; Ann Arbor, MI, USA; www.machinevisiononline.org; see Table 1) has been developing the Gigabit Ethernet vision interface standard for machine vision. The latest revision of its proposed standard, Version 2.3.1, only available to members of the standard committee, shows how far along the effort has progressed.

“GigE cameras are Internet Protocol devices and make good use of existing IP standards. But, ultimately, this is a standard for ‘Gigabit Ethernet’ machine-vision cameras; they simply are not expected to function well when bridging across link layer networks. This standard is for machine-vision cameras on local Ethernet networks and will serve the machine-vision market well,” says David Lee, software architect at Prosilica (Burnaby, BC, Canada; www.prosilica.com).

The standard has three main elements:

• The GigE Vision Control Protocol (GVCP), which defines how to control GigE Vision-compliant devices (that is, cameras) and specify stream channels and provides a mechanism for cameras to send image and other data to a host
• The GigE Vision Stream Control Protocol (GVSP), which defines data types and describes how images are transmitted over GigE
• The GigE Device Discovery mechanism, which defines how compliant devices, such as cameras, obtain IP addresses and how applications control the devices on a network.

Like all Ethernet standards, the AIA preliminary standard does not cover the physical description of the transport media or any specific implementation of a specialized IP stack or network driver.

Vision applications send messages or streams of data to Internet transport- layer protocols, using either UDP or TCP. These receive the data from the application, divide the information into packets, add a destination address, and pass the packets along to the Internet Network that encloses the packet in an Internet Protocol (IP) datagram, puts in the datagram header and trailer, decides where to send the datagram and passes the datagram to the network. This accepts IP datagrams and transmits them as frames over network hardware, such as Gigabit Ethernet. The layer diagram highlights TCP, but the GigE Vision Standard uses UDP. Additionally, the “Data” in the TCP packet contains the GigE Vision Standard Protocol, which includes image/control header information.

APPLICATION LAYER

GVCP is an application layer protocol that allows applications to configure cameras and specify stream channels and lets cameras notify applications when specific events occur. GVCP provides support for one application to control a camera, but also allows many applications to monitor the camera.

The application is thus the master, the device is the slave, and command requests are initiated by the application software. Command and acknowledge messages are each contained in single packets, and the application software must wait for the acknowledge message before sending the next command message. This creates a very basic handshake, with the acknowledge message providing feedback that the IP device received a command.

Currently, GVCP runs on top of the User Datagram Protocol (UDP) IPv4, one of several transport protocols operating at Layer 4 of the seven-layer IP stack. UDP delivers efficient transfer performance, but does not guarantee data delivery. To address this limitation, GVCP defines mechanisms to guaranty reliable packet transmission and ensure minimal flow control. The confinement of command and acknowledge messages to single packets is one example of how flow is controlled (see figure on p. 43).

“The command mechanism uses a simple command-reply architecture. UDP is ideally suited to GVCP (by no coincidence). The command is sent, and, if a reply is not received in a timely fashion, the command is sent again,” says Lee.

GVSP also uses UDP, in this case to receive image data, image information, and other data from a camera or other device. In the latest revision of the standard, GVCP defines the maximum packet size used by GVSP, allowing it to be tailored to the user’s requirements. To avoid IP fragmentation and ensure data transfer through the LAN, the user’s application must negotiate packet size with the device. The do-not-fragment bit in the IP header can be used to ensure packets remain intact during transmission across a network.

With GVSP, streamed data such as data types, images, and image statistics can be transmitted over the GigE link. However, transmission of multitap sensor data is not fully described in the preliminary release, so multitap cameras must perform image data re-ordering before sending data to the host. Although multitap devices can output each tap on different stream channels, application software must reconstruct the image from these streams. But this is true only if the camera has not done the reordering first.

“It is intended and is more efficient for multitap GigE cameras to perform tap reconstruction before they send the data,” explains George Chamberlain, president of Pleora Technologies (Kanata, ON, Canada; www.pleora.com).

UNSUPPORTED PROTOCOLS

At present, neither GVSP nor GVCP support the Transmission Control Protocol (TCP) or the Stream Control Transmission Protocol (SCTP). Unlike UDP, TCP and SCTP provide reliable message delivery and ensure data are not lost, damaged, or delivered out of order to the receiving system. Such reliability frees applications programmers from having to build communications safeguards into their software (see Table 2).

“Although TCP validates data transfers, it relies on constant resends to do so. Its transfer performance is inefficient and therefore not suitable for many machine-version applications,” says Pleora’s Chamberlain. SCTP also has its limitations for machine-vision applications. “The overhead for SCTP is slightly higher than that for GVSP. SCTP is also a fixed standard that does not support the simultaneous transfer of vision data to multiple locations,” he says.

According to Version 2.3.1 of the GigE standard, TCP will be supported in future revisions. “This is not universally supported by members of the technical committee,” says Chamberlain, “and is mentioned only to provide guidelines for future compatibility if it is decided to incorporate TCP at a later date.”

At the AIA Vision Show West (San Jose, CA, USA; May 2005), Pleora announced its first product compatible with the nascent AIA standard-an OEM board for in-camera GigE connectivity known as the iPORT PT1000-VB In-Camera Engine.