language-style interpreter that executes a testing script. The interpreter was extended with intrinsic functions that call GPIB libraries, also built into the daemon.
A Shared Remote Testing Environment for Engineering Education Clinton D. Knight and Stephen P. DeWeerth School of Electrical and Computer Engineering Georgia Institute of Technology Atlanta, GA 30332-0250
Abstract The World Wide Web has tremendous untapped potential for engineering education. We have developed a system for evaluating microelectronic circuits via the Web. While remote testing is not intended to replace hands-on laboratories, the system can address many of the short-comings of traditional labs. Remote testing has been applied at Georgia Tech in both instructional and research settings and has been well received by students.
Introduction The Internet, coupled with the impending ubiquity of the World Wide Web (WWW), holds a vast, largely untapped potential for innovative educational tools. Much has been said about distance learning and the virtual class-room, but such discussion usually centers on remote access to static databases [1,2,3]. We have extended these ideas to a dynamic case: remote automated testing. Using the same paradigm, the “database query” becomes a set of test parameters, and the “database output” is the test result. Neither specification nor acquisition is trivial in this case, and the system is dynamic because the state of the data-base must change before the result is known. The primary challenges to building a remote testing system are also its greatest strengths. It must be universally accessible, it must be shared efficiently by a large number of users, and it must function automatically. Furthermore, the system should provide maximum flexibility but present a minimal learning curve. Given these advantages, remote testing has proven particularly useful with analog circuits and devices. Setting up an analog test can be a tedious process of connecting various instruments to the device under test (DUT), but the system described below automates this task by moving it into software. This eliminates overhead and enables effortless sharing by multiple users. Universal remote access allows high equipment costs to be spread among disparate organizations. We present a system for evaluating microelectronic devices and circuits. The system operates
over the WWW, providing for near-universal access. It has significant advantages in the implementation of some electronics lab-oratories and has already been tested as such. Remote testing is an idea that is not limited to EE labs. It could find application in many fields, such as chemical analysis, wind tunnel tests, robotics, animal experiments, and other areas in which equipment access is somehow limited.
Application According to [4], over 70% of students prefer learning new material in the sequence of concept followed by example, both in lecture and textbooks. As this presentation style can enhance both comprehension and retention, many EE courses link circuits courses with corequisite laboratories. While careful planning can address lab/lecture synchronization issues [5], the labs themselves can be problematic for a number of reasons. There is, of course, no substitute for solid, hands-on bench laboratory experience. There are cases, however, where the traditional lab is either impossible or undesirable. Equipment accessibility is one factor; it is impractical to allow a large microelectronics fabrication class into a cleanroom facility, even though there are unique experiences to be gained there. Equipment cost is another obstacle; a radio-frequency lab might be fortunate to have a single network analyzer or anechoic chamber. Safety of equipment and operators is always a concern, as in power labs. Additionally, the “closed” lab paradigm, where a contiguous period is spent in lab followed by a written report, is not the format most conducive to learning. Better to have an open lab, where a student can return to take additional data if needed for the report. Closed labs suffer other limitations as well. A disproportionate amount of lab time is spent assembling circuits provided by a “cook-book” lab manual. Any difficulties encountered, such as defective parts or uncalibrated instruments, are likely beyond the diagnostic capabilities of first-year students. And while solving such problems may provide valuable bench experience, the frustration involved can overshadow the intended benefit of the assignment.
To circumvent these problems, some schools postpone the lab courses, replacing them with simulation assignments. And while simulation is a valuable tool and certainly belongs in the early circuits courses, it can never completely replace working with actual devices and circuits. Simulation results are idealized and 100% repeat-able, whereas data from real devices is laced with offsets, noise, mismatch, parasitics, etc., and provides a more realistic view of the design challenges engineers face. The remote testing laboratory was developed to address all of the above concerns. To use the system, a student using the Netscape WWW browser submits testing parameters to a suite of instruments, the test is carried out, and the results are returned immediately over the Web (Fig 1). Leveraging the graphical power of the WWW, the system can even plot the output data (Fig 2). A circuit connected to the testing suite can thereby be fully characterized by a user at a remote location. Software arbitration provides transparent system multitasking to many users. The testing parameters are created off-line using a scripting language, minimizing connection time and allowing one state-of-the-art testing suite to be shared by a large class. Having a layer of software between user and equipment allows controls to be established that protect instruments, DUT, or user from harm.
to a set of instruments is eliminated. Lab time consists wholly of taking and analyzing data, probing a device or circuit and learning its characteristics. This advantage highlights the principal raison d’être of the remote testing laboratory: a teaching tool in circuits classes. Once again, it is not meant to replace traditional handson laboratories, but using each in the proper setting can lead to a more effective curriculum.
Figure 2. n-FET data in graphical form.
Figure 1. Data from an integrated n-FET.
With remote testing, the emphasis is on “quality” lab time. The entire process of selecting electronic parts, assembling a circuit, and connecting it
Implementing the remote testing system using the WWW brings all the power of hypermedia to bear. Other educators have created hypertext reference material for use in an instructional lab [6], but this system completes the package. The reference pages can become an integral part of the “lab” environment. For example, a student can refer to the page describing transistor parameters before measuring those of the DUT. Even the class notes and lab assignments can be placed on Web pages, providing a “one-stop” solution that is simple both to use and maintain. The remote laboratory is easily tailored to students of various experience levels. A freshman might be given an intuitive graphical user interface (GUI) and asked to take some specific measurements. A more experienced student might be asked to write a script to identify and characterize an unknown device with little further instruction. Either way, the remote testing novice faces a gentle learning curve. Many students already use the WWW, and only a rudimentary knowledge of structured programming is assumed. Contrast this with
another published lab design [7], which devoted two entire lab assignments to familiarization with Unix. Of course, the C-language-style scripting language does provide a powerful, inherent analysis tool for the computer literate student. Borrowing from published computer lab guidelines [8], laboratories should be kept up-to-date and in working order. Since the remote testing system only requires one central suite of instruments, system acquisition and maintenance is simplified. Labs should also be available beyond scheduled hours so that students can complete experiments at their own pace. Accordingly, the remote testing system requires no supervision and may be left running 24 hours a day. This advantage seems to violate another criterion, that help should always be available. The WWW-based hypertext system, however, places solutions to common problems right at the student’s fingertips. One study found that lab assignments are most effective for groups of two students, rather than the larger groups often necessitated by scarce equipment [9]. Due to its efficiency, the remote testing system can feasibly be used by groups of one or two. The remote testing system has been used at Georgia Tech in a graduate circuits course. This group seemed a wise choice for the initial evaluation, given the small class size and better computer skills of grad students. The class of 15 students had no difficulties sharing a single testing suite and tended to complete assignments on highly varying schedules, suggesting the system would be useful to much larger groups. Remote testing has been well received by students, as it gives them far more insight into circuit behavior than lectures and simulation alone can provide. The system is also being evaluated by graduate students doing research in analog circuits, and plans are underway to use it in undergraduate circuits and fabrication courses.
Implementation We have addressed the challenges encountered in building a remote testing system. Universal access is achieved using direct Internet connections. This choice also meets the sharing requirement, as multiple connections are possible. Platform independence is gained by using the WWW, which also serves to present a familiar interface to new users. A switching matrix makes connections between instruments and the device under test, eliminating the need for local supervision. A scripting language provides for both flexibility in testing and efficient sharing, as users can develop test programs
off-line. This also improves equipment utilization, as user jobs are run sequentially from a wait queue. Figure 3 shows the layout of the system. A testing script is submitted from a client/WWW browser to a Common Gateway Interface (CGI) program on the local WWW server. This program opens a socket connection to a daemon running on the workstation/GPIB controller. Written in C++, the daemon is the heart of the system. The daemon embodies several distinct software packages that work together as a unified application. One part of the daemon is a Clanguage-style interpreter that executes a testing script. The interpreter was extended with intrinsic functions that call GPIB libraries, also built into the daemon. These libraries were written in an object-oriented style, using multiple virtual inheritance, that treats the testing suite as a single object made up of disparate instruments, some of which contain independent channels. The instrument libraries insulate the user from cryptic GPIB programming, and the daemon adds additional layers of abstraction so that the user may specify a test from a purely functional viewpoint. The daemon also links the interpreter to a plotting utility that returns test results in a graphical representation. Another part of the daemon converts user data plots to an image format used by WWW browsers. When used in scripting mode, this is effectively a batch processing system, an arrangement with definite pros and cons. A batch system lends itself well to efficient sharing and high equipment utilization. The ability to write a program provides the flexibility needed for complex tests that require group triggering, intermediate data analysis, low-level GPIB control, conditional tests, etc. On the other hand, the batch-mode system cannot provide the look and feel of a laboratory bench. If a problem occurs during a batch test, the user receives little or no feedback to help determine what happened. In this case, a GUI is preferable, as it allows a user to vary circuit stimuli and immediately observe the responses. Connections between instruments and the DUT are made using a click-and-drag iconic paradigm. The challenges to developing the GUI lie in how to represent the circuits as well as how to keep the instruments and the interface well-synchronized despite unpredictable delays between them. The Java programming language is being used to design such an interactive testing interface, as it is compatible with the WWW and is becoming sufficiently mature for this project.
Figure 3. System diagram. (IP=internet protocol, CGI=common gateway interface, GPIB=general purpose interface bus)
Conclusions
References
We have demonstrated a system that provides access to laboratory equipment to users outside the lab. Remote testing represents a novel use of the Internet and WWW for education. While it is not meant to replace hands-on laboratory experience, it promises to enhance engineering and science curricula by facilitating greater access by more people to better laboratory equipment. The system described herein allows remote testing of electronic devices and circuits and has been validated in the classroom. Remote testing may use either batch or interactive paradigms, and both approaches are currently being refined. Once the GUI is finished, the system will be tested with larger, less-experienced classes. In the same vein, other new applications of remote control of these “dynamic databases” are being investigated, both for educational and industrial use. The WWW is already a tremendous information resource, but is also well suited for interfacing to physical systems. Both of these have myriad applications, not the least of which is engineering education. The challenge lies in discovering ways these new tools can not only supplement existing curricula, but also significantly enhance the learning process.
1. van Brakel, P.A. “Teaching Hypertext Techniques with Mosaic/WWW,” Proceedings of the First International Conference on the World Wide Web, May 1994, Geneva, Switzerland.2. Bignal A.R., et. al. “Uses of Mosaic in a University Setting,” Proceedings of the Second International WWW Conference, Jan. 1995, Chicago, Illinois. 3. Ibrahim, B. “Advanced Educational Uses of the WWW,” Proceedings of the Third International WWW Conference, Apr. 1995, Darmstadt, Germany. 4. Rosati, P. “Learning Preferences Reported by Engineering Students,” International Journal of Engineering Education. Vol. 9, No. 3, pp. 218-222. 5. Spina, R. and Mukund, P.R. “A Multimedia Approach to Teaching Design in Core Laboratories,” Proceedings of the 23rd Frontiers in Education Conference, Nov. 1993, Washington, D.C., pp. 263-266. 6. Eibeck, P.A. “Multimedia Courseware for Instruction of Engineering Experimentation,” Proceedings of the 23rd Frontiers in Education Conference, Nov. 1993, Washington, D.C., pp. 135-138. 7. Williams, R.W. “An Undergraduate VLSI CMOS Circuit Design Laboratory,” IEEE Transactions on Education. Vol. 34, No. 1, pp. 47-51. 8. Tucker, A., et. al. “Computing Curricula 1991,” Communications of the ACM. Vol. 34, No. 6, pp. 68-84. 9. Sutko, A.A. “The Effects of Laboratory Group Size on Student Performance,” International Journal of Engineering Education. Vol. 8, No. 3, pp. 189-191.
Links:
• • • • • •
Introduction page to the remote testing system Testing script submission form Results from nFET test Linear plot of nFET data Log plot of nFET data Script used to test thenFET
