In new-product development groups, it is always a good idea to “wear the customers’ shoes.” Being a VXI and test and measurement software vendor, we were reminded of this when a new staff member asked: “Does all this stuff–all this graphical programming and VXI instrumentation on a card–really work?”
Rather than inundate this neophyte with overhead slides, speeches, demos and other static window-shop promotional hype, we took a different approach. We suggested that he create an interesting virtual-instrument test program for a fairly complicated DUT. What better way to answer the question than to put it to the test?
But what DUT? A simple one? Of course not! Here was a chance to learn something.
One of the automotive marketers suggested we use an engine controller. An engine controller is a medium-scale device of fair complexity, creating both analog and digital test problems (Figure 1a). And, you must stimulate and respond to it properly or it won’t operate.
A trip to the junkyard and $150 later produced a late-model car DUT with a half-meter lopped-off harness stub in hand. A visit to a nearby car dealer for a 3-inch-thick service manual provided information on general functional operation, I/O connections, signal characteristics and troubleshooting hints.
The service manual described in detail how the sensors and actuators in the chassis and motor could be emulated. For example, the engine block temperature sensor was replaced with the output of a D/A module that could be ramped from 0.5 V to 1.5 V.
Our neophyte crash-crammed the service manual, then spent a morning with an automotive expert on engine controllers (Figure 1b). Between them, a test and interface strategy was developed, and our neophyte was ready to see how easy graphical programming and VXI are to use.
We spared no disadvantages in the project, either. The neophyte had been through a week of HP VEE (graphical programming) training, but when the project started, the software was still sealed in shrink wrap and the mainframe was in its box. We also elected to use B-size VXI.
The Test Strategy
It began with a diagram. Through it, the expert explained the basic closed-loop operation of the engine and controller, down to the use of arbs and measurement instruments. These instruments would be used to fool the controller into thinking it was running in a real car (Figure 2).
The testing flow is expressed in the DUT language: Emulate the motor as though the car were spiraling up a 3,000-m climb–inducing drag, other impairments and sensor changes–during a 1- to 2-min run. This is a fairly powerful functional test because it truly treats the DUT like a black box.
The junkyard didn’t have schematics of the engine. All was not lost, though, because the strategy immediately lent itself to being implemented in graphical programming (Figure 3).
The engine controller needs several critical stimulus signals which emulate the sensors that detect rotation of the crankshaft and cams. These variable reluctance sensors (VRS) are inductors normally mounted near the flywheel or cam.
The flywheel and cam have metal teeth that pass by the inductor, inducing a pulse. The pulse has a camel hump-like shape that changes period and amplitude and, in a real car, shape (Figure 4).
If the arb is used to create these scaling VRS signals, the next question is, “What controls the arb’s rpm scaling factor?” Our neophyte determined rpm with a DMM and a counter/totalizer by measuring two outputs of the engine controller: the motor drive output that positions the butterfly (in the carburetor) and the tachometer output which is a pulse-width modulated signal. The core of the test strategy was to: 1) start the engine by setting the arb to 800 rpm (about 13 Hz) and 2) observe the steady-state behavior by reading the DC level of the throttle and the outputs of the butterfly motor and tach (Figure 5). Step 3 changes the throttle in a ramping function to simulate acceleration.
The key part of the third step is to continue reading the butterfly motor and tach and update the arb’s rpm. In this closed loop-like mode, the controller “thinks” it is in charge, so it tries to increase rpm by opening the carburetor butterfly and feeding more fuel. In our setup, the measurements detect the controller’s actions and then we update the arb.
Once the core closed loop became operational, the strategy was to change and measure the slower sensors and actuators. These slower devices were sourced with general-purpose D/A converters or other simple sources and measured by A/D or DMM inputs.
As the throttle voltage was ramped (D/A output), the butterfly position (motor-driver output) was measured, a new speed for the arb was looked up in a table, and the arb was reprogrammed. During this continuous two-minute ramp, other sensors and actuators were wiggled or measured.
From Out of the Box
Within a half day, we witnessed the successful assembly, configuration and self-test of the IEEE 488 PC interface, seven B-size instruments in the mainframe and HP VEE. It was refreshing to watch a VXI-inexperienced technical person check off the installation and integration steps in a rapid manner.
Our neophyte quickly tried numerous tutorials and built-in soft front panels to get the feel of the overall system. In two days, a graphical loop was written in which globals set the arb frequency and output level.
What became immediately evident to many of us with experience in IEEE 488 instruments was that, at first crack, a somewhat coherent test was taking shape–proving that VXI’s backplane triggering and tighter integration are superior to traditional rack and stack. Also, the coherent test was coming together via graphical programming, not in cryptic code and function calls.
Fixturing and physical interfacing, tasks typically underestimated, were easily and quickly handled by the VXI architecture. Modular screw-connection terminal modules were pulled from stock and used for the I/O connections.
It was also necessary to scale the arb output to 150 V to fully emulate the VRS at full rpm. As a result, a small gain stage was built on a B-size breadboard module. The breadboard module, borrowing power and some simple register control from the mainframe, also was a convenient place to locate other loads and interface circuits.
Performing the Test
Our neophyte had progressed from “box” to “job” in less than a week. This included interfacing the DUT and experimenting with the graphical instrument front panels.
Work then intensified toward making the controller function per the service manual. Functional states–battery-on, ignition-on, start and, most importantly, idle–were explored. “The fuel pump is activated for 4 s when ‘start’ is activated” was typical of the service-manual clues used to coarsely gauge if the effort was on track.
Our neophyte closed the loop between the controller and VXI hardware 15 days after the start of the project. The time required to perform the basic “read manifold air pressure (MAP), update arb” loop was measured at just over 1 s–not bad for a B-size and an IEEE 488 controller interface. Fortunately, a real engine doesn’t operate in the megahertz range, so the slow closed-loop time of a second could emulate movements of a foot on a gas pedal.
With engine start and rev sounds coming from the PC’s speakers, the core closed loop ran impressively: By turning a potentiometer, the VXI hardware measured the butterfly position and updated the arb, all the time keeping the check-engine light off.
Test With Hardware-in-the-Loop
Experiments continued. With the loop closed, the sensors and actuators managed by the controller were stressed. For example, visual displays showed that if a D/A output was slowly changed on the engine temperature block from cold to hot, the controller dutifully activated an auxiliary radiator fan.
In another example, again using slow D/A output changes on the O2 and MAP sensors, we could see the test fool the controller into thinking altitude was increasing. Admittedly, many of these experiments began as “See if you can get it to…” from the automotive experts.
Our neophyte speculated that the setup would be valuable to people other than test engineers. We agreed.
In one form, the setup is a hardware-in-the-loop incarnation, meaning electrical instrumentation is used in an electromechanical–or mechatronic, as it is called these days– model in place of metal devices. As a test, the closed-loop operation clearly flushes out many potential faults, especially those relating to component variability, effects of a real harness (when appropriate loads are included in the DUT fixture) and stress conditions.
The time to run the closed loop as a test could be as short as 2 to 3 min. But the setup also allows continuous operation in which individual sensors and actuators can be experimented with or functionally stressed.
Next Steps
In less than a month, it was hard to tell where the assignment had stopped and the extra credit had begun. We who witnessed the exercise felt good that a beginner–armed with a reasonable PC background, moderate history with Basic and C, and a week in HP VEE training–could get a significant assignment completed in a short time. VXI and graphical programming did prove to simplify the task and solve a complex problem.
By the way, we don’t call our neophyte a beginner any longer. Instead, we wonder if we should put ourselves “to the test.”
About the Author
Gary Culbertson has worked in the ATE and test and measurement industry for 20 years. Half of that time was spent as a telecommunications test engineer, the other half in new-product marketing at GenRad, Wavetek and currently at Hewlett-Packard. Mr. Culbertson has a B.A. degree in quantitative studies from The Johns Hopkins University. Hewlett-Packard Co., Measurement Systems Division, 815 S.W. 14th St., Loveland, CO 80537, (970) 679-3942.
Copyright 1995 Nelson Publishing Inc.
November 1995
|
|