Jeffrey M. Thate

Caterpillar Automatic Code Generation

Automatic code generation from models is actively used at Caterpillar for powertrain and machine control development. This technology was needed to satisfy the industry’s demands for both increased software feature content, and its added complexity, and a short turn-around time. A pilot development effort was employed initially to roll out this new technology and shape the deployment strategy. As a result of a series of successful projects involving rapid prototyping and production code generation, Caterpillar will deploy MathWorks modeling and code generation products as their department-wide production development capability. The data collected indicated a reduction of person hours by a factor of 2 to 4 depending on the project and a reduction of calendar time by a factor of greater than 2. This paper discusses the challenges, results, and lessons learned, during this pilot effort from the perspectives of both Caterpillar and The MathWorks.

Methods for Interfacing Common Utility Services in Simulink Models Used for Production Code Generation

Traditionally, code generated from Simulink models has been incorporated into production applications in a manner similar to hand-written code. As the size of the content created in Simulink has grown, so has the desire to do more integration in Simulink. Integrating content from C/C++ calling environments directly into Simulink blocks rather than just calling external legacy code prevents errors and preserves signal flow visibility in the Simulink models. Although much of the application content has transitioned to Simulink models, most of the Common Utility Services (e.g., communications, diagnostics, and nonvolatile memory) still exist in C/C++ libraries. While application content changes frequently, Common Utility Service content changes infrequently and is heavily leveraged across many applications. Therefore, it is often desirable to call these Common Utility Services from their existing C/C++ libraries rather than porting them to be generated directly from Simulink models. Many common services do not fit easily into a constant parameter and dynamic signal flow approach that is typical of Simulink models. This paper examines methods used for creating custom blocks and nongraphically represented code to create a Simulink interface to these Common Utility Services.