Climbing on the right bus

There have been some intriguing developments in instrument buses for handling massive amounts of test data. Tom Shelley investigates

When handling truly massive amounts of test data, simple databus speed may not be enough to process all the information in a coherent way. It may well be necessary to use different databuses to handle various streams, in order to coordinate everything properly. Whether the test involves crashing something, blowing it up – or simply flying something over a runway to see how much noise it makes and what causes it – it is essential to manage the acquisition of data in the best possible way. This is especially true where the test is likely to be expensive to repeat and/or has involved the purchase of a lot of specialist instrumentation. Ian Matthews of National Instruments argues that it’s necessary to look at bandwidth, latency and distance. For example, Ethernet may be available to deliver Gigabit speeds, but latency can be 1000 microseconds, which may not sound a lot. However, if there is a need for a high volume of requests and responses, this may not allow the gathering of all the data from all the sensing points in the available time. In some sequences, he told a recent session at NI Days at the IET headquarters in London, the old GPIB (General Purpose Interface Bus) may be more appropriate, because, while speed may be lower, latency is only about 10 microseconds. And while PCI Express - derived from PCI, Peripheral Component Interconnect - is a serial bus used in standard PC architectures, which has a latency of much less than one microsecond, and can deliver 1 GB or more per second, “you can’t put anything even 10m away”, states Matthews. In some circumstances, he suggests, you can use several buses in parallel - for sensor data, vision and motion control, for example. When designing a system, he said, the aim should be to provide the opportunity to transfer as much data as possible, and allow for the plugging in of different current and future databuses. One of the strengths of NI’s offerings is that, being software based, new modules and capabilities can be added in by making alterations in graphical programming without having to scrap what has already been purchased and to start again from scratch. This is important when, on one hand, electronic technology continues to advance at a fearsome rate, while, on the other hand, many systems, particularly those designed for military and aerospace, have to be tested and maintained for 20 or more years. Ian Bell, NI’s UK marketing manager, comments: “No single bus solves every application – we are very keen on PXI” [PCI eXtensions for Instrumentation, which NI introduced in 1997]. “In many industries, the biggest companies are using PXI.” NI products include the ability to provide bandwidths of up to 6 GB/s and the company presently has a PXI-8108 2.53 GHz module with a dual core embedded controller. Next year, says Bell, it will be offering quad core capabilities, as well as supporting other databuses such as VXI. Meanwhile, he points out that even higher processing speeds can be achieved by using NI’s LabView FPGA capability, which allows massively parallel data processing applications to be run on a single gate array. Pointers * When choosing instrumentation databases, it is essential to look at latency and maximum length, as well as data rate * It may be necessary to have more than one databus in order to gather and process different types of data * With the present rapid rate of technological advancement, it would be wise to ensure that, what ever system is adopted, it should be flexible and upgradable