How to Fast-Track MISRA Compliance of Automatically Generated Code

By Ram Cherukuri

Code generation greatly simplifies the MISRA compliance process. The key objectives of coding standards (such as MISRA) are readability, maintainability, and portability, in addition to ensuring safety and reliability. Because the models are at the core of the development process and code can be generated from the model in a consistent manner for different platforms, it simplifies the portability and maintainability pieces.

Hence, there is a smaller subset of rules in the context of code generation, such as MISRA AC AGC or as part of the new MISRA C:2012 coding rules. In order to generate code that is MISRA compliant, you need to make sure certain modeling patterns are not violated and configure code generation options appropriately.

The below link provides information on generating MISRA compliant code with MathWorks Embedded Coder:

Similarly, for dSPACE TargetLink, you can refer to the following link:

But in most real world applications, you will end up with certain violations that you need to address through the deviation process, as recommended by MISRA. Some of these might be a result of the design decisions.

You can run the analysis on the generated code either manually or as part of your build system. You can then address any violations by adding comments into the code or saving them separately with your results. You can perform the same tasks with Polyspace tools but what if there was a more efficient way? How many engineering hours are potentially wasted in repeating the review of say 100 violations if you have to regenerate the code?

Benefit of integration with tools for Model-Based Design

The key benefit of such an integration would be to make this deviation process efficient. By adding justifications at the model level, you can avoid rework every time you generate code, either after an update or for a different target platform. You can continue to maintain your models as the center of your design and the justifications are automatically propagated to the Polyspace analysis; this is due to integration with automatic coders such as Embedded Coder and TargetLink.

Left shift operation is a MISRA violation but is a design choice for efficient code. Further, it has no side effects and is proven safe. It can be traced back to the gain block that can be annotated.

In the example above, it was a design choice to generate code that uses bitwise shift operations instead of multiplication for greater efficiency. Below, you can see the options that Embedded Coder provides to enable or disable these settings. Embedded Coder further provides Code Generation Advisor to guide the process either for efficiency or compliance to MISRA.

Code generation options to configure the use of shift operations as discussed in the example above.

In addition, Polyspace automatically configures the subset of rules applicable in the context of code generation. For example, in the case of MISRA C:2012 ,certain rules are reclassified if you are generating code, and the Polyspace MISRA checker imports this information when launched from the code generation environment.

Example of the settings that are imported from the code generation environment.

In fact, you can automate the execution of Polyspace as a post-processing step after code generation to assess that a code component is MISRA compliant before it is checked into your source code management system. For example, you can select the single-unit subset of rules that can be analyzed and addressed locally. The traceability back to the model helps you address these violations directly within the model. Last but not least, you can generate detailed MISRA reports to document the level of compliance.

For more information regarding MISRA compliance using Polyspace tools, refer to the links below:

Ask the Expert

Ram Cherukuri
Polyspace Static Analysis Notes Contact Expert

Static Analysis with Polyspace Products