Newsletters - MATLAB Digest

Introducing the Model Assistant Tool

Model developers who generate embedded code should investigate the Model Assistant Tool (MAT), which lets you configure, check, and optimize Simulink^® models for production code generation. This article describes how the MathWorks Embedded Targets Team used MAT to quickly generate an optimized, fixed-point, fuel system control software demo for the Embedded Target for Infineon C166^® Microcontrollers. The application described in this article involves an automotive powertrain, but the information could also pertain to other applications, including industrial and medical control devices, where the C166 is widely used.

MAT´s graphical user interface also lets you search for and replace model information -even if those models are not intended for code generation. MAT is available from MATLAB Central, and installs directly on top of Simulink 5 (or higher).

MAT automates some of the points described in the November 2002 MATLAB Digest article, Tips for Fixed Point Modeling and Code Generation. Please read this article as it provides background information for topics discussed below.

This article details how MAT helped the Embedded Targets Team optimize the final implementation of the fuel rate controller, beginning with a brief description of the model and following with the optimization procedures.

Model Description

Figure 1 shows the fuel system model. Notice that, in addition to the controller, the model has sensors with fault-insertion capabilities and an engine gas dynamics model that serves as the actuator and plant. Scopes help plot important signals, including the Metered Fuel command and the air/fuel mixture ratio.

Figure 1: Fault-tolerant fuel control system.
Click on image to see enlarged view.

Figure 2 shows the fuel rate controller. It employs Stateflow^® for the fault-tolerant logic and Simulink for the feedback compensation, as shown in Figures 3 and 4 respectively. The automatic scaling capabilities in the FixPt GUI block helped in deriving the fixed-point data types and scaling information.

Figure 2: Fuel rate controller.
Click on image to see enlarged view.

Interactive simulation originally validated the performance of a floating-point version of the control system. In this mode, the team executed the model and toggled the sensor switches back and forth to emulate a variety of failure scenarios. Scopes helped them examine the system´s response and evaluate the robustness of the fuel rate controller. The floating-point response was eventually designed to fit within the required performance envelope. After attaining the desired behavior, the development phase was concluded. It was now time to begin the implementation phase, where the team sought to maintain the desired behavior using fixed-point data on a C166 target processor.

Figure 3: Fault logic in Stateflow.
Click on image to see enlarged view.

Figure 4: Feedback control in Simulink.
Click on image to see enlarged view.

Initial Implementation

Simulink and Stateflow both support fixed-point math intrinsically. The team added fixed-point data to the fuel rate controller model using this built-in capability. Simulating and generating floating-point code from the fixed-point model was still possible, so several quick iterations were performed to derive fixed-point data for closely approximating the floating-point response. Using a common model for specifying both the floating-point behavior and fixed-point implementation reduces model translation and conversion errors. A common model approach is also useful to other production processes that encounter problems converting behavioral models to software implementation, such as with vehicle manufacturers and ECU suppliers.

The team created the fixed-point fuel rate controller model using the general procedures detailed in Tips for Fixed Point Modeling and Code Generation. As a result, a number of model optimizations occurred during implementation that reduced the RAM and ROM size of the code.

Some of the optimizations included:

Selecting inline parameters on the Advanced tab of the Simulation Parameters dialog and choosing Integer Code Only
Using C166 bit-addressable memory for some signals with data type Boolean (specific to Embedded Target for Infineon C166 Microcontrollers)
Replacing the reference to time, t, inside the Stateflow chart with a counter to create integer-only code
Skipping the index search by adjusting the input values to space the tables evenly

Initial Results

The Embedded Target for Infineon C166 Microcontrollers comes with an HTML code profile report generator, which helped the team determine the initial size of the code. The results for the entire module (shown in Figure 5 below) show that 251 bytes of RAM and 8,995 bytes of ROM were used.

Figure 5: Initial results from code profile report.
Click on image to see enlarged view.

Once MAT became available, the team decided to use the new tool to implement additional tips and optimizations, reducing the byte count.

Introducing MAT

A new tool from The MathWorks, MAT helps improve a modeler´s productivity. It includes a variety of checks (e.g., checking for questionable or costly blocks and operations) that MathWorks engineers with a comprehensive understanding of Simulink and Stateflow created. MAT has three core capabilities, which you can access through the tabs shown on the top bar of Figure 6.

The three core capabilities (with corresponding windows) are:

Configuring models (General Code Generation Goals and Detailed Code Generation Goals)
Checking and analyzing models (Model Advisor)
Searching and replacing objects in models (Search and Modify)

Figure 6: Model Assistant Tool (MAT).
Click on image to see enlarged view.

The team invoked MAT from MATLAB using the following command:

modelassistant('modelname')

After reviewing the online documentation and running through some demos, the team was ready to apply MAT to their fuel rate controller. Because the C166 Embedded Target, C166.tlc, and the various configuration settings were already selected, the team bypassed the General Code Generation Goals and Detailed Code Generation Goals areas and proceeded to the Model Advisor.

Final Implementation Using MAT

The Model Advisor provides checks for model constructs and conditions involving blocks, ports, signals, sample times, initial conditions, and more. The team selected all the options and invoked the Model Advisor, which reported that a number of areas for improving code efficiency existed, especially from the check for "expensive saturation and rounding code." See Figures 7 and 8 for details on this check.

Figure 7: Model Advisor before check.
Click on image to see enlarged view.

Figure 8: Model Advisor after check.
Click on image to see enlarged view.

Many of the blocks were reported in this check because the default block setting Saturate on Integer Overflow was turned On. However, this setting causes additional code to be generated to address saturation conditions. In many cases this added software is not needed, perhaps due to a develope´s detailed analysis or defensive programming techniques.

The team investigated the overflow conditions further and decided to turn Saturate on Integer Overflow Off for all blocks within the fuel rate controller. Manually changing this particular setting for each block would be too time consuming. This is where MAT´s global search-and-modify capability excels. Figure 9 shows the Search and Modify window. The Frequent Tasks option featured a built-in capability that can turn Saturate on Integer Overflow On or Off. The team set this value to Off and invoked the modification.

Figure 9: MAT´s Search and Modify. Click on image to see enlarged view.

Figure 10: Turning Saturate on Integer Overflow Off. Click on image to see enlarged view.

Final Results - ROM Savings of 800 Bytes

After confirming the change by inspecting several of the blocks, the team regenerated the embedded code and produced a new profile report. This time, the values for RAM and ROM were reduced. In fact, the ROM savings was more than 800 bytes!

Figure 11: Final profile. Click on image to see enlarged view.

Conclusion

With embedded software, every byte counts and a savings of 800 bytes is significant. For this reason, and others, such as the graphical search-and-modify capability, the team used MAT to create a fixed-point fuel system demo that now comes as part of the Embedded Target for the Infineon C166^® Microcontrollers.

We´re interested in knowing which frequent tasks you would like automated, or other model checks that might come in handy. Please let us know by contacting Greg Paul (gpaul@mathworks.com) or Pete Szpak (pszpak@mathworks.com).