Static Code Analysis and MISRA C in Automotive Embedded Systems

C for Car, is the dominating fact of the Motor Industries and especially automotive sector. Besides its popularity, it is also the fittest language for creating Safety Critical Systems in the automobile sector, followed by C++ (its descendant) and compliance with the ISO 26262 Certification Standard is required. According to a VDC Research Survey, C was used in the industry to a degree of just over 70%.

ECU (Electronic Control Unit), is an essential part of modern day cars where you use micro-controllers to program your ECU to be brain of the required functions such as launch, gear-shift, and even to open the window. Some modern cars have up to 150 ECUs. ECU embedded software keeps become more sophisticated, complex, and line-intensive. For original equipment manufacturers (OEMs), controlling the complexity and quantity of electronic control units (ECUs) in a vehicle has emerged as a major concern.

Static Code Analysis

Static Analysis (a.k.a. Source Code Analysis) is the process of simulating a program’s performance at runtime. The phrase is typically used to describe analysis carried out by an automated instrument. It is working as analysing the code without executing.

Errors that might not surface for several weeks or months after development are discovered through static analysis. Without static analysis, these mistakes show up in production and are very expensive to rectify. After performing static analysis, start looking for less evident flaws in dynamic code. A program is tested during a dynamic analysis. You should include static and dynamic analysis in your testing routine. You run the risk of upsetting both yourself and your client if you skip any step. The majority of the time, an analysis is carried out on a program’s source code or, less frequently, on some aspect of its object code.

Advantages of Static Code Analysis

  • Security: Analysis provides forseeing the bugs that can occur and lead to a bigger problems while don’t really effect the main functionality of the code. So, even if your code works perfectly, there are huge bugs you cannot see without doing the analysis.
  • Standardization: Almost all analyzer tools use the same standarts that are published by trusted foundations. Making every code according to them is standards the industry and helps developers to understand each other.
  • Validity: Because standards are set by such trusted organizations and used by titans of industry, the analysis is valid.

The Motor Industry Software Reliability Association (MISRA) offers recommendations for creating independent software, embedded control systems, software-intensive applications, and systems for safety and security. The need for a “restricted subset of a standardized programming language” was first expressed in the 1994 “Development guidelines for vehicle-based software” and led to the creation of MISRA C in response to this need and the burgeoning use of C for creating embedded software in automotive applications. It aims to guide mostly in according to ISO C, C90, C99, and C11 standarts.

The analysing process is relatively simple. Most of the cases, it is done before the software testing starts in beginning of the development. When the code is ready, analyzer should start the process and review the code. There are several standarts and analysis levels for the analyzer to choose customly. In some testing tools, user can choose the degree of violation. But in almost all of them user can choose the standart and its timelines. Static Code Analyzer should choose for their need and launch the analysis according to.

Statical Code Analysis tools are seperated according to their qualities. Some of them created an enviroment and an interface for easier use and more detailed reports. Others are used by simply compiling directly in the terminal. For example:

The C programming language is straightforward, clear, and effective. It gives a programmer the tools they need to create accessible, maintainable, and effective code. Its popularity can be attributed to all of these qualities. Unfortunately, the language also gives the unwary developer the ability to write risky, insecure code that can lead to significant issues throughout the entire development project, including deployment. These language flaws are a big worry for applications where safety and/or security are top priorities. For example, these software flaws are not fit such industries as; “Aviation, Automotive, Railways, and the Defence Industry”. Where a milisecond delay or missing data can cause lives.

Let me give you a taste of the guidelines here.

MISRA C:2012 Rule 12.2

Rule Definition:

The right hand operand of a shift operator shall lie in the range zero to one less than the width in bits of the essential type of the left hand operand.


Consider this statement:

If abc is a 16-bit integer, then num must be in the range 0–15, (nonnegative and less than 16). If num is negative or greater than 16, then the shift behavior is undefined.

MISRA C:2012 Rule 7.2

Rule Definition:

A “u” or “U” suffix shall be applied to all integer constants that are represented in an unsigned type.


The signedness of a constant is determined from:

  • Value of the constant.
  • Base of the constant: octal, decimal or hexadecimal.
  • Size of the various types.
  • Any suffixes used.

Unless you use a suffix u or U, another developer looking at your code cannot determine easily whether a constant is signed or unsigned.

MISRA C++:2008 Rule 7.5.1

Rule Definition:

A function shall not return a reference or a pointer to an automatic variable (including parameters), defined within the function.


Automatic variables are destroyed at the end of the function call. Returning a reference or pointer to such a variable allows it to be used after its destruction, leading to undefined behaviour.

It is not all of these rules are common sense of the all programmers but they are set of guidelines 🙂 for safer and more secure code after all.

Author: Muhammet Kamil Kalaycı