Integrated code analysis in functional safety tools

Functional safety standards and code analysis

Part 3 of IEC 61508 Edition 2.0 sets the software requirements of a safety-related system mandating the use of good development processes. As an example, it is expressed in part 7 Overview of techniques and measures, section C.4.2, that a language subset shall be used:

Aim: To reduce the probability of introducing programming faults and increase the probability of detecting any remaining faults.

Description: The language is examined to determine programming constructs which are either error-prone or difficult to analyze, for example, using static analysis methods. A language subset is then defined which excludes these constructs.

The same section also states that using C as a programming language without this restriction is not recommended for safety integrity levels (SIL) above 1. In other words, you basically need a static analysis tool if you are aiming for a SIL 2-4 certified system using C/C++ software.

Similarly for runtime analysis, it says in part 7 Overview of techniques and measures, in section B.6.5 Dynamic analysis and testing:

Aim: To detect specification failures by inspecting the dynamic behavior of a prototype at an advanced state of completion.

Description: The dynamic analysis of a safety-related system is carried out by subjecting a near-operational prototype of the safety-related system to input data which is typical of the intended operating environment. The analysis is satisfactory if the observed behavior of the safety-related system conforms to the required behavior. Any failure of the safety-related system must be corrected and the new operational version must then be reanalyzed.

Let’s take a look at how C-RUN can help meet this demand!

The tools

C-RUN is a tool integrated in the compiler as well as in the C-SPY Debugger. It lets you observe executable code at run-time and report violations performed by the code as it runs. C-RUN performs arithmetic checking, bounds checking and heap checking and is easily configured in the project settings in IAR Embedded Workbench:

Runtime analysis tools in general are characterized by a low false-positive rate and C-RUN is no exception. In other words, when C-RUN reports a bug – it is likely to be a real bug as your real code is being executed and analyzed and on a real target system. C-RUN can see all the information about your application’s state and will report bugs that actually occurred. Nevertheless, you are free to let detected errors pass during execution by setting the appropriate C-SPY Message Rule as shown in the image below.

There are some down sides with runtime analysis, though. To start with, problems are in general found late in the software development process with this method as the analysis tool requires a running executable of your code. Further, the analysis itself only covers those the parts of your application that was actually run. If you are not able to trigger all stimuli that your application requires to get full code coverage, you will end up with un-tested code. Still, C-RUN provides you with extremely valuable feedback and thanks its tight integration into IAR Embedded Workbench, it is very easy to use.

Moving on to C-STAT, this a static analysis tool that tries to find deviations from certain coding rules by performing one or more checks for the rule. It checks for compliance with rules as defined by MISRA C:2012, MISRA C++:2008 and MISRA C:2004 together with approximately 250 checks mapping to issues covered by CWE and CERT C/C++. Just like C-RUN, C-STAT is easily configured among project settings in IAR Embedded Workbench.

In opposite to C-RUN, C-STAT is a tool that checks your code for defects without actually running it. It is able to find errors independent of the executing path through the program, as well as of the data set being used. C-STAT can identify bugs and defects early in the software development process, from day 1 actually, and it does not impact the performance of your system.

There are several free-standing static analysis tools available on the market for C/C++ developers but an advantage with C-STAT is that it works out of the box without any heavy configuration and, of course, it understands all IAR Systems-specific C/C++ language constructs tailored for efficient embedded programming. By using C-STAT as a natural part of your daily work, you can easily check your code against a major part of important rules. This will save time and resources for test and debug at later stages.

C-STAT is integrated into the IAR Embedded Workbench IDE and is as simple to use as the regular build tools:

Each detected error has a description in the online help system and by tapping F1, you get a rule explanation together with a code example showing how to do it right:

You can create reports in HTML format to document your test results:

Conclusion

Going back to the functional safety standards in the first section of this article, let’s check how the tools can help you meet the defined criteria.

Part 7 Overview of techniques and measures, section C.4.2, states that a language subset shall be used: The language is examined to determine programming constructs which are either error-prone or difficult to analyze, for example, using static analysis methods. A language subset is then defined which excludes these constructs.

Here, C-STAT checking compliance with rules as defined by MISRA is a very good match. And as previously mentioned, you do need a static analysis tool if you are aiming for a SIL 2-4 certified system using C/C++ software.

Moving on to section B.6.5 Dynamic analysis and testing: The dynamic analysis of a safety-related system is carried out by subjecting a near-operational prototype of the safety-related system to input data which is typical of the intended operating environment. The analysis is satisfactory if the observed behavior of the safety-related system conforms to the required behavior. Any failure of the safety-related system must be corrected and the new operational version must then be reanalyzed.

Even if C-RUN for runtime analysis by no means is able to check all aspects of the dynamic behavior in a safety-related system as a whole, it is a very good tool for finding real as well as potential errors at least in the software parts of it. It is important to remember that the safety concept must be related to the dangerous failure rate of a system, not just the failure rate of a component part, such as the software.

The two classes of code quality tools, C-RUN for runtime analysis and C-STAT for static analysis, are highly usable in the development of safety related software and are not competitors at all. Static analysis is strong in areas where runtime analysis is challenging and vice-versa. Hence, C-RUN and C-STAT indeed bring in complementary technologies and are designed to be a natural part of your day-to-day development workflow.