Determining that a control system works before you build it seems like a contradiction. At best, it represents a considerable challenge. Years ago—when the industry was young—you could build a prototype, try it out, make modifications, try them out, and so on. Today, this approach generally falls short for three main reasons.

First, building prototypes is time-consuming and expensive. With today's accelerated development schedules and demands for ever-shorter time-to-market, manufacturers rarely can afford the luxury of this time-honored technique.

Second, and equally important, systems today are generally too big or too small to lend themselves easily to prototyping. Application-specific integrated circuits (ASICs) and other complex components are generally not ready in time for the prototyping step, so the prototype cannot accurately achieve the expected performance of the final system.

Finally, prototyping involves making one of a product. Therefore, making a prototype yields no insight into the challenges of full-scale production.

But what is the alternative? Increasingly, companies turn to the twin techniques of simulation and emulation.

Although many people use the two terms interchangeably, simulation and emulation remain quite different. Simulation models a product or subsystem entirely in software, primarily so an engineer can examine alternatives and improve the design either to facilitate manufacturing or to improve performance. A powerful tool while the product sits on the drawing board, simulation, however, offers fewer benefits once production begins because simulation can tell you how the product should behave. It cannot tell you how a particular copy of the product does behave. Also, simulating a relatively complex control system can, in many cases, be inconveniently time-consuming, further limiting its applicability to the production environment.

Emulation differs from simulation in several key areas. According to Dennis Howe's Free On-Line Dictionary of Computing, one system is said to emulate another when it performs in exactly the same way, although not necessarily at the same speed. Emulation substitutes software and special hardware for parts of a product's architecture, which permits examining the product or its subsystems in real time, including the function of the control software. It allows "stopping the clock" for engineers to look at transient states that, in normal operation, never linger long enough to be observed or measured.

Emulators can map a product's entire design onto FPGAs (field programmable gate arrays) or other custom programmable devices. An emulation setup can mimic several parts of a system under program control. During manufacturing test, addressing these subsystems separately reduces the test's overall complexity by drastically limiting the scope of each section of the test. In addition, by hooking signals through an emulator to a "real" section of the product, engineers can observe actual responses to those signals from various hardware and software versions. This approach predicts what the product's performance will be when it runs the actual control application and how modifications and revisions affect that performance.

Combining emulation results with additional software-based simulation can further improve the product's design. Emulation is particularly valuable with large control systems because manufacturers can begin debugging a product earlier in its lifecycle than if the test required a prototype or a full working system, reducing development time considerably. Manufacturers of chips or devices often help with technology integration by providing test or development kits with simulation or emulation functions, especially useful for smaller system development.

During preproduction and "ramp-up" manufacturing stages, emulation allows testing a product even if some pieces don't yet exist. When those pieces finally arrive (assuming that they work), they can be "dropped into" the product seamlessly with minimum effort. Early feedback from this point in the manufacturing cycle helps anticipate how the product will perform in the field, while encouraging faster startups with fewer surprises on the factory floor.

Advanced emulation systems permit data input from free-running systems (systems running at their normal operating speeds) without halting their operation, improving the accuracy and usefulness of results. Texas Instruments' PCIBus JTAG scan-based emulator, for example, offers a data link that helps reduce the problem of "vanishing visibility" as processor speeds increase. That is, emulators can test a control system without bed-of-nails access to its printed-circuit boards for in-circuit test and without the need for the line-of-sight visibility that optical inspection requires.

In addition, engineers gain critical insight into systems where control of peripherals, data buses, and other components reside on on-board devices. In such cases, tracking how an actual application executes inside the chip or finding a test point for data access is almost impossible. However, emulators can transfer data to and from the host-development platform and target processor, download code, and view complex data sequences "on-the-fly" without compromising the product's ability to run at full speed.

Although most manufacturers have adopted simulation and emulation at some point during the development cycle, a separate team generally handles each technique, according to the "Testbench Acceleration" white paper from Verisity. One critical concern with both simulation and emulation is the source of test and verification patterns

For example, the emulation team may adopt random test vectors created especially for that step. To provide the best and most accurate picture of product performance, however, they often incorporate recorded stimuli captured during "what-if" simulation or include data traffic generated by a dedicated tester or by a "real" environment (such as an actual network's stream of data packets). Of the three alternatives, simulation stimuli can prove most useful because they will likely include extreme conditions—such as data that generate a "divide-by-zero." If such conditions are sufficiently rare, randomly generated test vectors and subsets of real-life operation vectors will likely not find them.

Exercising stimuli captured during simulation requires sending each vector to the emulation workbench, executing it in software, and monitoring the results. Some manufacturers try to combine the two processes by connecting a workstation to an emulator through an API-like communication bus that most emulators provide, or by creating testbenches that may then be simulated.

Cimetrix, for example, offers a family of open-architecture machine-modeling and motion-control software products for multi-axis machine-control applications. The company's so-called "simulation environment" emulates operation of the final product to permit developing hardware and software simultaneously. Cimetrix also provides an off-line environment for building machine models and developing software applications that will run identically in the models and in the final control system.

Again, manufacturers can begin developing applications software before real hardware becomes available—or is even fully defined. The company claims that its approach reduces time required for product implementation by up to 70%.

By allowing manufacturers to test control systems off-line, emulation removes this process step from the start-up critical path, according to Rockwell Automation, which makes an emulator called the RSTestStand. This tool permits tests for device failures and system responses in a controlled way. It simplifies connecting software to the test stand because it does not require actually wiring physical devices, yet it can create snapshots of running control-system processes under test. Also, because much of the emulation occurs in software, engineers can save and reload applications easily to check out different possible stimulus combinations and alternatives. Rockwell's TestStand presents emulation results as visual elements on a conventional PC display. The manufacturer contends that visualization permits better understanding of the complex relationships among many control elements that react in unpredictable ways to relatively rare conditions. That same display can be used for training operators and maintenance technicians without tying up expensive equipment on the factory floor.

To illustrate this idea, consider Voith Siemens' (York, PA) installation of new controls for the massive St. Lawrence-Franklin D. Roosevelt Power Project in Massena, NY. The project includes 16 hydroelectric-powered 70-MW turbines on each side of the U.S.-Canadian border. Each generator is controlled by an Rockwell Automation controller (Allen-Bradley ControlLogix), which manages alarm triggering, cooling and lubrication, auto-shutdown, and pump and valve operation.

In the past, Voith Siemens tested the units' control systems with a hard-wired test stand that required actual equipment to receive test inputs and to produce corresponding outputs. The process was expensive and time-consuming and often introduced its own errors into the mix. This type of test permitted only a limited number of switches, lamps, and other test components. As a result, Voith Siemens had to exchange equipment or rewire the test stand in mid-test, eliminating incoherent, one-shot testing of an system. The sometimes incorrectly wired equipment produced suspect results.

"Hard-wired tests can take a long time to set up, and any equipment misconfiguration will compromise their accuracy," comments Darryl Stevenson, project leader for Voith Siemens. "We needed to shorten the process and improve the results." Stevenson also says Voith Siemens often had to develop custom simulation code in addition to the hardware to perform a proper test. Extra code added another level of complexity and possible source of error.

By replacing physical-plant inputs—pumps, sensors, etc.—with RSTestSTand, users could examine the controller's actual performance through software manipulations. With the new system, adding a pump or switch to the system configuration requires only a software change, eliminating restrictions on the number of available test resources. The test stand can be easily configured through the software interface to represent a wide variety of processes—discrete and continuous—then respond to many different control signals in those processes.

With the new approach, Voith Siemens could completely test an entire unit's controls in a fully integrated environment, improving the accuracy and timeliness of results. In addition, far less custom code development allowed engineers to focus more on testing end applications. Modularity of the system also permits easier code re-use, saving time when changes or upgrades are needed.

The soft economy is forcing electronics manufacturers and other companies to rethink the costs and paybacks of ramp-up to full production. Substituting emulation for portions of the system during test permits concurrent hardware, software, and application development. The critical issue is—as it has always been—time to market. Emulation can offer benefits over hardware prototypes and pure simulation. Resulting methodologies can achieve the twin goals of reducing time-to-market and associated development costs.

“Test Your Control System with Simulation”

“Simulate Your Embedded System”

“Model, Simulate, Execute Simulation in Discrete Control”

“Adaptive Controllers Work Smarter, not Harder”

Also, searching on keyword emulation at the Control Engineering Bookstore brings up several relevant titles.