The world of automotive companies and suppliers is spinning faster and faster and the need for automotive software and its development process is being radically modernized and accelerated. However, the faster development cycles must not lead to the neglect of quality assurance processes, especially for safety-critical software applications. For most automotive companies and suppliers, the MISRA C standard is an important part of quality assurance, and checking the program source code for deviations from the standard is used to identify potential errors and to improve software quality. But what is the objective of the MISRA C standard and how can the standard be used in model-based development with TargetLink?

The MISRA C standard in a nutshell

Since 1998, the “Motor Industry Software Reliability Association” (MISRA) has provided a generally accessible standard for developing software in C (MISRA C) to ensure safety, security, and code quality. The authors of the standard gathered knowledge from literature, company standards and practice to avoid common software errors. The guidelines are mainly focused on preventing human programmers from making avoidable errors when programming C code. But what if the code is generated by a code generator like TargetLink? Do you need to adhere to all rules even then? 

MISRA C-compliant model-based development

The MISRA C standard checks the C code for safety, security, and quality. For model-based development, this means that rule violations are found in the code but need to be fixed in the model. So, for each violation, you must identify the right change in the model. For this, we provide you with the TargetLink MISRA C compliance documentation that highlights the changes in the model that need to be made to fix a violated rule, to systematically work your way from the list of findings in the code to the model until you are satisfied. 
Code generators like TargetLink have a deeper understanding of C language constructs that may not be compliant with the MISRA C standard but are more efficient and still safe when applying the contextual knowledge. This means that not all MISRA C rules have to make sense for code generators like TargetLink. The MISRA C standard accounts for this and allows you to create deviations from rules. Moreover, the process to document and decide on deviations is an important element of MISRA C which is clarified in the MISRA Compliance:2020 publication. 
One example for a rule deviation that is still safe is the compute-through-overflows (CTO) optimization that TargetLink applies by default. The optimization introduces casts from signed to unsigned integer types and vice versa. This significantly improves code efficiency, i.e., code size and execution time. The CTO optimization violates rule 10.8 of the MISRA C standard that is based on the risk that the cast from a signed to an unsigned type introduces an unrecognized overflow. However, TargetLink actively recognizes and exploits this overflow behavior in a well-defined manner and the resulting bit patterns are identical regardless of whether CTO is used.​​​​​​​

Prevention is better than cure

Even if the afore mentioned fixing-on-demand approach works, we would recommend a more elegant approach. In most situations in life, it is easier to stop a problem from happening than to correct it after it has started. If we transfer this to MISRA C-compliant model-based development, it is easier and faster to check rule violations during the modeling phase instead of fixing them on demand. For this, you can use the MES Model Examiner® (MXAM) that ensures the comprehensive static analysis of your models. We are glad that in close cooperation with Model Engineering Solutions (MES), the TargetLink modeling guidelines that are specifically designed to avoid MISRA violations during the modeling phase are already included in MXAM. This eliminates the need for the time-consuming task of fixing findings on-demand and helps you to get your models right the first time. 
One example for using MXAM and getting your models right the first time is a model in which you route a signal to a logical block, i.e., an if block. In some situations, TargetLink might generate if(NonBooleanVar). This violates rule 14.4 of the MISRA C standard. However, you can avoid this by enabling the ForceBooleanOperandsInBooleanOperations Code Generation option which inserts additional unequal-to-zero comparisons for non-Boolean operands, i.e., if(NonBooleanVar!=0). During the static analysis by MXAM, you will get information about this before generating the code.  

Drive in the slipstream of dSPACE and MES

Together with MES, we at dSPACE always try to be your windbreaker so that you can drive quickly and safely on your software development road - always ready to win the final sprint. For this reason, we closely cooperate with our partners from MES to provide you with the best solutions for your needs. Feel free to contact us to discuss your needs and wishes.