Fig 1. The functional test process comprises a number of steps, not all of which necessarily occur on the same manufacturing line or even in the same facility.
Fig 2. In a full-functional test scenario, the DUT is connected to actual loads with the intent of emulating the actual environment that the DUT will operate in.
Fig 3. This diagram shows a common topology for a DUT-assisted functional test system. Firmware in the DUT is used to set up outputs for measurement and to query the DUT for input status.
Fig 4. Shown are the key measurement and switching sections in a typical automotive functional test setup. In addition to a core complement of instruments, there will often be multi-channel instruments as well as high-frequency types (with added high-frequency switch elements).
Fig 5. Switch-matrix architectures in an automotive-test environment can be dauntingly complex. Single-wire and dual-wire types are common topologies.
It doesn’t take much examination of modern automobiles to figure out that they have become vastly more complex in just a few years. Even if you consider only the boom in infotainment systems, the amount of electronic content that vehicles use has exploded.
But it’s not all glitz and glamour when it comes to electronics and the automobile. Almost everything in today’s vehicles is under the sway of an electronic control unit (ECU), and that includes the safety features that we depend on to save lives in the event of a collision, most notably the braking systems.
Thus, the ante for testing the electronics in our vehicles is raised considerably. Compounded by the exploding complexity, functional test is a critical aspect of the design and development cycle in Detroit, Tokyo, and everywhere else vehicles are conceived.
Summing Up The Challenges
A key issue for automotive test is the proliferation of extremely complex distributed networks within today’s vehicles. There may be hundreds of ECUs that must communicate with each other over serial buses with fairly complex protocols. These include the CAN, LIN, and FlexRay buses. Moreover, a given distributed network may mean multiple buses with different protocols, or the same protocol with multiple signal speeds. That will introduce the need for gateways to help transition signals between these various bus protocols and/or signal speeds.
Most of today’s bench oscilloscopes from all of the major manufacturers (Agilent, LeCroy, and Tektronix) offer built-in serial analysis capabilities that enable you to trigger on specific data, address protocols, or errors on the bus. These scopes will also decode and search for specific packet content.
A related issue concerns the troubleshooting of the overall system, which means dealing with the gateways between multiple buses and protocols. This requires timing analysis to determine the causes of lag on packets as they migrate from bus to bus. In turn, this means being able to look at these multiple buses passing through the gateway simultaneously. Thus, the oscilloscope needs to support multiple speeds and decoding on multiple buses. Here again, all of the major scope makers provide equipment that fulfills these requirements.
“Our 5000 series scopes can view up to 16 decoded buses,” says Gina Bonini, technical marketing manager at Tektronix. “I’ve never seen a customer who needs to do that, but we do see the need to look at up to five buses to examine their relationships through the gateway.”
Scopes with built-in serial decoding aren’t new, of course, but Bonini expressed surprise that many engineers still aren’t aware that this functionality is available.
“Especially in the automotive space, this tool on a scope is a huge time saver,” says Bonini. “You can set up a hardware-based trigger in which the scope is looking at the incoming signal and watching for a packet. It can home in on very specific data. The scope monitors the incoming signal until it sees that data and then triggers.”
In capturing signals for this process, modern scopes can take in many millions of data points, which translates into many thousands of packets. The scopes’ search tools can then be applied to find specific addresses, data packages, or errors. “This not only helps to validate the bus but also helps you to see what is really happening in your system,” says Bonini.
Another trend complicating automotive test is the proliferation of wireless. Wireless sensors for tire-pressure monitoring, Bluetooth connectivity from cellular handsets to the vehicle, and other wireless sensors mean that test engineers must deal with RF signals. An instrument such as Tektronix’s recently introduced MDO4000, which combines an oscilloscope with a spectrum analyzer, is well suited for debugging and troubleshooting such wireless links (see “A Hands-On Look At Tek’s MDO4000 Mixed-Domain Scope” at www.electronicdesign.com).
A final aspect of automotive test that can cause issues is the lack of a rock-solid earth ground in a vehicle. A scope such as Tek’s TPS2000 series circumvents this issue with isolated channels that allow floating measurements. Thanks to the channel isolation, each channel has its own ground reference. The scope is also battery powered for easy portability.
Function Is Everything
Broadly speaking, electronic functional test proves that an electronic product is fully functional. It’s used to demonstrate that an assembly (or sub-assembly) meets the design specifications. In an R&D context, functional test simply verifies that the design concept is viable. In this setting, test setups need to be quickly configurable and very flexible. Test of this nature is typically done on the lab bench. The goal is to probe for the limits and weaknesses of the design (see “Hints And Tips For Electronic Functional Test Implementations” at www.electronicdesign.com).
In the context of manufacturing, reliability and repeatability become the paramount concerns for functional test. Here, functional test becomes a line of defense against shipping “bad” products. As such it’s seen in all industries and all portions of the product lifecycle.
If we take a “big-picture” view of the manufacturing process, we see a series of steps in functional test (Fig. 1). Not all of these steps would necessarily occur on the same manufacturing line. They might even occur in different locations or different companies’ facilities. It begins with printed-circuit-board (PCB) assembly processes and part placement. Tests continue along the way during surface-mount assembly, including in-circuit test. These tests can be optical or x-ray tests at the PCB level.
“All manufacturers strive to push the test process as far up the production line as they can go. The earlier in the process you are, the lower the cost of test is,” says Al Lesko, an applications engineer at Agilent Technologies. “As you populate boards, test incurs higher cost. So the earlier in the process you can catch defects, the better off you are.”
After in-circuit test and once the PCB has been deemed correct, final assembly takes place. For example, with brake systems, final assembly means attaching aluminum covers on top and bottom. Often, burn-in takes place at that point in an attempt to induce infant mortality. Burn-in can be simple application of heat, or it can be temperature cycling while the unit is powered up and operating.
The last stage is functional test, where a couple of primary strategies predominate. One is full functional test, in which the device under test (DUT) is connected to actual loads with the intent of emulating the actual environment that the DUT will operate in (Fig. 2). This includes stimulus inputs and correct loads for the DUT outputs.
For example, if you are testing an analog brake system, you would apply loads that the system would see in actual operation, including the hydraulic solenoids and sensors. Then you would run through an emulation in which you apply wheel speed, perform a panic stop, and see how the system performs.
Full-functional test has the advantage of really shaking out a system and putting it through its paces. On the downside, it is a relatively slow test strategy, so it is more common during development, manufacturing burn-in, or quality-control life and durability testing, when time is not so critical.
The second strategy, known as DUT-assisted test, is most often used in manufacturing test due to the higher throughput requirements (Fig. 3). This highly reusable testing methodology depends on embedded firmware within the DUT to exercise it. DUT-assisted test allows test engineers to isolate blocks within the system and test them one at a time. For instance, a known stimulus could be applied to DUT inputs, and the DUT can be queried via the serial communications link to determine what it measured on its inputs.
It is important that the DUT is designed to support this testing method. During DUT development, the firmware needs to be developed to support a “test mode” of operation, in which a communication session using the DUT’s serial input port can be established and a test command set implemented. This requires a close working relationship with the development groups to ensure the commands needed for DUT-assisted test are implemented.
Test System Topology
A very common test-system topology includes a full complement of instruments, including digital multimeters (DMMs), sources, digitizers, digital-to-analog converters (DACs), and arbitrary waveform generators, all of which are connected to a switching matrix and in turn to the DUT (Fig. 3, again). The switching matrix at this measurement core is very flexible, and the addition of some RF switches makes it even more so.
A closer look at the switching and measurement core of the test system reveals three major blocks (Fig. 4). Depending on the test needs at any given time, only one, two, or all three may be present.
For low-frequency (<10 MHz) measurement needs, the basics include a 6.5-digit DMM, which provides designers with traceability back to National Institute of Standards and Technology (NIST) standards. A basic digitizer is a must for waveform captures. Automotive applications call for the ability to handle voltages of up to 200 V with a sweet spot of about 20 Msamples/s for speed.
A DAC serves as a multi-channel voltage and/or current source, complete with remote sensing. Ideally, DACs should be isolated from chassis ground, which enables you to do interesting things like stacking them to achieve higher voltages. It’s not uncommon, in an automotive functional test setup, to need at least 16 to 20 V.
“When we design DACs focused on automotive test, we strive for ±16 V with isolation so that you can stack them and get higher voltages,” says Lesko. Remote sensing is also a key feature, because the DUT might be some distance from the test rack, in which case you might have noticeable voltage drop in the cabling.
Arbitrary waveform generators come in handy when, for example, you want to emulate the activity in an antilock braking system (ABS), such as a wheel-speed sensor. “I worked on the ABS module in the Mercury Mystique,” says Lesko. “The wheel sensor put out a low-speed signal, but you did need sweep capability to emulate the ABS activity. We had to slowly ramp up the speed and then ramp it down quickly to emulate a panic stop.”
In some cases it is desirable to provide direct, multi-channel stimulus/response signals as shown in the second block (Fig. 4, again). Multi-channel stimulus/response blocks are typically used to improve test throughput.
Higher-frequency instrumentation may be needed in cases such as wireless or telematic testing. The instrumentation could be as simple as a wide-bandwidth digitizing scope, a signal generator, or even a complete vector signal analyzer.
But when signal frequencies are greater than 10 or 20 MHz, they can’t be run through a general high-density switching matrix. In those cases either direct connections or RF/microwave switching elements must be used to overcome bandwidth limitations. This can be especially important when testing navigation, telematics, or infotainment systems.
Another potential addition to the core instrumentation might be a frequency counter. But all in all, a core complement of this sort is used over and over in automotive test applications.
Into The Matrix
The switching matrix itself is very flexible. Matrix architectures can be quite complex (Fig. 5). A 32-by-32 matrix can be overwhelmingly so. One compromise uses a fan implementation, which is popular because fan implementations are easily expanded by daisy-chaining to access more DUTs.
There are two primary switch-matrix topologies to consider: single-wire and dual-wire types. Each has advantages and disadvantages. A single-wire topology uses only one relay per crosspoint and is also very flexible. However, signal fidelity can suffer. A dual-wire topology provides higher signal fidelity but comes at a higher cost because you need two relays at each crosspoint. Both topologies are seen in automotive-test applications.
It’s worthwhile to mention that because the test system can be situated at some distance from the DUT, good engineering practices should be observed in wiring the system together. Twisted-pair interconnects work best in these cases to reduce noise, crosstalk, and ground loops.
Because functional test is switch intensive, care must be taken in terms of selecting switches for the matrix. Designers have three main options: FET switches, reed relays, and armature relays.
FET switches are great if you need very high-speed switching and can tolerate higher on resistance. They have virtually infinite lifetimes, but being solid-state devices, they’re more prone to static damage than mechanical relays and can’t tolerate as high a voltage or current as relays since there is no additional isolation between the control circuitry and the signal path.
Reed relays offer high switching speeds and have higher voltage and current handling capability than FETs, while also providing for a low contact resistance. Armature relays are popular for their ruggedness and support for higher currents and voltages than the other options. They also offer a low resistance, but generally have slower switch times. Generally speaking, relays switch more slowly than do FETs and are mechanically larger.
Hardware In The Loop
Having examined a typical test setup, we’ll now take a closer look at the explosion in software in the automotive arena and how it has impacted test. As the number of lines of code grows, it’s safe to assume that the number of bugs will grow as well. “These are really defects in the vehicle, implemented in software,” says Chris Washington, National Instruments’ senior product manager for hardware-in-the-loop (HIL) and real-time test.
As a result, the exploding amount of software in vehicles presents significant challenges to test engineers for quality and safety. HIL test has proved to be a viable means of mitigating that growing challenge.
Testing of ECU firmware can be accomplished sooner, more thoroughly, and with more repeatability. By replacing the hardware components with models, you can test scenarios that would result in catastrophic failure of the real-world hardware. A common scenario in the aerospace world is an aircraft experiencing total engine failure. The automotive corollary would be running an engine with no oil.
A typical example of an HIL testing situation would be for an engine position sensor that would feed its signal to an ECU, which in turn is running firmware that calculates engine timing. In HIL testing, you can replace the sensor with a software model and run a simulation.
“The system doesn’t know if it’s connected to the real world or a simulated world,” says Washington. “It’s virtual reality for the controller being tested by simulating the sensors and actuators.” There’s no slowing down the real world, so you need real time to execute simulations very deterministically.
If you were testing a braking controller, one way to do it would be to have a dynamometer to simulate the inertial load on the axle. A real hardware brake can be applied to the dynamometer to facilitate test of the antilock braking algorithm to see how fast it can stop the system.
But with an HIL strategy, the brake-control ECU is connected to a simulated environment and a hardware brake is no longer necessary. The HIL is connected to a wheel speed sensor and to the ECU’s actuator outputs, which can then pump the simulated brake as in an ABS system. All that is fed back into the simulation.
“You can now have multiple terrains, multiple types of tires, swap out any variable in the system,” says Washington. Simulations can be run overnight to test all possible combinations of axles or brakes you might want to verify for the fleet. The combinations can be queued up to learn how an ABS algorithm works for each combination.
For HIL purposes, National Instruments’ Veristand product provides a sophisticated test framework within which to perform real-time simulation, data logging, and more. “With LabVIEW, test engineers have a development environment that’s graphical, quick, and with connections to hardware I/O,” says Washington. “But what we found is customers didn’t want to write and maintain this level of application themselves.” NI Veristand gives them an off-the-shelf framework for real-time HIL testing.
Meld Measurement, Analysis
In a typical scenario in almost any test-lab environment, data is gathered on instruments, typically oscilloscopes, and then transferred to a secondary environment for analysis, which is often Matlab from the MathWorks. But users of Agilent scopes have the option of acquiring their instruments with Matlab already installed.
Rather than forcing engineers to go through a two-stage work flow of gathering data with the instrument and dumping it to a PC for analysis, Agilent’s instruments now run Windows, which enables installation of Matlab for immediate analysis.
“You can do some monitoring and filtering on the fly in real time,” explains Wensi Jin, automotive industry marketing manager at the MathWorks. “But it’s typically a large amount of data, so it’s not a good idea to filter the data as it’s being collected.”