|
|
Interoperability Comes The Open Data Acquisition Standard means users can finally mix and match Timothy Ludy, True interoperability between PC-based data acquisition (DA) hardware and software from The Open Data Acquisition Standard (ODAS) defines the software interface for PC DA cards. When implemented, it functions as a standard software driver for the cards. ODAS provides a specification for the five primary subsystems found on most DA boards: analog in, analog out, digital in, digital out, and counter/timer. This specification is based on Microsoft COM technologies, not on a proprietary software implementation (see the sidebar "ODAS Capabilities,"). The Current Situation When writing software for DA boards, you must choose how it will interact with the hardware. You can write your own program using a standard computer language (e.g., Visual Basic, C++, Delphi), or you can purchase a software development package (e.g., HP VEE and Labtech Notebook) and use it to create an application that executes in that programming environment. Let's examine each choice. Write a Program. You must deal with a variety of programming details when writing applications for PC cards. Adding channels to a multipurpose DA board using the digital outputs allows switching among more analog-in lines than are present on the board. To do this, you have to control the digital output lines. The following table shows the software commands from various vendors used to control the output lines:
Not only are the command names different, but the number of parameters and data types for the parameters are too. If you use PC cards from the same vendor, this is generally not a problem. But integrating cards from different vendors or switching vendors means you must learn a new set of software commands, figure out how the commands work together, and then learn how to set up the card. Purchase an Application. You also have to deal with programming details when you buy the software. Software vendors have taken two approaches to make sure that their applications work with DA cards from multiple vendors. In the first approach, the vendor writes a layer of code inside the application, on top of each I/O library from each hardware company's application programming interface (API). This is the approach used with Labtech Notebook and other applications. The main benefit of this approach is that the user interface is consistent regardless of which vendor's card is installed. But this creates a software maintenance problem for the software vendor, because as the hardware I/O libraries change over time, the application must be updated. Also, not all libraries are available for Windows 95/98 and Windows NT. The additional software layers are difficult to implement uniformly because the functions of the I/O libraries don't always overlap. This forces the software vendors' R&D engineers to be experts in many different I/O libraries. In the second approach, software vendors enable the board makers to add support for their products to the application. The board vendor ensures that the software add-on or example programs work with all of its cards. This is the approach used with HP VEE and other applications. But with this approach, the user interfaces to the various cards are different from vendor to vendor. In addition, board vendors must track the revisions of the application and ensure that their integration methodology works on all software revisions (see Figure 1).
The first approach puts a burden on the application vendors to support all hardware interfaces. The second puts a burden on the hardware vendor to support multiple applications. Neither case provides a uniformly consistent solution for customers developing PC-based systems. For example, Figure 2 shows how this is done in HP VEE. The graphic shows the user interface to a card from Data Translation. Data Translation developed a top-level menu divided into two sections. The first is for configuring the card's functionality. Individual cards have different areas of functionality, so you might have to use several of these Config objects to get the card set up. The second section includes the calls needed to set or get data from the card. Figure 3 shows another board vendor's integration of HP VEE. The menus and submenus are calls to the dynamic link library (DLL), which is the way this vendor used to talk with its I/O library and hardware. This illustrates how two vendors can choose two different methodologies to interface their boards. This kind of difference is true in all applications that support this kind of modification. ODAS Design ODAS is a software interface, designed to Microsoft's COM standards, that formalizes a standard communications mechanism between application software and the device drivers for DA hardware (e.g., PC boards). Because most hardware manufacturers already have their own APIs and driver libraries, the standard was designed to be a thin software layer that could be written on top of existing drivers. Another design goal was to be able to write interfaces to other complimentary API standards, such as OPC (see the sidebar "Why ODAS and Not OPC?,"). A set of software objects provides a software abstraction of the most common functionality of PC boards and DA software. There is support for analog input, analog output, digital input, digital output, and counter timers. The object hierarchy is as follows: ODAS Manager. The ODAS Manager is a top-level object, or software interface, that can enumerate all the installed ODAS drivers. The manager allows an application to easily find and select the appropriate driver. The object is not specific to any device manufacturer, and through it, you can reach one or more driver objects in the next level of the object hierarchy (see Figure 4). ODAS Driver. Each manufacturer of DA hardware provides an ODAS driver object, which provides interfaces to the device drivers for specific models of PC boards or devices. Through this object, you can reach one or more device objects in the next level of the object hierarchy. ODAS Device. In ODAS parlance, the prototypical device is a multifunction DA board. Devices that connect by interface cabling are also supported. In a running ODAS driver, there is one ODAS device software object per device. For example, if you have two identical analog I/O boards and one counter/timer board, there would be three ODAS device objects. Each of these is linked to one or more ODAS subsystems. ODAS Subsystem. Each board might have one or more subsystem objects, which correspond to the I/O on the device. Each of the subsystem object types has specific properties and methods (APIs) that applications can use to interact with the I/O hardware, such as AIn( ) for simple single-point analog input. Interoperability ODAS is designed to provide a high degree of interoperability so that hardware can be quickly and easily connected to software (see the sidebar "The Benefits of ODAS,"). This is facilitated by user-defined aliases for hardware devices. The ODAS Manager object creates subsystem objects based on user-defined aliases. For instance, the alias "ADBoard 1" might refer to Data Translation's DT3010 board, and the program can be written around that card. In the future, the user might replace it with another vendor's card, and by modifying the alias reference, the program should work without change. Aliases are designed to allow you to swap out one DA device for another without modifying the application software. This should be true even if the boards are from different manufacturers (and provide similar levels of hardware capability). This interoperability will enable new software vendors to easily enter the PC board market. The current cost of entry is high. New software developers must either support many hardware drivers themselves or convince the hardware vendors to support their applications. At the beginning of the article, a table lists the commands used to control a digital output line. Here is what the table would look like when ODAS drivers are used.
Why Is ODAS Built with COM? PC board driver libraries are based on DLLs. But standard DLL interfaces suffer from several shortcomings. First, handling multiple versions of a DLL can be very problematic. It is not uncommon to install a new Windows application only to find that a previously installed application will no longer run. This happens when the new application installs a different version of a DLL that the first application happens to use. Subtle changes in behavior or missing functionality in the updated DLL cause the old application to fail. Solving the problem was one of the prime design goals for COM, which does solve the version problem inherent in DLLs. The second shortcoming of DLLs is that they usually provide a flat procedural interface. Because they are designed to work with the widest array of programming languages, simple DLLs don't provide an object-oriented programming model. Instead, they use a list of every function available in the DLL. This is very much like the current Win32 application programming interface. This API can present the programmer with a bewildering array of choices, where the most commonly used functions are lumped in with the least frequently used functions. Another of COM's design goals was to provide an object-oriented programming paradigm that can be used for many different programming environments. As a result, COM-based components can provide a hierarchy of functionality--also referred to as an object model--that provides an intuitive grouping of functionality. Much like the directories used to group and organize related files on a computer, COM uses objects and interfaces to group-related functions.
Because ODAS drivers are COM components, they can be developed in any programming language, and COM support is nicely integrated with most software development tools. A mature spec, COM allows for multiple network transports; when distributing an application with DCOM, this becomes important. COM is becoming the ubiquitous object model for developing component software. COM objects also retain state. This means that you can set the properties of an object, and those properties stay with the object throughout its life. For instance, consider a hypothetical DigitizerObject. It will need to set the SampleRate property to 1 Msps, the Depth property to 1 KB, and the NumBits property to 12. Then the Digitize method is called with no parameters. This is because the information has been set as properties of the object. The SampleRate property can be changed easily to 10 Msps with a subsequent call to Digitize again. The following represents what the respective programming models would look like: Procedural Model '1st parameter indicates the subsystem Object Model With driver.AnalogIn (1) .NumBits = 12 Note that each call to a procedural-style function requires every parameter to be passed again. The object-oriented code is easier to read because you can easily tell that the value 1E6 is associated with SampleRate. This is not obvious with the procedural-style function call. Because objects can retain state, the objects can save their state, which can be recalled later. This can eliminate the need to programmatically set every property in an object. In terms of industry trends, COM is the future of software development on the Windows platform. Most new functionality being added to the Windows operating system is coming in the form of COM components. Microsoft's much-heralded Active Directory Services Interface (ADSI) is COM-based. The new scripting paradigm for Windows, called Windows Scripting Host, is COM-based. The DirectX multimedia interfaces are COM-based, as are Microsoft's Distributed interNet Applications Architecture (DNA). COM provides a better foundation for a long-term standard because it provides all members with equal competitive footing. It also ensures a wealth of software technology that DA applications can better use. End users of DA products will have more choices--choices that will work together and that will make life easier for everyone.
Timothy Ludy is the Product Marketing Manager at Data Translation, 100 Locke Dr., Marlboro, MA 01752, 508-481-3700, x-602.
|
|
|
different vendors--wouldn't that make life easier? If the Open Data Acquisition Association (ODAA) has its way, users of DA systems will have a universal standard that allows them to mix and match the most appropriate products from multiple providers. All products in compliance with the specification are fully compatible. The founding members of the ODAA--Data Translation, Hewlett-Packard, Labtech, Omega Engineering, and Strawberry Tree--are spearheading the drive to standardize the way DA components work together.
