KAMINSKY, Daniel
VSB Technical University Ostrava, Department of Electrical Measurements, 17. listopadu 15, 708 33 Ostrava Poruba, Czech Republic, Daniel.Kaminsky@vsb.cz, http://www.vsb.cz
Abstract: In the 1992 the project "Instrument drivers development" focused into the establishing the developers team based on FEI VSB Technical University teachers and students has been prepared and officially started as the joint project of National Instruments Corporation, USA and VSB Technical University. The project was successfully started and is still running. Two project extensions in the past are the evidence of the project success. Now in the framework of the project exists a wide network of co-operating institutions in which participates beside National Instruments (USA) such instruments vendors as are Rohde Schwarz (Germany), LEM Instruments (Austria), Hewlett Packard (USA), LeCroy (Switzerland and USA) and others. The project allowed several long term study stays (4 months) for up to 10 students and involved University teachers in the last 4 years, giving to its attendees to work in the international team dealing with the design and development of the SW components used in the instrumentation systems. The project contributed also to the creation of spin-off company dealing with instrumentation SW design and development in the Ostrava Science and Technology Park. The paper will discuss as the case study the development of co-operation, showing the critical parts of such international project development running and management.
Keywords: International partners network, industry joint programs, Practice based engineering education, virtual instrumentation, instrument drivers, and remote control of instruments
The Department of Electrical Measurement of Faculty of Electrical Engineering and Informatics of VSDB TU Ostrava is focusing for several years to the area of Virtual Instrumentation Technology. In general this technology is dealing with the problems concerning the design methodology of the systems where the PC and the appropriate SW systems play the key role. Shortly after the Department of Electrical Measurements has been established at the Faculty of Electrical Engineering of VSB TU Ostrava the International project "Instrument Drivers Development" has been initiated. To provide a better understanding how the project has been started and handled it is very important to understand the technology of instrument drivers and know what is the main purposes of instrument drivers, how they can be used for the development of instrumentation systems.
To understand a standard architecture and methodology for the development of instrument drivers, it is useful to understand some of the history of the evolution of modern instrument driver software. A first step in this process is to answer the question "What is an instrument driver?" It is not a new concept. Instrumentation users have been writing their own instrument drivers for years, as many are aware. An instrument driver, in the simplest definition, is a piece of software that handles the details of controlling and communicating with a specific instrument.
The task of programming instruments in a test system has always been a major concern for end users and a major cost for the overall system development. Many users know that programming can often be the most time-consuming part of developing a system. The developer spends much valuable time learning the specific programming requirements of each instrument in the system, including the undocumented or unexpected features.
"Rack and stack" IEEE 488, or GPIB, instruments with their ASCII message-string programming methodology, have long been the most widely used type of instruments for multi-vendor systems. Almost all GPIB instruments are designed for interactive use through a physical front panel and also offer remote control capability via a GPIB port on the back of the instrument. The details for how to program the instrument remotely are usually documented in the instrument manual in the form of ASCII command sets that cause the instrument to perform the desired operation. Documenting an instrument command set in the user manual, along with some example program listings, has traditionally been the standard method for an instrument vendor to assist the end user in programming the instrument. These documentation methods have served the industry well for many years, but this approach still places the responsibility for writing the program code on the user, many of whom may end up writing very similar application programs.
In the early days of computer-controlled instrumentation systems, the interpreted BASIC language was a widely-used programming environment. To control the instrument from the computer, the users would typically use I/O statements throughout their application program to send and receive the appropriate command and data strings to and from the various instruments in the system. The BASIC language, with its built-in formatted I/O capabilities, matched well with the formatted ASCII command and data strings used to control message-based GPIB instruments. Over the years, special-purpose versions of BASIC or similar languages with ever more powerful tools oriented specifically toward message-based instrument programming appeared on the market and enjoyed various levels of success. During this era, the concept of an instrument driver as referred to in this specification did not exist. Throughout the 1980s, computer-controlled instrumentation became more widespread. Several key factors helped this occur and influenced the evolution of instrument drivers.
The personal computer revolution enabled more users to take advantage of automated computer-controlled systems. Not only did many more scientists and engineers become comfortable using computers, but also the lower cost of PC-based systems made such technology applicable to many more applications. Also during this time, computer-programming technology made tremendous strides. Compiled languages such as Pascal and C offered many benefits over interpreted BASIC, including faster execution speed and more powerful program and data structures. In addition, these new languages offered the ability to make programs more modular by organising them into separate pieces that could be developed, maintained, and managed as independent, but related, software objects.As computer-controlled instrumentation became more widespread and successful, many users began to realise that they often used the same instruments in a variety of systems. In addition, maintaining or enhancing existing systems often entailed replacing older instruments with newer or less expensive models. These realisations led to two identifiable trends in instrumentation applications: standard instrument command sets and modular instrument driver software.
If the same commands work for multiple instruments, regardless of the manufacturer, users can interchange or upgrade instruments and reduced the amount of changes to their application programs. In particular, many of the installed base of users who had substantial investments in BASIC or other software environments that did not easily lend themselves to software modularity lobbied for this approach. Through the mid to late 1980s, many standard organisations, including the IEEE, worked on this objective with little progress. The IEEE 488.2 specification, completed in 1987, more carefully defined the operation of instruments but did not address the issue of standard command sets.
Finally, in 1990, the SCPI (standard commands for programmable instruments) Consortium was formed. This organisation, many of whose members were also involved in the VXIbus Consortium and are now involved in the VXIplug&play Systems Alliance, approved a specification for standardised commands for message-based programmable instruments. The SCPI Consortium is still active and the standard document is updated on a yearly basis as new commands are added. While more and more companies continue to endorse the SCPI standard and use it in their new instrument designs, the majority of instruments available today do not use this standard command set. In addition, while many users of SCPI instruments applaud the progress and have experienced improvement in productivity once they learn the standard command set, instrument interchangeability is still not a reality because most instruments have different, often unique functionality.
While the SCPI standard is certainly recognised by the entire industry as a step forward, the lack of progress on this issue encouraged both users and vendors to explore other approaches before SCPI was completed. They needed to decrease the time required to program instruments, facilitating instrument interchangeability and easing system maintenance. Rather than trying to solve the problems by standardising the instruments from all suppliers, both users and vendors began to take advantage of new computer science technology to address the issues by making software more modular and flexible.
In 1987 the VXIbus Consortium produced the first VXIbus specification. Over the next several years, VXI enjoyed tremendous success and growth. As VXI grew, so did users’ expectations for instrument drivers. There are several reasons for this. First, it is widely known that VXI instruments can only be used with software. Whereas the evolutionary history of GPIB instrument control resulted in users never really expecting driver code to be included with a GPIB instrument, VXI set a new expectation. In the past, the burden of developing instrument-specific driver code had been placed on each and every user of each and every instrument. Because VXI instruments can only be used with software, VXI users and potential users began to make it known that they expected a better answer.
Another very important aspect is that VXI actually has two paradigms for instrument control. The first paradigm is message-based control, which is very similar to the message-based control methodology used for years with GPIB instruments. With this paradigm, the instrument is controlled using fairly high level ASCII command and data strings that are communicated to/from all instruments in a standard way and interpreted by each instrument in a device-specific way.
The other paradigm available in VXI is register-based control, which is a new paradigm for instrument control. With register-based control, the instrument is controlled through very low-level peeks and pokes of individual binary registers. Because there is no overhead for the instrument to interpret a message string, and because the software can directly access binary registers and data on the instrument without any formatting or interpretation, register-based control can, in some cases, offer higher performance than a message-based approach. However, because each register-based device has its own unique set of registers that operate in a unique way for each instrument, the software to control a register-based module is device-specific. Register-based control software, which is very low-level and unique to each instrument, is similar in concept to the "device driver" software modules required for individual computer plug-in boards such as network interfaces, display adapters, disk controllers, and so on.Because VXI has two paradigms available for instrument control, it promises the benefit of higher performance than GPIB technology. A particular instrument can use one or the other of these paradigms, or a mixture of both on the same module. Some of the VXI performance potential lies in register-based programming, but higher performance is also available through the use of other unique new VXI concepts such as fast data channels, shared memory, and distributed, multi-processor architectures that work with both message-based and register-based devices. Taking full advantage of many of these "high performance" programming techniques is a far more complex task than the simple message-string approach with which GPIB users are familiar and instrument driver concepts had evolved. Therefore, end-user programming of these unique features without a pre-written instrument driver may be more of a challenge and take more time and expense than with previous-generation GPIB technology. For these reasons, instrument drivers are recognised as a key component in the successful implementation of VXI technology by end users.
Purpose and Benefits of Instrument Drivers
The benefits of standard VXIplug&play instrument drivers are tremendous. First, vendors of instruments can be responsible for developing drivers for their own instruments and be guaranteed of interoperability with those from other vendors. This approach is desirable because the developer of a particular instrument knows how to use the unique capabilities of that instrument, and therefore is the best candidate for developing the instrument driver. The quality of the driver will be high, and users can hold the instrument vendor accountable for that quality and give direct feedback. A standard ensures that drivers from multiple vendors are designed, packaged, and used in a consistent way, which increases ease of use for end users. System-level openness and multi-vendor interoperability, therefore, are greatly enhanced.
The VXIplug&play instrument driver standard minimises duplication of effort in the industry. VXIplug&play instrument drivers can work with a wide variety of higher-level software tools. This capability unifies the market and promotes both de facto and formal standards in many other areas. When evaluating competing higher-level software packages, users can focus on understanding the differences in the methodology of higher-level software tools themselves, rather than worrying about subtle undocumented differences in the different instrument drivers used in the different packages.
VXIplug&play instrument drivers provide comprehensive access to the test and measurement capabilities of the instrument. To develop a standard for multi-vendor instrument drivers, it is important to identify the fundamental requirements. The first fundamental requirement is that instrument drivers should provide turn-key, ready-to-go software modules that the user can use directly in his or her own application program. Other areas of interest include the scope of functionality of the instrument driver, modularity and hierarchy, consistency in design and implementation, source code distribution, error handling, help information, documentation, revision control, distribution media, and installation.
During the Spring of 1997, a number of large manufacturing organisations expressed interest to National Instruments in interchangeable, or generic, instrument driver programming models. In response, these users were approached individually by National Instruments about the possibility of formalising a group chartered to define a set of interchangeable instrument driver models. The first working group meeting occurred in the Summer of 1997 and included representatives from GDE Systems, GEC Marconi, Lucent Technologies, National Instruments, Northrup Grumman, and Raytheon Systems. Representatives from these companies continued to meet throughout the Fall and Winter to explore the technical feasibility of generic instrument drivers. This group has evolved into a formal working group, the IVI (Interchangeable Virtual Instruments) Foundation, that has defined a set of standard instrument programming models on VXIplug&play-compliant frameworks. Membership in the IVI Foundation is open to end-users, system integrators, or instrument vendors interested in these issues. Those interested in joining the IVI Foundation can contact any member companies or the IVI Foundation itself.
The IVI Foundation will identify instrument classes based on the most common functionality and configurations available in instruments today. Initial classes have been selected based on importance and popularity in common test system configurations. The initial classes include Oscilloscope (IviScope), Digital Multimeter (IviDmm), Function Generator (IviFGen), Switch (IviSwtch), and Power Supply (IviPower) classes. In the future, additional classes will be identified and defined.
The goal of the IVI Foundation is to reduce the overall cost of test by defining standard instrument driver programming interfaces to common instrument classes. By standardising on a set of fundamental functions, settings, and permissible values, products based on the IVI Foundation specifications can deliver significant savings to test system developers. Standard interfaces give the following benefits:
The IVI Foundation will achieve instrument interchangeability and improved execution performance through the definition of standard instrument attributes applicable to each instrument of a particular class.
A. Test Development Savings through Instrument Interchangeability:
The IVI Foundation effort raises the level of standardisation for instrument drivers from basic interoperability to interchangeable instrument classes. By clearly defining APIs for instrument classes, such as oscilloscopes, multimeters, function generators, and so on, test developers can achieve greater hardware independence. A test program set (TPS) using IVI can then be deployed on multiple instrument racks with differing instrumentation, and can be updated as instruments become obsolete, or as newer, higher-performance or lower-cost instruments become available, without requiring changes to the test program source code. Therefore, through IVI drivers, test developers can not only change the hardware on their test systems without changing the test program source code, they can change out hardware without requiring a recompile of the source code. This is key for users, such as defence or avionics-related system developers, who must follow strict documentation and release procedures when implementing software changes.
In addition to code reusability, instrument interchangeability through standard programming interfaces reduces long-term maintenance and support costs for test system developers. Today, system developers must maintain test systems over many years, oftentimes requiring procurement of many instrument spares to support systems in the field. With interchangeable software interfaces, systems can be designed and supported by groups of instruments, reducing the danger of key instruments becoming obsolete over the lifetime of a system.
Standard programming interfaces not only reduce long-term maintenance and support costs for systems, they also simplify test system development. As more and more instruments are supported by a standard programming API, test developers will have much shorter learning curves when using a new instrument for the first time. When all oscilloscopes or DMMs have the same programming interface, developers can very easily begin programming with any instrument in the class.
B. Test Performance Improvement through Instrument State Caching
One of the most commonly requested features for standard instrument drivers is instrument state tracking, or caching. For standard VXIplug&play-style drivers delivered as a series of function calls, the state of the instrument is always assumed to be unknown. Therefore, each measurement function must go through a complete instrument setup for that measurement, even if the instrument is already configured properly. This can introduce significant overhead in building and sending command strings and forcing the instrument to reset parameters unnecessarily; all of which consumes instrumentation interface and processing bandwidth, and precious test time. By tracking the state of an instrument in software, unnecessary redundant instrument control commands can be eliminated, resulting in significant improvements in test execution speed.
Through the IVI attribute model, drivers automatically cache the current state of the instrument. Each instrument command only affects the specific instrument attributes that must be changed for that particular measurement. For example, if a test requires making the same measurement multiple times in a row, most VXIplug&play-style drivers would reconfigure the instrument during each subsequent measurement call. With an IVI driver, the instrument is configured only once on the first measurement call. This feature also benefits operations that alter only one attribute of a measurement. For example, if you are sweeping through a range of frequencies with a waveform generator, IVI drivers enable you to simply increment the frequency attribute without reconfiguring the remainder of the device. These seemingly minor differences in instrument I/O approaches can lead to dramatic reductions in test time and significant cost savings.
C. Easier, More Cost-Effective Test Development through Simulation
With IVI drivers, users can simulate the operation of their instruments when the instruments are not available. This allows developers to make progress on software when stations are unavailable or incomplete. As test code is developed that uses expensive instruments, or test systems are pieced together one instrument at a time, it is vital for developers to be able to make progress on the software front as the instruments are being acquired, calibrated, validated, installed, and fixtured. IVI drivers are delivered with default values for instrument attributes, and IVI also enables users to input their own values to be used for simulation for unique circumstances. Other approaches in the past have simulated bus traffic, showing which command strings will be passed over the GPIB or VXI bus when particular functions are called. IVI simulation focuses on the data returned from instruments. With simulated data, developers can actually develop test code without the instruments for performing acquisition and analysis operations. IVI simulation also handles all input parameters as if the instrument were actually connected as well – all parameters are range checked and coerced to proper values when out of range. Maximise software re-use through interchangeable instrument class definitions that focus on the features that instruments commonly implement and are commonly used by test system developers. IVI specifications outline instrument driver functions for controlling the common capabilities of rack-and-stack GPIB, PCI, PXI, serial, and VXI-based instruments. With an interchangeable driver model, users can easily rehost, upgrade, or transfer test program source code to accommodate newer, more powerful instruments, reduce downtime due to instrument failures or recalibration, and reuse of software originally developed for benchtop systems in R&D.
In 1992 the agreement for Instrument drivers development has been signed between VSB TU Ostrava and National Instruments Corporation. The main goal of the project was to establish the instrument driver’s development team that is able to work on the development SW libraries for remote control of instruments. For the successful starting of the project it was necessary to:
The agreement that stated the conditions, project phases and finance issues was prepared during the visit of Dr. Daniel Kaminsky to National Instruments Corporation in the 1992. Shortly after the visit National Instruments president Dr. James J. Truchard and Rector of VSB TU Prof. Tomas Cermak have signed the contract. The group of three students from VSB TU Ostrava who passed the telephone interviews with project supervisor from National Instruments in Austin, TX, USA departed for 3 months studying stay in the National Instruments Instrument drivers department. In the mean time the procedure for shipping the instruments that were and are the subject of instrument’s drivers development and testing has been developed. The first company that sent the instruments to VSB TU Ostrava was the well known German company: Wandell Goltermann.
Two project extensions in the past are the evidence of the project success. Now in the framework of the project exists a wide network of co-operating institutions in which participates beside National Instruments (USA) such instruments vendors as are Rohde Schwarz (Germany), LEM Instruments (Austria), Hewlett Packard (USA), LeCroy (Switzerland and USA) and others. The project allowed 3 long term study stays (4 months) for up to 10 students and involved University teachers in the last 4 years, giving to its attendees to work in the international team dealing with the design and development of the SW components used in the instrumentation systems.
The project contributed also to the creation of spin-off company dealing with instrumentation SW design and development in the Ostrava Science and Technology Park. The SW development group (in the meantime some student’s members of the development team have graduated) went also into the STP Ostrava as the new Division of Virtual Instrumentation focusing on the virtual instrumentation technology. Now the Division has the Department of Instrument Drivers with 5 developers, project manager providing the services to instrument’s vendors. The IVI technology for instrument drivers is the other project currently running between the Division of Virtual Instrumentation and National Instrument Corporation. Two developers from the Division are fully focussing into the IVI technology, being trained by National Instruments.
The described projects are bringing the important benefits to all involved partners. The Department of Electrical Measurements as the workplace where the development is being done has the full access to the latest technologies appearing in the are of virtual instrumentation. The latest versions of National Instruments development systems are being delivered for the updates free of charge to the Department of Electrical Measurements. The development packages and all technical resources and information are being continuously used in the education process for the students studying branches related to the instrumentation. The Faculty students have a chance to take part in the development project including the possibility of studying stays in USA. The instruments for which the drivers are being developed are mostly unique measurement systems that are just coming into the market from the leading instrumentation vendors. This is again a unique opportunity for both students and faculty members to get familiar with the latest technologies and systems from world technology leading companies. There are of course the benefits on the side of all involved companies. They are getting the results of the SW development e.g. instrument drivers. As the last not least issue it is important to mention the financial income from the project for the University, involved staff and students.