When a new market segment is created by way of a disruptive technology or otherwise, companies active within it are inevitably going to be in direct competition with each other. However, situations arise – especially in the high-technology sector – in which competing companies can achieve more by working together, and so standards are agreed upon. Representatives from the 28 companies that constitute the GenICam committee are working hard to ensure that GenICam is the next ubiquitous standard within machine vision. The name GenICam is an abbreviation of ‘generic interface for cameras’, sometimes written as Genicam or GenCam.
The GenICam idea was formed around 2005. The initial goal was to create a standardised camera-programming interface for any kind of camera. Existing connectivity standards such as Camera Link, FireWire and GigE Vision define that there will be transfer, and they define how software should communicate with the camera. Each company has its own way of presenting the camera’s features, and so it is really hard for the customer to go from one system to another without major change. The developers of the standard aimed to find a way for every device to present itself in the same way.
Mats Lindberg is marketing manager of Pleora Technologies, and he chairs GenICam’s marketing subcommittee. He explains why the standard is necessary: ‘Throughout its history, machine vision has been something of a cottage industry in which each player fends for themselves. That was fine in the initial stages when nobody was all that sure what was going on, and when there was no cohesive standard, but the industry as a whole has recognised that in order to grow, and in order to benefit the customers and reduce support costs, some sort of standard had to be in place. Without this standard, growth is likely to be too costly, too time-consuming and too frustrating for everybody involved.’
The first steps towards this goal came in the form of the Gigabit Ethernet connection GigE Vision. The committee developing the GigE Vision standard initially aimed for the same standardised access to camera features, so that all cameras could be configured in the same way. This turned out to be too grand a task, and so the GenICam standard was split off from GigE. GenICam has therefore been well accepted by GigE camera vendors, and the certification criteria for GigE mandates elements of GenICam. Vendors are beginning to apply the standard to IEEE 1394 (FireWire) and USB cameras, with Camera Link cameras likely to follow suit in the future.
Features of GenICam
Currently, the standard is made up of three modules: GenICam application programming interface (GenAPI), the GenICam standard features naming convention (SFNC), and the GenICam transport layer (GenTL).
The GenAPI is a layer of control between the end user’s software and the camera. The GenAPI makes use of an XML file, essentially a simple document, which is stored on every GenICam compliant camera as part of the standard. This XML file states all the rules and features of the camera: how to protect the camera, writing to a particular element, the limits of given values, maximum and minimum values, the step value, and other criteria.
This module of the standard has been in place for some time already, as Lindberg explains: ‘Pretty much every camera manufacturer includes the XML file that’s required for GenICam compliance, and all the software companies which are active in this space reference the GenAPI in their code.’
The second module, the SFNC, is in the process of being finalised by the GenICam committee. As the name suggests, this aspect of the standard consists of an agreement between contributing companies that a particular feature will be given a particular name, as well as a definition of what constitutes a given feature.
The third and most recently introduced module, the GenTL, gives a level of abstraction for device enumeration and image acquisition. GenTL is based on the C++ language, although other languages can be added, and it follows in the native styles of both GigE and the 1394 interfaces by assuming that the camera has a register-based interface.
Jan Becvar, of Leutron Vision, explains that camera vendors write a GenTL ‘producer’ DLL library which understands the technology the camera is using and is able to operate, configure, and acquire images from the cameras connected to the system. This means that software on the other side – frame grabbers or image processing packages, for example – only requires a GenTL ‘consumer’ DLL. ‘The advantage is that you can plug your camera immediately into any supporting software package. If you develop some very specific protocol, it isn’t a problem; you still don’t need to write drivers for software, all you need to do is provide the GenTL producer and [GenICam] will understand automatically.’
Current difficulties
‘The reasons behind the move to the standard are solid, and in most places the move has been well-executed, but there have been some pitfalls as well,’ says Lindberg. ‘It’s been a piecemeal introduction of the standard. GenTL was introduced late in the game; as this is on the driver side of the technology, people developed their own standards and their own products in order to replace the GenTL.’
Confusion over the precise nature of the standard may also have slowed its adoption. ‘There has been some confusion as to what the standard is, what it does, and what it means for the customers; it’s quite a technical concept, and if you have a “Mom ‘n’ Pop” machine vision operation, they perhaps don’t really know what it is, and they don’t understand why they need it or if they need it.’
Vendors developing new cameras understandably aim to do more and more with their cameras, but there are some limitations in that a new feature might not fit into the GenICam model. According to Eric Bourbonnais of Dalsa, 80 per cent of cameras work well, but others have some strange or novel dependency that doesn’t fit. While the XML file can be adapted to describe most things, constraints of the SFNC sometimes prevent a particularly novel camera from fitting into it. Either new elements could be added to the specification for each new feature, or camera vendors could be required to straddle a novel feature across existing elements in order to fit into the GenICam model. This question will be addressed at the next meeting of the GenICam committee.
According to Lindberg, the committee approach has its own drawbacks with any changes to the standard taking a long time to be implemented. ‘Right now, if a customer can’t do something with GenICam they have to go elsewhere, because it takes a long time to make changes. Things will work in the end, but not instantly.’
The committee
There are two international meetings per year, one in North America and one in Europe. Potential methods of certification have been discussed at recent meetings, and are on the agenda for the April meeting. Vincent Rowley, senior developer at Pleora and vice chair of GigE Vision’s technical committee, says that ‘there is no GenICam certification process enforced by anyone at this time, but at the GenICam conformance subcommittee they have identified that it is important to put this in place.’ While GigE already has this type of certification process, the scope of GenICam is a little broader. GenICam compliance not only covers cameras, but also libraries and software, and so each type of product will require its own type of compliance testing. ‘One needs to define what is going to be tested, how it is going to be tested, and who the results of the test are to be reported to,’ says Rowley. ‘It’s a complicated process’.
Competitors cooperating
As Bourbonnais of Dalsa explains, GenICam’s adoption will mean greater interoperability between software vendors and camera vendors. ‘Dalsa doesn’t need the standard, as we produce both software and cameras. The need arises when a customer wants to use our camera, but they are currently using another company’s frame grabber.’ This could be bad for business for the company that loses customers to another camera manufacturer, but the 28 companies are happy to cooperate nonetheless.
Pleora’s Rowley believes that the reason behind this cooperation lies in a common desire to see the market grow. ‘The idea is to help make the pie bigger; after that it will be up to the company creating the better product to get a bigger piece of that pie.’
Lindberg, also of Pleora, adds that ‘most players around the table are committed to the use of standards. ‘We find that participating actively in both GenICam and GigE is a good way to position ourselves as technology leaders, but also to prepare ourselves for the future, so that we know what’s coming up on the horizon and can adjust our prioritisation accordingly.’
The future is likely to bring a wider adoption of GigE’s cousin, the 10 Gigabit Ethernet cameras (10GigE), with vendors already controlling these products through the GenAPI. Using GenICam interface for Camera Link cameras would, according to Bourbonnais, be a significant step, as it would help to distance the standard from GigE Vision and therefore help showcase its versatility. Widespread FireWire and USB adoption could follow; the committees controlling these two standards are not yet on board GenICam thus far. Whatever the future of machine vision brings, the members of the GenICam committee hope that it will be easily connected.