First, You Simulate

As a product design engineer, you probably start a new design by producing a prototype. Then, it goes through seemingly endless testing, debugging, and redesign. But did you know that by first simulating an innovative process or product in software, you can easily run many "what-if" tests and quickly wring out problems before you build a prototype? Simulation can help you reach design goals faster and improve the chances of a successful product launch. Best of all (crack out the champagne here), you can apply simulation to almost any process described by data or equations and get these benefits.

An engineering team just took on a new task, say, developing an electronic engine-control unit (ECU) for use with truck engines. The engineers know it will take too long to build a prototype controller, program it with untested algorithms, and go through many debug-and-tweak steps to make it work with a real engine. So instead of building a prototype ECU, they start with simulation software that lets them quickly test and modify control algorithms.

Big Benefits With Simulation

As an added advantage, simulation software lets the team reuse algorithms and simulation code in other projects. Engineers can program simulation algorithms by linking software blocks that perform filtering, Fourier analysis, averaging, and other functions. They then can alter these blocks, link them with new code, or write new operations in C, C++, Visual Basic, or another language. Also, special software meant solely for simulation of complex systems makes it easy to set up simulations. Any simulation in software must perform the same functions prototype hardware and firmware would perform. (People often refer to simulation as rapid prototyping when designers mock up dials, switches, on-off lights, meters, and other elements on a monitor.)

After putting together their simulation code, the ECU designers "feed" their simulated device previously saved engine data—camshaft, and transmission speeds, oxygen concentration, and other characteristics—and observe how the algorithms manipulate the data. This simulation doesn't process information in real time, but it shows whether algorithms operate properly with real engine data. If the algorithms fail, the designers can rapidly adjust them and run more tests.

The what-if game: Some hardware-in-the-loop (HIL) systems include a controller that lets designers vary normal operating conditions that stress a simulated device with what-if situations. The controller also will let engineers automatically and rapidly test many operations.

In the next series of tests, the simulated ECU will obtain electrical signals from an engine. But that engine may exist only as electronics that simulate the engine. In effect, the ECU simulator connects to an engine simulator. This type of test setup, in which an electronic system rather than real equipment exists in the control loop, goes by the name hardware-in-the- loop (HIL). An HIL system proves effective when engineers can't obtain the actual equipment they plan to control. The equipment may cost too much to dedicate to testing, or it too may be under development. Using an HIL system also avoids the "smoke test," which, as its name implies, could damage expensive equipment.

Real Deal

Engineers may place real actuators, controls, and sensors in a control loop, but they may not be the actual hardware slated for the final product. During simulation of an automated transmission, for example, Eaton Corp. (Cleveland, OH) included a driver's seat, foot pedals, controls, and gauges, in the control loop. The simulator also provided sound for realistic feedback of transmission-shifting noises.

The ECU simulator must "see" the HIL version of a truck engine as indistinguishable from a real engine. The HIL tester could use an industrial PC and analog and digital I/O cards, or an embedded computer and specialized add-in cards for buses such as PXI, VXI, or Compact PCI. These cards can provide analog and digital I/O lines that accurately represent the simulated equipment.

3-Way Switch

You may be wondering where the HIL system's engine data come from. Engineers obtain it in one of three ways. First, they run an engine and measure the signals that go to the actuators and come from the sensors. Then they put the data in a look-up table. Based on inputs from the ECU simulator, the HIL system finds the values that correspond to that condition and sends them back to the ECU simulator. This approach requires extensive engine testing to ensure acquisition of data for all operating conditions.

Second, engineers can measure an engine's sensor and actuator signals and then derive equations that simulate an engine's operation. Third, the engine's designers can provide equations that accurately describe engine performance in the HIL system. These three approaches also apply to simulations of equipment such as jet engines, printer mechanisms, medical instruments, and disk drives.

So far, the HIL system simulates only a perfect engine, so the ECU designers may want to control the HIL system so it modifies the performance of the simulated engine. A controller might have the HIL system act like the "engine" has a clogged fuel injector at cylinder 3, a faulty oxygen sensor, a defective throttle-position sensor, or other problems. This sort of realistic testing lets the ECU designers determine how their simulation works under non-ideal engine conditions. And an HIL controller can run through programmed sequences of test to quickly check operation under many conditions. After proving the simulation produces the proper engine control, the designers can move on to rapidly develop real ECU hardware—the actual goal of the simulation.