August 1, 1997

Electromechanical Simulation: Tackling Control Systems Takes Talent and Tools

DAN STRASSBERG, SENIOR TECHNICAL EDITOR

Designing µP-based electromechanical systems is no job for a lone-wolf developer; one person can't possess all the needed expertise. And with today's demanding schedules, even multidisciplinary teams need powerful software and, often, hardware tools.

Wherever µPs manage moving mechanisms, successful marriages of electromechanical (EM) and electronic components depend on the teamwork of people with varied skills. Whether the product is an implantable intravenous infusion pump, an automobile-engine control, an automatic-braking or flight-control system, or a steel rolling mill, the design team needs broad expertise. Skills in dynamic-systems analysis and modeling, EM design, embedded-hardware design, and real-time software are all essential. Yet, even with all of these talents, the experts require something more to meet today's tight schedules: a powerful array of software and, often, hardware tools.

Central to EM-system developers' tool suites are graphical-modeling tools. (The box "For more information..." lists many such tools.) But don't think that you can draw a picture of a physical system on your workstation or PC screen and have the computer turn out a mathematical model. The software doesn't work that way--at least not yet. To obtain a model that approximates a system of even moderate complexity, you have to understand what models of similar systems look like and why. You should also have a strong mathematical background and some experience in modeling systems without the aid of a computer.

Engineers develop most EM models from first principles (that is, from an understanding of the physics of the system). Usually, suppliers of components, such as motors and actuators, supply device models. Nevertheless, combining the device models into a system model is not a trivial task.

Another way to develop system or subsystem models, however, is a technique known as "system identification." You apply known stimuli to the unit whose characteristics you want to describe mathematically and then measure the unit's responses. You then submit records of the stimuli and responses to the system-identification software, which produces a model.

Although the idea of letting a computer create models in this way seems appealing, the technique has achieved only limited acceptance. The main adherents are engineers who need to keep old systems running--on automated assembly lines, for example. Models created when such systems were new may no longer be sufficiently accurate because of wear in mechanical parts. Wear can introduce deadbands, which produce oscillation and instability that necessitate modification of control algorithms.

Developing and implementing control algorithms are key responsibilities of EM-system designers (see box "Simulating a disk-drive head positioner"). System modeling is important to these engineers for two main reasons: In most cases, control-algorithm design cannot be completed without a mathematical model of the system under control. Moreover, experiments on the real system are usually impractical until you are highly confident of success; failed experiments could cost both money and lives!

Still, exact system models are often unavailable. The thermostat that regulates your household temperature typifies controllers whose designers cannot work from accurate models of the controlled system. The need to produce devices that work in a variety of houses forces thermostat designers to use generalized models. The homeowner or the fuel dealer adjusts the deadband and on/off times by trial and error to empirically tune the "control algorithms." The trial-and-error approach works in this case because the consequences of improper adjustment are minor.

Avoid severe consequences

When the consequences are severe, however, there has to be another way to develop system or subsystem models, optimize control algorithms, and evaluate system performance. In fact, there are several other ways. Some companies lump multiple techniques into one category, called "hardware-in-the-loop (HIL) simulation." Other companies are emphatic that the name "HIL" belongs to only one member of that category. The simulation techniques are:

Rapid prototyping (RP): In RP, you use the real controller to control a computer simulation of the system that the controller is supposed to control. In this context, RP is unrelated to the similarly named technique in which packaging designers use laser and optical technology to turn liquid polymers into lifelike, albeit static, 3-D product models.

HIL: In HIL, you use a computer simulation of the controller to control some or all of the actual hardware that the real controller will ultimately control.

Virtual prototyping: In this technique, both the controller and the system under control exist solely as models running on a computer.

Getting meaningful results

Regardless of which technique you use, getting meaningful results is tricky. The problem is that the systems are dynamic, and the dynamics are absolutely central to the correct design of control algorithms. If you are simulating the controlled hardware and the simulation runs more slowly than the real system, you must insert delays into your controller to compensate. If you are using a simulated controller with real hardware, the problems are equally challenging. The simulated controller has to run at the same speed as the real one.

Designers might choose to build a cost-critical product--say, a subsystem of a mass-market automobile--around an 8-bit microcontroller running hand-optimized code without the benefit of a real-time operating system (RTOS). On the other hand, the prototype controller might use a faster 32-bit processor. But the more powerful processor probably runs compiled ANSI C code under an RTOS. Will the faster, more powerful processor run the much less compact code as fast as the less expensive processor runs the hand-optimized code? You need to know before you can trust the simulation results.

Code size and execution speed are, of course, also important in aspects of system development unrelated to simulation. These factors should be high on your list of criteria for selecting the tools you use to generate your code. Different tools can produce code whose efficiency differs dramatically. This statement is true whether you use memory consumption or execution speed to measure efficiency.

Different criteria

Nevertheless, if your product is large and expensive and you plan to build it in fairly small quantities, you may care little about minimizing the controller's cost, size, or power consumption. Your top priority is probably holding down the development time, which would be the case with such products as locomotives or steel rolling mills. When shortening development time is your top priority, you should give little weight to code efficiency; instead, select tools that emphasize ease of use.

One factor that distinguishes today's control systems from those that were common a decade or more ago is today's emphasis on controllers that implement sequential state machines (see box "Clearly state what you mean"). Though the use of state machines in controllers is no surprise in an age of digital electronics, it has significantly affected simulation- and system-design software. Classical control systems were linear; they treated nonlinear effects by approximating them as linear. This force-fit is no longer appropriate. More and more modern simulation and synthesis tools integrate state-machine design and analysis. Simulators handle systems whose parameters change as they operate.

In an era of state-machine-based control systems, system specifications are more important than ever. Any well-run design project should begin with a specification that explains the system behavior. Only if you clearly communicate your design intent to the design-team members and to the customers or marketers can you hope that your project will succeed.

Historically, a specification has been a document several inches thick, even for a system of only moderate complexity. These documents made great bedtime reading for insomniacs because after a few minutes of reading, most readers' eyes would glaze over. This was great if you were trying to get to sleep, but not so good if you were trying to figure out how the system was supposed to work.

Executable specifications

Within the past few years, software vendors have come to the aid of design teams by introducing a new concept--the executable specification. An executable specification is a relatively compact piece of software that simulates a system's user interface. In many cases, the executable specification also simulates the system's internal behavior, albeit at a macroscopic level. The system's responses appear on a PC's or workstation's screen. Users click a mouse to simulate pressing buttons and turning knobs.

An executable specification need not be photo-realistic; that is, the controls and displays don't have to look like those on the actual hardware. The executable specification need not include such niceties as animated graphics of motors whose rotation you can observe. A simple box labeled "motor" containing smaller boxes labeled "running" and "stopped" may be all you need.

But don't underestimate the importance of photo-realism in an executable specification. Companies such as Altia Design, Emultek, and Virtual Prototypes, whose software creates photo-realistic executable specifications, call such specifications invaluable competitive tools. Suppose two companies compete for a contract. One company's proposal includes a photo-realistic executable specification; the other's includes a written specification. The company that provides the executable specification wins the job every time. And according to Mike Juran, president of Altia Design, creating the executable specification takes less time than creating the written specification.

References

1. Lewis, Paul H, and Chang Yang, Basic Control Systems Engineering, Prentice-Hall, Upper Saddle River, NJ, 1997.

2. Lukich, Michael S, "Rapid prototyping of embedded systems: 1997 update," Society of Automotive Engineers 1997 Earthmoving-Industry Conference, Paper no. 97EIC-17.

| EDN Access | Feedback | Table of Contents |