Will Data-Acquisition Standards Become a Reality This Time?
A commentary about a new industry organization.
Martin Rowe, T&MW Senior Technical Editor -- Test & Measurement World, 12/1/1998
In 1992, manufacturers of data-acquisition boards recognized that each company used a different set of programming commands for its products. At the time, those companies were writing their first dynamic link library (DLL) drivers for Windows 3.1. The companies sought to create a standard set of programming commands for all boards so users wouldn't be locked into learning and writing code for each manufacturer's products.The companies held several meetings and finally agreed to disagree. Each company wanted the others to convert to its set of function calls. These companies were, in effect, saying, "We should all conform to one religion--mine." In October 1993, I wrote a requiem for the WinSEM (Windows Science, Engineering, and Manufacturing) movement.1
Recently, several companies have decided to try again. On November 10, 1998, members of the Open Data Acquisition Association (ODAA, www.opendaq.org) demonstrated software that runs on boards from two companies without changing code. The two companies (ComputerBoards and Data Translation), along with Hewlett-Packard, Strawberry Tree, Labtech, and Omega Engineering, hope to persuade the industry to adapt a specification for a common set of programming commands. These companies claim that a common application programming interface (API) will lower costs, simplify technical support, and let users replace a board from one company with one from another without having to write new code. Will the association succeed where WinSEM failed? It's too early to know, but there's a chance.
Both the WinSEM and open data-acquisition standard (ODAS) programming models add a "shim" driver layer between applications programs and board-level drivers. The concept is the same, but the technology used to implement the shim differs. The WinSEM group planned to use a DLL to translate the common set of commands into manufacturer-specific commands. Each manufacturer would deliver its own version of the shim DLL.
Driver technology has changed in six years, and the companies in the association have abandoned the DLL concept in favor of ActiveX controls, also called Microsoft's common-object model (COM) technology. For COM to work, the applications program you use must be an ActiveX client. ActiveX client programming languages include Visual Basic, Visual C++, Delphi, LabView, TestPoint, and VEE. Figure 1 shows how the shim fits in between an applications program and a board's driver DLL.
To use the ODAS COM driver, you don't actually make function calls as you do with DLLs. Because the ODAS driver is a COM object, you program it the way you would any other ActiveX control. You activate the control by setting properties.
The ODAS software also contains a manager program. In the manager, you select a variable that tells the software shim which board to control. According to Ken Colasuonno of Hewlett-Packard, you might pick variable daqCard1=CBxxxx (ComputerBoards) and daqCard2=DTxxxx (Data Translation). In your program, you then set properties such as sample rate, channel number, gain, and number of samples before sending the command to begin an acquisition. The ODAS driver then communicates the information to the appropriate driver DLL.
Because each company's drivers use a unique set of programming commands, each company will have to write its own ODAS shim that converts the standard set of properties to that company's unique set of DLL function calls. Publishers of third-party data-acquisition software will have to add the standard set of properties to their applications, but they won't have to provide a programming interface for any one set of hardware. Currently, third-party software publishers must decide which hardware to support and provide calls to those drivers.
What Does It All Mean?
If you use plug-in data-acquisition boards and write your own programs, the new standards may not affect you at all. The companies will continue to support their existing drivers, so you will be able to use your existing code even if you use products that eventually comply with the ODAS standards. You won’t need to switch to ODAS-compliant products unless you want code that lets you substitute hardware from several companies. If you do decide to use ODAS-compliant hardware in an existing application, however, you'll have to rewrite your code to match the new set of function calls. If you see no need for interchangeability in your system, then having ODAS-compliant products won't matter.
The ODAS concept is similar to what the VXIbus community calls virtual instrument software architecture (VISA). VISA is a DLL that adapts programming languages to VXIbus instruments. Most VXIbus users expect to purchase instruments from more than one company, so interoperability has always been an issue.
In contrast, most manufacturers of data-acquisition board can meet just about any need. Data-acquisition boards have essentially five functions:
- analog input,
- analog output,
- digital input,
- digital output, and
- counter/timer.
A multifunction data-acquisition system has any or all of these functions. Nearly all data-acquisition hardware manufacturers have products that provide these functions. So, users of data-acquisition systems tend to purchase products from a single manufacturer. If, for example, you have a multifunction board and need more digital I/O channels, you most likely can get a digital I/O board from the same manufacturer. Because you're already familiar with that company's programming calls, you'll have no learning curve.
You might, however, have a need to switch board manufacturers if yours doesn't have a board with the speed you need. Only then will you be able to take advantage of ODAS-compliant products. You'll still have to climb a learning curve to program with the ODAS property settings, but you'll only have to learn the programming interface once.
If you use an ODAS-compliant third-party data-acquisition program (when available), you should be able to use ODAS-compliant hardware. Right now, when a software publisher changes its programs, hardware manufacturers have to verify that the changes won't have an adverse affect on their hardware.
So far, I believe that the biggest beneficiaries of the ODAS concept are hardware manufacturers, software publishers, and resellers. Hardware manufacturers will benefit from no longer having to test every version of third-party programs for interoperability problems. Publishers of third-party software will need to support only one set of programming commands, which simplifies program development. Resellers of hardware and software will receive the biggest benefit--their technical support engineers will have to learn only one set of programming functions.
Three-Sided Coin
Right now, the open data-acquisition issue has three sides?companies already in the group, companies not interested in joining, and companies still trying to decide whether to join. Two of the largest hardware manufacturers?Keithley and National Instruments?have not joined the association.
According to Keithley's David Howarth, the company has taken a wait-and-see approach. If customers ask for ODAS compliance, then the company may decide to join. Other companies, such as Quatech and United Electronic Industries, favor the ODAS concept, but are waiting to see if it gains momentum before they decide to join the association.
To date, National Instruments also has chosen not to join the association. According to vice president of marketing, John Graf, the company will reconsider its position if it's customers express enough interest in ODAS compatibility.
Without Keithley and National Instruments, the association will have its work cut out for it. With Hewlett-Packard already in the group, the potential for a showdown exists with National Instruments and LabView on one side, and HP and VEE supporting several hardware manufacturers on the other.
Ultimately, instrument users will decide if the Open Data Acquisition Association will succeed. The association does have one thing going for it: this group already has a standard for analog-input functions and has demonstrated that the standard can work. Six years ago, the WinSEM members, which included Keithley and National Instruments, tried to get everyone to agree on a set of DLL programming commands before setting out to write a standard. With a standard and a working model already in place, the ODAA is already in better shape than its predecessor.
FOOTNOTE
1. Rowe, Martin, "A Noble Effort Fades to Black," Test & Measurement World, October 1993, p. 27.
FOR FURTHER READING
Test & Measurement World has published the following articles relating to the WinSEM effort. 1. Bhaskar, K.S., "Data Acquisition Users Must Define Standards," December 1992, p. 37.
2. Rowe, Martin, "PC Plug-In Cards Drive for Standards," January 1993, p. 42.
