Recently ratified AIA GigE Vision standard is now a standard interface of many digital cameras.
By Andrew Wilson, Editor
The adoption of Gigabit Ethernet (GigE) by the machine-vision industry has increased steadily since the first products were introduced in 2002 and is now set for rapid expansion. IMS Research predicts that GigE connectivity in vision systems will grow at an annual rate of more than 30% over the next three to five years-faster than any other connectivity protocol.
There are several reasons why GigE is making inroads into the vision market. The 1-Gbit/s bandwidth capacity is powerful enough for about 90% of today’s vision applications, and connections can extend up to 100 m without regeneration. Off-the-shelf GigE equipment offers significant cost savings compared to special hardware, and its flexible networking capabilities pave the way for multi-PC, multicamera installations controlled from a single location.
A key challenge when deploying a GigE system is achieving real-time, end-to-end performance. When imaging data are streamed into the PC, the standard drivers provided by the network-interface-card (NIC) manufacturers cannot handle the task of transferring the data into PC memory in real time at the full 1-Gbit/s line rate.
These software drivers use the delay-prone Windows or Linux IP stack to transfer data into memory. Although this does not necessarily matter when real-time operation is not critical, the limitation can be circumvented through a more efficient NIC driver. Some of these drivers stream image data directly to user memory at the kernel level of the system in real time, thus bypassing the Windows or Linux IP stack process. Since they do not engage the IP stack and use intelligent DMA transfers, these drivers need almost no CPU capacity from the PC.
“While TCP/IP-based systems are connection-oriented protocols that use constant resends to validate data transfers,” says Eric Carey, manager of the smart products group at DALSA, “TCP provides error checking and can control the speed of data transfer. Unfortunately because TCP is connection-oriented, delays will occur whenever an error or packet loss occurs.”
Enter the AIA
Because of this, the Automated Imaging Association (AIA) recently introduced the GigE Vision standard, which uses the User Datagram Protocol (UDP)-a packet-based, connectionless, best-effort method to transmit data. Because it is left to the application to packet the data and provide error checking, The UDP is the fastest way to transmit data. Thus, applications based on the UDP are better suited to machine-vision applications for which meeting any real-time constraints is important.
“GigE Vision is a standard managed by the AIA that provides an open framework for transferring images and control signals between cameras and PCs over standard GigE connections,” says George Chamberlain, president of Pleora. “From day one, GigE Vision was designed to support different performance levels and feature sets so that vendors would have room to innovate and differentiate their products, and vision system designers and integrators would have a broad selection of compliant products with which to work.”
GigE Vision Version 1.0 consists of four main elements: a Device Discovery Mechanism, the GigE Vision Control Protocol (GVCP), the GigE Vision Stream Protocol (GVSP), and an XML description file. While the Device Discovery Mechanism defines how compliant devices such as cameras obtain IP addresses and are identified on the network, the GVCP defines how to specify stream channels and control and configure compliant devices. The GVSP defines how images are packeted and provides mechanisms for cameras to send image data and other information to host computers. An XML description file provides the equivalent of a computer-readable datasheet of features in compliant devices. This file must be based on the European Machine Vision Association’s GenICam standard.
Camera identification
To automatically identify any GigE Vision devices on the network, the Device Discovery software first transmits a broadcast message over the network to find compatible devices. Once found, the devices respond with their IP address, make, model, serial number, and other characteristics. The application can then take control of the device using the GVCP. Of course, for this to operate, the devices need an IP address, and the GigE Vision standards support three methods for camera vendors to achieve this: Dynamic Host Configuration protocol (DCHP), Link Local Address (LLA), and persistent IP addresses.
FIGURE 1. After Device Discovery software transmits a broadcast message over a network to find compatible devices, the GVCP provides a set of commands in a header file to configure the UDP channel, establish control of the camera, and read and write camera registers and memory locations
Once this IP address is identified, the GVCP provides a set of commands in a GVCP header file that are used to configure the UDP channel, establish control of the camera, and read and write camera registers and memory locations. GVCP is also used to control features of the camera such as frame rate, exposure, and I/O response (see Fig. 1). Once this is configured, the GVSP performs image acquisition. To define how data from such cameras are packetized, each packet is identified with a BlockID that associates the packet with a specific image. This BlockID information is also transmitted as a header in the application layer (see Fig. 2).
To allow interoperability between cameras and third-party software, GigE Vision includes an option to use the GenICam standard to provide a single camera-control interface, no matter whether it is the GigE Vision, Camera Link, or 1394 DCAM standard. The first GenICam release features an XML schematic that defines how camera-specific parameters should be presented in an XML description file. To comply with GigE Vision, camera vendors must provide customers with an XML file that conforms to this schematic (see Fig. 3).
FIGURE 3. To allow interoperability between cameras and third-party software, GigE Vision uses the GenICam standard to provide a single camera-control interface, no matter whether it is the GigE Vision, Camera Link, or 1394 DCAM standards.
GenICam also includes a GenApi library-a reference implementation of a dynamic application programming interface that demonstrates how to parse this XML file. Although use of GenApi is not mandatory for compliance with the first release of GigE Vision, many camera manufacturers are incorporating at least some of it in their software development kits (SDKs).
Software for vision
Vision software applications are now available from a number of companies including National Instruments, Matrox Imaging, and Stemmer Imaging, all of which have announced compatibility with the GigE Vision standard. “Because at the time we had no SDK to base our driver development on,” says Rupert Stelz, senior developer with Stemmer Imaging, “the development of a driver for the company’s Common Vision Blox (CVB) software required a little bit more work. To implement the GenICam interface, CVB uses the GenICam Reference implementation as a base and wraps a layer around it that blends the GenICam interface to the CVB interface. We then expose all the GenICam features to the user in the form of an OCX module that allows the user to change settings by point and click.”
Since many vision applications require access to advanced features and capabilities that are not supported through GenICam, developers may decide to use other camera control methods,” says Pleora’s Chamberlain. “Indeed, the use of GenICam is not mandatory for compliance with GigE Vision.”
“While the first version of GigE Vision states that it is the responsibility of the camera to sort multitap data, there are mechanisms in GigE Vision to handle multiple image streams,” says Stelz. “But this would lead to additional load on the host. So far we only have seen GigE Vision devices that deliver aligned and sorted data. Since many of these cameras contain on-board FPGAs, however, it makes much more sense to relieve the host from sorting this data before transmission.
Compatible cameras
Implementing a minimum protocol for interfacing a GigE Vision camera is not a trivial task, particularly if you need reliability and performance. Indeed, of the cameras now available that support the standard, most incorporate Pleora’s iPORT IP Engine to convert video data into IP packets for GigE transport to PCs and to provide serial or parallel control channels for input to cameras. The purpose-built hardware in the engine uses no embedded operating system, improving performance and easing in-camera integration. And because Pleora’s iPORT engines interface natively to almost any analog or digital image data, they have been used extensively by nearly all the major GigE camera manufacturers
(Click links to download the PDF copy of the tables)
Interestingly, Prosilica is one of the few companies that has not chosen this approach. “Prosilica’s GigE Vision data stream is generated 100% in hardware and implemented in an FPGA device,” says Marty Furse, Prosilica president. “These cameras can operate at the full bandwidth of Gigabit Ethernet -125 Mbytes/s.” According to Furse, Prosilica’s GigE Vision cameras also have very low latency. The time between the last active pixel read from the sensor and the last packet sent via GigE is 10 μs. In comparison, the same latency on FireWire cameras is 60 μs on average because FireWire cameras must wait for the next available isochronous cycle. If the host requests that a packet be resent, Prosilica’s hardware engine starts resending the packet within 10 μs of the request.
This is mainly dependent on the network infrastructure and system load, so it difficult to generalize these statements. However, warns Furse, “most of the latency in vision systems, be they FireWire, frame grabber, or GigE based, is found in the driver and application software running on the host.”
GigE compliance
“It is important to note that compliance with the GigE Vision standard means only that products follow a certain connectivity method,” says Chamberlain “It is not a performance guarantee. Compliance does not, for example, mean that a product will operate reliably, recover from packet loss in the GigE connection, deliver deterministic real-time operation, or meet the precisely timed synchronization requirements of multielement applications. As with any other vision product, GigE Vision cameras and PC software must be assessed for reliability and quality of implementation.”
While GigE Vision-compliant cameras can start continuous image acquisition out-of-the-box, functions such as single-frame triggering are not supported by the standard. “However,” says Chamberlain, “many cameras support single-frame capture under GigE Vision, and the standard does not preclude hardware triggering and cameras that use Pleora’s iPORT technology support this feature, as well as single-frame capture triggered from a PC.
“The fact that some may be skeptical about the performance of GigE Vision merely reflects that there is big difference between well-designed products and poorly designed ones,” says Furse. “Not all GigE Vision interfaces are created equal. Developing a GigE Vision camera interface is much more difficult than developing a FireWire or Channel Link interface and not all camera vendors will be successful.” But those that have done so will reap the benefits.
null