Practical Assistance for Validating Your Automotive ... · Caring about code quality • High...
Transcript of Practical Assistance for Validating Your Automotive ... · Caring about code quality • High...
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
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/