Take advantage of integrated code analysis tools in your functional safety development environment

Currently, more and more automotive, industrial and other applications are emphasizing functional safety, and their development process also requires advanced and complete tool chain support, as well as some important development tool usage experience. As a R&D engineer of functional safety products, you must have heard of static code checking similar to MISRA C, as well as some other code standards and automated checking tools. However, in the daily development process, just knowing these standards does not mean that you can efficiently make the code comply with the code standards.

This article will provide some ideas from the aspects of the code standard itself and the use and process of the supporting inspection tools, using the common IAR development tool chain in the industry as an example to explain why it is recommended to use its own code analysis tools when developing products that require safety certification. In actual applications, for Renesas RX and Arm series cores, C-STAT static code analysis and C-RUN runtime analysis components are often added as plug-ins to the IAR Embedded Workbench development environment.

Functional safety standards and code analysis

In Part 3 of IEC 61508 2.0, software for safety-related systems is regulated and requires the use of a reliable and well-developed process. For example, Section C.4.2 of Part 7, “Overview of Techniques and Measures”, states that a subset of programming languages ​​should be used:

Purpose: Reduce the probability of introducing programming errors and increase the probability of discovering residual errors.

Description: Examine a programming language, for example using static analysis to identify programming constructs that are error-prone or difficult to analyze. Then define a subset of the programming language to exclude such programming constructs.

Section C.4.2 also states that it is not recommended to program in C without setting such restrictions if the software has a Safety Integrity Level (SIL) higher than 1. In other words, if you want to develop a SIL 2-4 certified system using C/C++ software, you will basically need to use static analysis tools.

Similarly, for runtime analysis, Section B.6.5 “Dynamic Analysis and Testing” of Part 7 “Overview of Techniques and Measures” states:

Purpose: To detect specification failures by dynamically checking the behavior of a nearly completed prototype.

Description: Dynamic analysis of safety-related systems is performed by running a basic runnable prototype of the safety-related system with typical input data from the target environment. If the safety-related system is observed to behave as expected, the system passes the analysis. If any failures occur in the safety-related system, they must be corrected and the new runnable version reanalyzed.

Let's take a look at how C-RUN meets such analysis needs:

C-RUN is a tool integrated into the compiler and C-SPY debugger. It allows you to observe executable code at runtime and report unexpected behavior of the code at runtime. C-RUN performs arithmetic checks, bounds checks and heap checks and can be easily configured in the project settings of IAR Embedded Workbench:

Runtime analysis tools in general have a low rate of false positives, and C-RUN is no exception. In other words, errors reported by C-RUN are very likely to be real errors, because real code is executed and analyzed on a real target system. C-RUN sees all the information about the state of the application and reports errors that actually occurred. Nevertheless, during execution, you can set up appropriate C-SPY message rules to let detected errors pass through, as shown in the figure below.

However, runtime analysis has some drawbacks. First, when using this approach, problems are often not discovered until late in the software development process because runtime analysis tools require the use of executable files of the code. In addition, runtime analysis only checks the part of the application that is actually running. If all conditions cannot be triggered so that the entire code of the application is analyzed, you will end up with parts of the code that are untested. Nevertheless, C-RUN can still provide very valuable feedback and is very easy to use due to its deep integration with IAR Embedded Workbench.

Next, let's talk about C-STAT, a static analysis tool that detects deviations from coding rules by performing one or more rule checks. C-STAT checks code for compliance with the rules specified by MISRA C:2012, MISRA C++:2008, and MISRA C:2004, as well as checks for various issues covered by CWE and CERT C/C++. Like C-RUN, C-STAT can be easily configured in the project settings of IAR Embedded Workbench.

Unlike C-RUN , C-STAT checks the code for defects without actually running the application. It finds errors independently of the program's execution path and the datasets used. C-STAT finds errors and defects early in the software development process, virtually from day 1 of development, without affecting system performance.

Although there are several independent static analysis tools available for C/C++ developers, one of the great advantages of C-STAT is that it can be used directly without tedious configuration. Moreover, it can understand and analyze various IARSystems-specific C/C++ language structures designed for efficient embedded programming. By integrating C-STAT into daily development, you can easily check whether the code complies with most important coding rules. This can save more time and resources for later testing and debugging.

C-STAT can be integrated into IAR Embedded Workbench IDE and is as easy to use as a regular build tool:

For each error detected, there will be a corresponding description in the online help system. Press F1 to see the corresponding rule description and the corresponding sample code to illustrate how to satisfy the rule:

A report in HTML format can be generated to record the test results:

Conclusion

Going back to the functional safety standards discussed in the first part of this article, let’s see how the above tools can help your software meet the required standards.

Section C.4.2 of Part 7, “Overview of Techniques and Measures” states that programming language subsets should be used: Programming languages ​​are examined, for example using static analysis, to identify programming constructs that are error-prone or difficult to analyze. Programming language subsets are then defined to exclude such programming constructs.

This is where C-STAT comes in handy, checking whether the code complies with the rules specified by MISRA . As mentioned earlier, if you want to develop SIL 2-4 certified systems using C/C++ software, you do need to use static analysis tools.

Let's look at Section B.6.5 "Dynamic Analysis and Testing": Dynamic analysis of a safety class system is performed by running a basic runnable prototype of the safety class system with typical input data from the target environment. If the safety class system is observed to behave as expected, the system passes the analysis check. If any failures occur in the safety class system, they must be corrected and the new runnable version reanalyzed.

Although C-RUN for runtime analysis cannot comprehensively check all dynamic behaviors in the entire safety-related system, it is still a very useful tool to find real and potential errors, at least in the software part of the safety-related system. It is important to remember that the safety concept must be related to the dangerous failure rate of the system, not just the failure rate of the components (such as software).

C-RUN for runtime analysis and C-STAT for static analysis are two different types of code quality analysis tools. They are both very useful in the development of security software. The two do not form a competitive relationship, but complement each other. Therefore, IAR's C-RUN and C-STAT tools can bring complementary code inspection capabilities to developers and naturally integrate them into the daily development process. The evaluation version of IAR comes with C-RUN and C-STAT plug-ins, and engineers are welcome to try them out.