Practical Assistance for Validating Your Automotive Application Shawn Prestridge, US FAE Team Lead Agenda

•ISO 26262 – functional safety •Coding standards and code quality •Code Analysis tools •Safety Guide ISO 26262 Road vehicles - Functional safety Safety Standard

There are many safety standards • Each one caters to a specific industry or product category. • IEC 61508 • Basic functional safety standard applicable to all kinds of industry. • ISO 26262 • Specific for road vehicles What does ISO 26262 do?

• Assign safety goals • Best practice to reduce systematic failures • Diagnostic measures to detect random failure • Ongoing procedures after product deployment • Provides an automotive-specific risk-based approach for determining risk classes (ASIL)

• They outline how to identify and deal with risks • They require FS-certified tools What does functional safety certification for my tools mean?

The development tool has gone through a rigorous qualification process • Development processes for different functional safety standards • Validation of compliance with different language standards • Handling issues reported from the field and updated to the users What do I have to do to certify my toolchain?

Section and Clause 7.4.4.10 of IEC 61508 standard states: “The selected programming language shall have a translator which has been assessed for fitness for purpose including, where appropriate, assessment against the international or national standards.” • Difficult to certify a tool • Prove fitness • Document the process • Gets worse for higher SIL IAR Embedded Workbench certified edition

Functional Safety is available for

IAR Embedded Workbench for Arm V8.22.3 IAR Embedded Workbench for RX V3.10.5 IAR Embedded Workbench for RL78 V3.10.2 IAR Embedded Workbench for RH850 V1.40.3 www.iar.com/safety Solutions for safety-critical applications

Certified toolchain • A special functional safety edition of IAR Embedded Workbench Validated according to: IEC 61508 Simplified validation ISO 26262 • Functional Safety certificate from TÜV SÜD EN 50128, EN 50657 • Safety report from TÜV SÜD IEC 62304 • Safety guide

Guaranteed support through the product life cycle • Prioritized support • Validated service packs • Regular reports of known problems

Available for Arm, Renesas RX, Renesas RL78, Renesas RH850 What do I get with my FS version?

• Build chain that is certified by TÜV SÜD and complies with IEC 61508, ISO 26262 and EN 50128 (EWARM) • Report that accompanies the certificate • Test report • Compiler that supports C89, C99, and C++ languages • Frozen version support – Prequalified service packs. – Support for the life of the FS version. • Regular updates on known issues Coding standards Which one? • MISRA • CWE • CERT C/C++ • Static analysis tools MISRA

• Motor Industry Software Reliability Association • Promotes safe and reliable embedded programming practices • Many other industries also use this standard MISRA benefits • Helps you find potential bugs before you begin testing • Enforces coding rules that promote safety and reliability • Rules are not compiler-specific Sample of MISRA-C:2012 rules Directive 4.6: A primitive data type (int, char, etc.) cannot be used without a typedef • Different compilers and architectures treat things like int differently (16-bit vs. 32-bit) • Makes code invariant across compilers and architectures Sample of MISRA-C:2012 rules • Typically, developers will use a data type such as uint16_t –Explicitly conveys intended width of the data to both compiler and reviewer –Ditto for the signedness of the variable • These types are in stdint.h Sample of MISRA-C:2012 rules Rule 8: All declarations at file scope should be static where possible • Prevents you from unintentionally exposing internal help functions • Forces you to think about design of module interface Sample of MISRA-C:2012 rules Rule 13: The right hand side of a "&&" or "||" operator shall not contain side effects. There is nothing in the C language that prevents you from writing code that looks like the following: if ((x == y) || (*p++ == z)) { /* do something */ } Sample of MISRA-C:2012 rules In this example: • The right hand side of the || operator is only evaluated (and its side-effects executed) if the expression on the left-hand side is false—that is, if x and y are not equal • The side-effect is to post-increment the pointer p. Sample of MISRA-C:2012 rules However: • Even if this behavior is specified by the standard, it is still easy to get it wrong when writing the code. • Even if you manage to get it right, everyone that will ever read or maintain the code must also understand the rules and your intentions. Sample of MISRA-C:2012 rules Rule 14: The statement forming the body of an if, else if, else, while, do ... while, or for statement shall always be enclosed in braces. Sample of MISRA-C:2012 rules It stops you from writing code like this: if (x == 0) { y = 10; z = 0; } else y = 20; z = 1; CWE rules • The Common Weakness Enumeration from mitre.org identifies common pitfalls –Allocation in a constructor without corresponding deallocation in a destructor –Functions used without prototyping –Etc. • Identifies risky coding behavior CERT C/C++ • Similar to CWE, it looks at common vulnerabilities from case studies –Checking floating point values for out-of-bounds –Not casting away a const qualification –Etc. • Also promulgates styling for readability Quantifying improvement • Using coding standards to lower defect injection rate is a maxim • One study by Dr. Dobbs pegs it at a 41% improvement Lowering injection rate [5] • In this study, injection rate was fairly constant until the introduction of coding standard • As comfort with the standard increased, so did quality Caring about code quality • High quality code has fewer defects, so faster time-to-market • It also is easier to maintain or extend, so faster follow-on projects • Much easier to get safety certifications • Lower “technical debt” Fast ways to better code • Perhaps the fastest way to improve code quality is to employ code analysis tools –Quickly finds common sources of bugs in your code –Helps you to find problems that don’t normally occur to developers –Helps you to adopt coding standards • Code analysis tools are required if you are seeking functional safety certification Can code analysis tools help to comply with all the standards? Static code analysis C-STAT: Fully integrated in IAR Embedded Workbench • Intuitive and easy-to-use settings with flexible rule selection • Extensive and detailed documentation • Checks compliance with MISRA C:2004, MISRA C++:2008 and MISRA C:2012 • Includes ~250 checks mapping to hundreds of issues covered by CWE and CERT C/C++ CWE (the Common Weakness Enumeration): http://cwe.mitre.org/ CERT (Computer Emergency Response Team): http://www.cert.org/ Runtime code analysis

Bounds checking Arithmetic checking Heap and memory leaks checking

Intuitive and easy-to-use settings with flexible rule selection

Code correlation and graphical feedback in editor

Comprehensive and detailed feedback

Very efficient instrumentation of compiled code Code analysis tools

Total fault coverage × × × × × × × × × × × × × × × × × ×

Runtime analysis Static analysis Demonstration Available practical assistance Simplified validation Safety standards require documented safety guidelines (a safety manual) (see Annex D in IEC61508-3) The guide provides you with: • More than 80 practical tips

The guide encourages you to: • Consider the relevance for your specific needs • Discuss the implications related to your application

Your guide to using a build toolchain in high-integrity functional safety projects! Topics in the guide • System and environment considerations • Installation, comissioning, operation, and maintenance • Setting up the build environment • Implementation and coding considerations • The C/C++ standard libraries For each topic, you get: • Advice that is relevant for the build toolchain • Each one is numbered for reference Examples... System and environment considerations

Language and standard compliance If using C/C++, safety standards advise you to use plain C/C++ with a suitable language subset (see 7.4.4 in IEC 61508-3 on language selection)

Advice: Make an informed decision on what language, language dialect, and subset you will use. System and environment considerations: Coding standards Safety standards generally require you to adopt a coding standard to deal with hazardous constructs in the programming language you select (see C.2.6 in IEC61508-7 on Design and coding standards) Advice: If you decide on any of the MISRA C standards, it is recommended to use at least one MISRA C checker.

In addition, to use more than one checker, the C-STAT static analysis add-on tool supports MISRA C:2012, 2008, and 2004. Setting up the build environment

Safety standards generally require early action to detect faults in your system (see Table A.5 in IEC61508-3 on Software model testing and integration)

Advice: Create various build configurations that differ in, e.g., compiler optimization settings, linker configuration, and debugger setup. Setting up the build environment: Stack depth considerations Safety standards generally require you to take measures regarding dynamic variables and dynamic objects (see Table A.9 in IEC61508-3 on Software verification)

Advice: Consider using Stack Usage Analysis if it is available in the product you are using. ...after a rebuild Many practical tips • System and environment considerations – How to manage language standards compliance, language extensions and subsets, potential tool failures, device specific support files, compatibility between different versions of the same toolchain, compatibility with other toolchains, MCU self-check strategies • Installation, commissioning, operation, and maintenance • Setting up the build environment – Debug mode, release mode, and build configurations; build options; stack depth considerations; linker configuration; add-on analysis tools • Implementation and coding considerations – Optimization modes; integral type selection; floating-point arithmetic; functions; global symbols; const and volatile; pointers • The C/C++ standard libraries – The standard libraries A final hint No absolute requirements: • Practices, decisions, or deviations can be justified as long as there is valid and sufficient rationale for it • Interpretation of the standards differ depending on the selected integrity level for the project

You have freedom, as long as you make qualified decisions! Validated and frozen versions

Validated service packs Validated service packs

Non-validated feature releases x.xx.x

Validated version: XX x.xx.x Validated version y.yy • For a certified product, a new certified version is released approximately every 12-18 months • A certified version is considered a ”frozen” version, on which bug fixes are applied in terms of validated service packs • No new product features are added to a certified version or the corresponding service packs Understanding the Functional Safety reports • Reporting principles – Only issues in the build chain are documented. – The tag [Key] denotes the public ID of the problem as reported in release notes of future versions of the tool chain or release notes – The list of issues is automatically generated from the issue tracking system. The tag [Components] indicates which part of the toolchain that is affected by the issue. – Released usually every 6 months Examples of reported issues Summary

. Many coding standards exist to help make your code safer and more reliable . Coding standards and certified build tools ensures a faster path to certification . The Safety Guide with the Functional Safety version of Embedded Workbench has practical tips for helping you certify your application Thank you for your attention! www.iar.com [email protected] References

[1] https://en.wikipedia.org/wiki/COCOMO [2] https://www.researchgate.net/publication/220580567_Code_Reuse_in_Open_Source_Software_Development_Quantitative_Evidence_Dr ivers_and_Impediments [3] http://csse.usc.edu/csse/research/cocomoii/cocomo2000.0/cii_modelman2000.0.pdf [4] http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf [5] http://www.drdobbs.com/tools/code-quality-improvement/189401916?pgno=4

Additional: http://insight.jbs.cam.ac.uk/2013/financial-content-cambridge-university-study-states-software-bugs-cost-economy-312-billion-per-year/