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 non- graphically represented code to create a Simulink interface to these Common Utility Services.