Practical Assistance for Validating Your Automotive ApplicationShawn Prestridge, US FAE Team Lead

Agenda•ISO 26262 – functional safety•Coding standards and code quality•Code Analysis tools•Safety Guide

ISO 26262Road vehicles - Functional safety

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

Safety Standard

• 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 ISO 26262 do?

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

Functional Safety is available for

IAR Embedded Workbench for Arm V8.22.3IAR Embedded Workbench for RX V3.10.5IAR Embedded Workbench for RL78 V3.10.2IAR Embedded Workbench for RH850 V1.40.3

www.iar.com/safety

IAR Embedded Workbench certified edition

Solutions for safety-critical applicationsCertified toolchain• A special functional safety edition of IAR Embedded Workbench

Simplified validation • Functional Safety certificate from TÜV SÜD• Safety report from TÜV SÜD• 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

Validated according to: IEC 61508ISO 26262EN 50128, EN 50657IEC 62304

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 rulesDirective 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 rulesRule 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 rulesRule 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 rulesIn 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 rulesHowever:

• 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 rulesRule 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 rulesIt 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?

CWE (the Common Weakness Enumeration): http://cwe.mitre.org/CERT (Computer Emergency Response Team): http://www.cert.org/

Static code analysisC-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++

Runtime code analysisBounds checking Arithmetic checkingHeap 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

Run

time

anal

ysis

Static analysis

Total fault coverage

× × ×

×××

××

×

××

××

×××× ×

Demonstration

Available practical assistance

Simplified validation

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!

Safety standards require documented safety guidelines (a safety manual)(see Annex D in IEC61508-3)

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 considerationsLanguage and standard complianceIf 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 standardsSafety 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)

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

Advice: If you decide on any of the MISRA C standards, it is recommended to use at least one MISRA C checker.

Setting up the build environmentSafety 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 considerationsSafety 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 hintNo 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 version: XX x.xx.x Validated version y.yy

Validated service packs Validated service packs

Non-validated feature releases x.xx.x

• 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

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

Summary

Thank you for your attention!www.iar.com

fae.us@iar.com

References[1] https://en.wikipedia.org/wiki/COCOMO

[2] https://www.researchgate.net/publication/220580567_Code_Reuse_in_Open_Source_Software_Development_Quantitative_Evidence_Drivers_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/