MOTOR Magazine

A MOTOR Magazine Newsletter
February 21, 2017

Contributed by Bob Chabot
Codifying the Car

Modeling and software autocoding spur GM electrification

Electrified drive systems don’t just happen. Nor does their development mirror that of conventional powertrains. Electrification means many additional components. It also means more electronic controls, and that means significantly more software. Take the General Motors Volt for instance.

The cost of remedying a software glitch rises the longer it takes to find it. (Images — General Motors)

Fixing a Software Bug Earlier is Much Less Expensive Than Fixing it Later
While the Volt incorporates elements that are common for any advanced propulsion system — for example, diagnostics, safety systems, and performance attributes — it also significantly raised the level of controls, systems-integration challenges and software,” explained Greg Hubbard, GM’s Chief Engineer for Hybrid and Electric Drive Controls. “The Volt uses more than 100 electronic controllers and 10 million lines of computer software code to shunt power rapidly and seamlessly among the vehicle’s battery pack, power inverter, traction motor, combustion engine/generator, and other subsystems.”

A generally accepted rule of thumb in the software world expects there to be 0.1 to 1.0 residual software defects (bugs) per 1000 lines of code written (net of comments), as first postulated by Dr. Barry Boehm, a leading software engineer, researcher and professor at University of Southern California's Center for Software Engineering. Boehm’s research also found that it costs up to 100 times more to fix a problem once a vehicle goes to market than it would have cost to correct it during the “modeling and definition” phase of manufacturing.

“The more you get the initial model correct, the more you prevent in later fixes to the vehicle,” Hubbard noted. “So the payback for time spent debugging an algorithm in the early development stages is a significant reduction in time and expense debugging software, tuning and calibrating the vehicle downstream. The cost to fix a defect just gets more and more expensive the later that you find it.”

The blocks on the left in the MATLAB modeling image above show various test scenarios for a particular algorithm pertaining to “on” and “off” commands for the Volt’s combustion-engine.

Model-Based Design: Applying 2-Mode Hybrid Insights
GM says its prior experience with its 2-Mode Hybrid Program provided a wealth of knowledge and files to help get its Volt program off to a quick start. But the key enabler was the model-based design and automatic software code generation expertise of its supplier of more than 15 years, The MathWorks. GM engineers use The MathWorks’ tool suite as the common language between teams for communicating requirements, definitions, algorithm designs, testing and calibration.

In the Volt program, a development path based on a traditional prototype design process was not feasible, given the vehicle’s all-new battery technology being developed in parallel with the vehicle. The challenge in the program was to get many controls to work together seamlessly, and to manage a complex system design in less time. That’s where the benefits of their 2-Mode learning and earlier experiences became obvious.

“While the Volt relies on a different vehicle operating philosophy, notably more software-based, our high level of confidence and ultimate success with the Volt program is predicated on this past experience in model-based controls,” Hubbard said. “Based on our model-based 2-Mode work with The MathWorks before the Volt, we had many MATLAB, Simulink, and other tools, files and modules we were able to extend for usage with the Volt. Examples include controlling the motor, the power electronics, and the drive unit.”

“Model-based design allows engineers to capture the system dynamics and control algorithms, including diagnostics, in a modeling environment while the hardware is being developed,” explained Wensi Jin, The MathWorks’ Automotive Industry Manager. “Then they refine the models of the various systems being controlled (e.g. the Volt’s battery pack, combustion engine and traction motor, in the case of Volt— to the point where they’re happy with it, after which it’s time to move on to the hardware.”

“This enabled us to describe how we wanted the propulsion system to behave and gave us the ability to test software algorithms earlier than in previous vehicle development timelines, so when the first hardware arrived, we could demonstrate and test much sooner,” Jin added. “Those demonstrations came far earlier in the Volt program than any other program before it, and resulted in significantly reduced time and cost savings.”

The screen image above includes the C code (bottom right) that is automatically generated from the Mathlab/Simulink modeling tool. This C code is then compiled and linked with other automatically generated code and downloaded to the Volt’s propulsion ECU.

Software Autocoding is More Efficient Than Hand-Coding
Automatic software code generation is just one benefit the Volt program realized from its long-standing relationship with The MathWorks tools used throughout the 2-Mode program. “The MathWorks’ Real-Time Workshop Embedded Coder played an essential role in enabling software code generation from model on downstream,” Hubbard said. “It was vital to meeting Volt’s aggressive program timeline.”

He said the Volt engineers describe the functionality and models using The MathWorks tools, which can then generate code from those models — the same code used directly in the vehicle’s computers. By having a single common code source, the designers, testers and calibrators of software algorithms are all using the same code; no one introduces translation errors during the process, which cuts down on bugs. In addition, the tools allow simultaneous multiple interpretations for functions to be used by various teams — say, one team using the root code in a Microsoft Word spec, while another team, for efficiency reasons, may use the code in a C or C++ spec.

The Volt uses more than 100 electronic controllers and more than 10 million lines of computer software code to shunt power rapidly and seamlessly, significantly raising the level of controls and systems integration challenges for GM engineers. As an historical reference, the average conventional GM automobile in 1990 used just one million lines of code.

“Having multiple interpretations for a function is one of the keys in being able to move more quickly, without errors, through the Volt program,” Hubbard emphasized. “In fact, for many of the Volt’s electronic modules, nearly 100 percent of the software was generated automatically. In addition, approximately 10,000 functions in the Volt were accomplished using models and autocode. We estimate that using automated code generation, rather than hand-writing code line-by-line, netted GM a 30-35 percent efficiency gain.”

“The Volt program is now the vanguard of these trends,” Hubbard concluded. “We’ll continue to build on past lessons learned from the EV-1, 2-Mode system, and now Volt. Our lessons learned using the same models to control different systems are invaluable. We’ve benefited from using single root sources of code that people can understand. It allows us to go faster. And we’re getting generational learning much faster each iteration.”

[Editor's note: Visit for the latest diagnostic and service insights.]

Important Links
MOTOR Current Issue
MOTOR Current Issue
MOTOR Magazine

MOTOR Information Systems • 1301 W. Long Lake Road, Suite 300 • Troy, MI 48098