Rapid Control Prototyping Buys Time

You're working on a new vehicle powered by a hybrid power plant that links an internal combustion engine with an electric motor. Simulations show the power plant's control algorithms work well, so you're anxious to find out if they'll actually run a linked engine and motor. You wonder if you can get the project moving faster: "Can't we test the algorithms on a computer with cards that monitor the sensors and drive the actuators?" In short, you can: Welcome to rapid control prototyping.

This technique, in which a standard computer temporarily replaces the actual controller, provides a way to rapidly test algorithms during the development of products such as laser printers, home appliances, adaptive cruise controllers, and hybrid-motor controllers. If designers uncover problems with a control algorithm while using a rapid control prototype, they can quickly modify their code and run another test. Often, rapid control prototyping uncovers operating conditions and transient phenomena that designers couldn't account for in initial simulations.

Tempers flaring: Testing evolving algorithms on changing hardware usually leads to shouting matches between the hardware and tsoftware developers. Because neither group can provide a stable product for the other to work with, communications often descend into shouting matches.

Rapid control prototyping also may diminish the battles between the algorithm developers and the controller developers. By testing algorithms independently on real hardware, designers can feed changed requirements to the controller design team without anyone feeling to blame for problems. Rapid control prototyping saves time because the power-plant designers don't have to wait for a complete prototype or breadboard of the final controller before they can test their control algorithms.

In the case of the vehicle described above, the algorithms would act to keep the hybrid power plant operating within limits established by torque curves and other empirical data. Most likely, the power-plant designers obtained this information during earlier, separate testing of the internal-combustion engine and the electric motor. The power-plant control algorithms also may incorporate data from flow charts or state diagrams that indicate, for example, which sensors to check, in what order, and when.

Code Soruce: A controller model supplies the code for a rapid control prototype and also for a final embedded controller that goes into production. The controller code may require a separate compilation, depending on the embedded processor chosen by the hardware-design team.

In most cases, software development takes place on a stand-alone PC and the process includes writing control algorithms and trying them out using simulation software. Designers can use packaged simulation software to develop algorithms or they can use a language such as C or Visual Basic to write algorithms from scratch. During initial testing, the algorithms don't control actuators or obtain data from sensors. Instead, they rely on stored data for "sensor" inputs and they display virtual "actuators" on a computer monitor. By first processing "canned" data and observing the results, the designers obtain a good indication of whether their algorithms work properly.

After determining that the algorithms and timing sequences operate properly, designers can transfer their software to the rapid control prototyping computer that will run the algorithms in real time. To avoid problems, use the same architecture in the development computer and in the rapid control prototype computer. This compatibility helps ensure software from one computer will run on the other. A rapid control prototype computer, though, will need a real-time operating system—instead of Windows—to keep up with the process it's supposed to control.

Unlike the development PC, the rapid control prototype computer must provide the necessary analog and digital I/O boards that will obtain signals from sensors and produce the signals that control actuators. Industrial-grade PCs as well as computers based on PC-104, Compact PCI, VXI, and PXI architectures accommodate a wide variety of digital and analog I/O add-in boards. Commercial simulation software usually comes with a list of compatible hardware that works directly with the software or with algorithms compiled by the simulation software.

As the designers run tests with the rapid prototype computer and tweak their algorithms, they also may change their hardware requirements. They may find, for example, that the control algorithms work well with an 8-bit analog-to-digital converter (ADC) rather than a 10-bit ADC on some sensors. They also may find the addition of two level detectors lets them better control something they didn't think about earlier.

It's unlikely the final controller will use a Windows PC. Instead, the controller design team will choose a low-cost microcontroller to do the job. Either the simulation software must provide code that will compile into instructions that run on the designated microcontroller, or the developers must translate their algorithms into code for the microcontroller. Although the latter task sounds onerous, if the simulation software can translate algorithms into C, the problem becomes manageable.

The design of the final controller still involves hardware and software issues such as using floating-point vs. fixed-point math, handling exceptions and errors, the use of watchdog timers, and so on. Rapid control prototyping doesn't eliminate the task of designing and testing a final controller, but it does let controller development run concurrent with real-time algorithm testing.