The Daimler project team, which consisted of systems and software engineers, had already developed a C-code module for this application, but would need to redesign this module for implementation on a new target ECU. The deadline for the project was within 18 months from start. Based on past experience, the team knew that they would not be able to meet the deadline using a traditional development approach.

Their goal was to create a modular application with an open architecture that could be reused for future applications. Since several teams would be working simultaneously on the project, they would need to share results.

The complex CC software would control drive and brake torque, regulate distance, and limit speed. Inputs for the governor and the road speed limiter included the CC lever, accelerator, pedal, CAN signals, and vehicle speed, distance, and acceleration. The design of a system with so many inputs and outputs would be challenging enough. Daimler would also need to ensure that the system executed on a fixed-point production microcontroller with limited memory and throughput resources.

Daimler used Model-Based Design with MATLAB^®, Simulink^®, and Embedded Coder^®. MathWorks consultants helped them develop modeling guidelines and architecture so that the algorithms would produce optimized C code.

Daimler began by modeling the system in Simulink and Stateflow^®. This complex design model consisted of 3900 blocks with 140 input signals, 40 output signals, and 340 parameters. They used version control in Concurrent Versions System (CVS) to enable teams to design subsystems simultaneously.

Engineers conducted tests throughout the development phase using an interactive, automated test tool based on a test database with predefined tests and a control interface. They performed processor-in-the-loop testing by using a closed-loop simulation of a Simulink model communicating over CAN bus with the production code generated by Embedded Coder executing on the target microcontroller. This enabled Daimler to quickly verify the results computed on the target hardware with those calculated in Simulink.

After testing, they automatically generated code for the CC using Fixed-Point Designer™, Simulink Coder™, and Embedded Coder. Fixed-Point Designer helped them define scaling and data types in most of the Simulink blocks. Embedded Coder enabled them to generate code that would satisfy their in-house quality and style standards. Custom storage classes enabled them to define and control the data types for a production release.

After testing the code in the target ECU, they tested the ECU on a hardware-in-the-loop simulator that consisted of a vehicle model working on VME Systems and all vehicle ECUs, including hardware sensors. The vehicle model ran in real time, enabling the team to calculate all physical values as if they were working with the actual vehicle.