Embedded systems were incorporated into commercial automobiles around the 1970s. At first, these embedded systems were used to control the timing of fuel-injection systems, a substantial improvement over the carburetors installed in most cars at the time.
From there, other embedded systems were developed that significantly contributed to key technologies of the automotive world, namely, anti-lock braking systems (ABS) and cruise control. Today, this trend continues with automotive suppliers creating even more innovative technologies such as adaptive cruise control and smart radar systems to avoid collisions.
While tools for creating these innovative technologies have progressed to meet the needs on the design side, testing processes have not advanced as quickly. New technologies such as adaptive cruise control obviously are complex embedded systems requiring custom testing tools.
Often, these custom testing tools have been developed in-house with significant costs up front followed by continuing support and maintenance expenses. Along with the costs, project managers must deal with the delays introduced by building custom test tools. These delays are especially costly in an industry where time-to-market is important.
As the race to deliver new technologies intensifies, automotive engineering managers are focusing on ways to remove the testing process as a bottleneck. At the core is a need for more powerful testing tools to address the complexity of new embedded systems.
At the same time, it is necessary to reduce the costs and development time to meet market demand and generate revenue. With technologies such as virtual instrumentation, automotive design and test engineers can leverage commercial off-the-shelf (COTS) technology to address some of these needs today.
Embedded System-Development Process
To understand the testing bottleneck associated with developing automotive embedded systems, first let’s look at the general engineering process. This development process can be broken down into four basic stages (Figure 1). The first stage consists of model identification where design engineers create a model of the embedded control strategy they will implement. This often is done on a workstation or desktop PC with a standard programming language like ANSI C or a control design software package.
In the second stage, the engineer runs this control strategy in a simulated environment on the desktop PC or workstation. At this point, the engineer must analyze the control strategy, find basic flaws in the design, and try to optimize the control strategy.
During the third stage, the design engineer will create a hardware prototype of the system. This hardware prototype may be connected to an actual system or run with a hardware simulator. After this hardware prototype is thoroughly tested, the engineer moves to the fourth stage, where the system is produced.
Within these four stages, testing plays a vital role; however, creating and verifying hardware prototypes present the most challenging tasks. While situations vary for each new design, typically verifying the hardware prototypes is a very tedious process. Here are two examples of how verification is done.
Prototyping a Collision Detection System
Let us consider the development process of an embedded system for collision detection. This system uses radar to detect when a vehicle is too close to another vehicle or an obstruction. A driver could use collision detection to safely back into tight parking spots, or the system might warn the driver before merging into a lane with a vehicle in a blind spot.
Given the nature of a collision-detection system, field trials can help verify the behavior of the embedded system. However, to run field trials, the design engineer first builds a hardware prototype system, embeds it within the vehicle, and connects it to the sensors (the radar in this case). Based on information gathered from each trial, the engineer may want to modify the embedded software to try out new design features. With a hardware prototype made of proprietary equipment, downloading new embedded software can be difficult and time-consuming.
Dynamic Testing of a Complex Embedded System
Next, we will look at testing a complex embedded system such as a powertrain control module. In this case, running field trials with a hardware prototype may result in a catastrophe.
One way to avoid this is using a hardware simulator to emulate the environment around the powertrain control module. This often is called Hardware-in-the-Loop (HIL) testing where a piece of hardware is running embedded software to simulate the environment.
The powertrain control module’s environment contains a great many dynamic characteristics. For instance, a given input into the HIL simulator will generate different results based on whatever the previous inputs were. Creating these complex HIL-based test systems can take up to hundreds of thousands of dollars to build just the hardware and up to a year of engineering time.
In both of these examples, proprietary hardware was considered an option but obviously would cause more bottlenecks in the development process. Now there are alternative approaches that can reduce the development cycle and save engineering costs at the same time.
One of these alternatives is virtual instrumentation, which focuses on the tight integration of COTS hardware with rapid development software to build customized test systems. With automotive companies now adopting it for prototyping embedded systems, they too are benefiting from the lower cost solutions and reduced development time.
More Powerful Tools for Faster Development
To further understand how virtual instrumentation can be used for rapid prototyping and HIL testing systems, it is helpful to concentrate on a few important technologies and how they reduce development time.
Graphical tools such as LabVIEW can be used for designing automotive embedded systems. With a heavy emphasis on control strategies and algorithms, embedded software in automotive electronics is much easier to visualize graphically (Figure 2). In addition, graphical tools speed development time for control design.
Graphical tools now provide better mechanisms to download software to embedded systems. This is especially important when creating hardware prototypes for verification. Engineers can easily make changes in the control program and download a revised control algorithm into the hardware prototype. This form of rapid control prototyping decreases the time it takes to iterate between design revisions, which cuts down the entire prototype/verification phase.
Tight Hardware and Software Integration
Tight hardware integration is another key component of rapid control prototyping. Building an entire hardware prototype and verifying that it runs the embedded software are challenging. With COTS real-time hardware systems such as PXI, engineers can mount the embedded PXI system within the vehicle for rapid control prototyping or use it as an industrial test bench for HIL testing.
The embedded PXI systems include integrated hardware I/O for direct connectivity to sensors, signals, and actuators. There are built-in libraries for I/O including analog and digital signals, counters, timers, motion control, and dynamic signal acquisition. This removes the hassle of developing custom drivers for proprietary hardware.
Rapid Control Prototyping
Visteon, a company with nearly 79,000 employees in 25 countries and 2001 global sales revenues of $17.8 B, develops a variety of integrated automotive systems. Recently, the company adopted LabVIEW Real-Time and PXI for the rapid control prototyping of next-generation automobile control systems such as adaptive cruise control.
Adaptive cruise-control technology gives a car the capability to automatically slow down or speed up depending on the location of other cars it senses on the road ahead. Visteon engineers can test a variety of control and interface algorithms and then quickly make changes and improvements to the systems design.
The engineers develop a control strategy on a host computer and download it to the RT PXI system, which then is mounted in the car’s trunk. The RT PXI system is connected to the rest of the communications inside the vehicle to read data from the special radar mounted behind the car’s front grill. The RT PXI system maintains a safe following distance and controls the engine and brakes.
Conclusion
Rapid control prototyping using standard software and hardware automotive control systems minimizes the cycle time to try out new design ideas and shortens the overall design process. This is especially useful where complex algorithms for applications such as adaptive cruise control, powertrain control systems, and ABS eventually must be embedded in cars.
About the Author
Shawn Liu is a product manager at National Instruments. Before he joined marketing, he worked as an applications engineer providing technical support for LabVIEW, Measurement Studio, data acquisition, and real-time products for National Instruments. Mr. Liu holds a B.S. in electrical engineering from the University of Texas at Austin. National Instruments, 11500 Mopac Expressway, Austin, TX 78759, 512-683-8378, e-mail: [email protected]
For more information:
www.rsleads.com/207ee-239
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2002 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
July 2002