Real-time controls prototyping

During the spring semester, I had the opportunity to teach a real-time control development course. Our target area was automotive systems, and I wanted to take students through a complete cycle of development from prototyping to deployment on an embedded system. The ultimate task for the students was to develop a real-time air flow controller for an engine using actual mass air flow (MAF) sens...

By Thomas R. Kurfess, Clemson University International Center for Automotive Research October 1, 2008

During the spring semester, I had the opportunity to teach a real-time control development course. Our target area was automotive systems, and I wanted to take students through a complete cycle of development from prototyping to deployment on an embedded system.

The ultimate task for the students was to develop a real-time air flow controller for an engine using actual mass air flow (MAF) sensors and electronic throttle body valves (ETVs) implemented on a 32-bit ARM processor. The development platform that made it possible was LabVIEW real-time. Many of the students did not have any LabVIEW programming experience, so they also had to learn to program LabVIEW. For the first couple of weeks we reviewed PID control concepts and signal processing. For homework, the students went through the self-paced LabVIEW tutorials. By the third week, we were ready to start programming in real-time.

For their first set of labs, the students were given a Bosch ETV and told to determine its characteristics and dynamics using the LabVIEW system ID tool kit and manufacturer specifications. Once I/O and system parameters were understood, the teams of two were told to control the position of the ETV. The feedback mechanism on the ETV is a potentiometer, so they controlled position by measuring the resistance value on that sensor. A PID control was implemented on the valve position. After tuning, the students learned that a PI control was the actual way to go, as the D gain was virtually zero.

Initial programming was done on a 400 MHz Power PC operating on a Compact RIO (cRIO). To give the students a feel for changing target processors, the FPGA (3 million gate, 40 MHz clock) on the cRIO was used as a second target. The only real change that the students needed to make was to avoid any floating point calculations on the FPGA, which was quite easy. Neither the Power PC nor the FPGA were taxed at all by the control requirements. Finally, the target was changed to the ARM processor (ARM7TDMI-S based high-performance 32-bit RISC Microcontroller with Thumb extensions). We were expecting to have to keep the integer programming limitation from the FPGA, but to our surprise, the ARM processor had a nice floating point emulator that worked quite well for our purposes.

Generating the flow

The next step was to insert the MAF into the feedback loop. To do this, a large fan was used to generate the flow that would normally be seen by an operating automobile engine. The MAF output is a frequency proportional to the rate of airflow. To simplify the programming of the overall system, a frequency to voltage converter chip was used.

Within a few days, the students were controlling the air flow without any problem. They did have to retune their controllers because of the inherent lag in the actual system. However, this was easily done with the system ID and control design tool kits. For their final exam, I provided them with a Delphi ETV rather than a Bosch. They had to redesign their controllers, within a week, to yield the same performance as the Bosch ETVs. This type of hardware replacement happens quite often in reality, so I thought that I would give them a taste of the real world. Well, I should have given them only a few hours to make the changeover, as most of them were done in less than one day.

So the lesson that the students, and I, learned was that with the new generation of rapid prototyping tools for controllers, development and deployment is easy and quick. You still need to understand controls and modeling; that was clear by the many times the students’ ETVs started flapping in a very unstable mode.

Finally, I did make it clear to the students that this was really a prototype development situation. The actual production system would probably employ a custom programmed processor to fully optimize system performance at the lowest price. I really do not foresee LabVIEW real-time running on every car on the road, but it is tempting!

Author Information

Thomas R. Kurfess, Ph.D., P.E. teaches at Clemson University’s International Center for Automotive Research in Greenville, SC. He welcomes donations of other products for his students to review and apply, and can be reached at kurfess@clemson.edu .