Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
4. Westmark Electronics Allegro Microsystems (Hall Sensors, Current Sensors)
Cypress Semiconductor (USB, PSoC, SRAM, NVSRAM)
GainSpan (WiFi Communication & Sensors)
IBM (ASIC/Custom IC Design, Microprocessors)
Littelfuse (Circuit Protection)
Murata (Capacitors, Zigbee, Bluetooth Modules)
Optrex LCD Displays (Industrial/Automotive LCDs)
Panasonic Electric Works (Sensors, Relays, Connectors)
SEI Stackpole (Resistors)
VTI Technologies (MEMS Sensors, Gyro/Accelerometer)
5. Why MISRA? Vehicle recalls related to electronic systems have tripled, and investigations quadrupled in the past 30 years following a surge in the use of computers to control functions such as acceleration, braking, emissions, steering, etc.
A modern luxury car may have functions run by as many as 100 million lines of software code, enough to fill a stack of letter-sized pages the height of a 50-story building.
6. Why MISRA? “Even the most carefully written software probably has about 1 defect per 10,000 lines of code.”
“You could have literally trillions of paths that might have errors in them; it's just hard to test every possible behavior.”
7. Why Now? “With all eyes now peeled on Toyota for three major vehicle recalls and the potential of Honda and other recalls holding the world’s attention, much more is at stake than financial consequences or the momentary loss of consumer confidence.”
One suggested “Cure” is an increase in the data recorded by onboard “black box” data recorders.
“Prevention” is better than the “Cure”. MISRA guidelines are a tool for “Prevention”.
8. Why Now? With increased visibility in Congress and the NHTSA, MISRA may become a requirement in the near future.
Documenting a MISRA audit of your software may help to limit your liability in the case of future problems.
9. Motor Industry Software Reliability Association (MISRA) Established in 1990
Mission Statement : “To provide assistance to the automotive industry in the creation and application of safe and reliable software in vehicle systems”
Originally part of the United Kingdom Government “SafeIT” program
Currently a self-supporting organization
10. Promote best practices in automotive safety-related systems engineering
Develop guidance in specific areas : C/C++ Language Automatically Generated Code Safety Analysis Guidelines
MISRA is NOT a certification agency.
11. MISRA Users Originally intended for the Automotive Industry, but also heavily adopted in : Avionics (MISRA C++ came out of Joint Strike Fighter - JSF++) Railway Signaling IT Systems Design Medical Electronics
Most users are NOT in Automotive! Particularly C++ users
12. MISRA C/C++ Links to SAE Links with the SAE Embedded Software Task Force (J2632)
Links with JAMA/JSAE Japanese Society of Automotive Engineers
Links With HIS Herstellerinitiative Software (Daimler, Audi, BMW, Porsche, VW)
Links with AUTOSAR (uses MISRA)
13. MISRA Publications November 1994: Development guidelines for vehicle based software (The MISRA Guidelines)
April 1998: Guidelines for the use of the C language in vehicle based software (MISRA C)
May 2004: Controllability Technical Report
October 2004: MISRA-C:2004 –Guidelines for the use of the C language in critical systems (MISRA C2)
March 2006: Software Readiness for Production (SRfP)
June 2008: Guidelines for the Use of the C++ Language in Critical Systems
14. Why is MISRA C/C++ Needed? Safety Critical use requires predictability
All software languages have features that are unpredictable, such as : A) unspecified behaviors B) implementation dependant operations C) unknown execution times D) unknown resource requirements
Coding standards like MISRA C/C++ can help to understand, document, mitigate or eliminate such unpredictable results
15. The Origins of Faults Inadequate Requirements
Inadequate Review and Auditing
16. The Detection of Faults Some faults are directly detectable For example, an array index that exceeds the size of the declared array : int some_array; some_array = 0;
This would usually be detected by the “Linter” or the “Compiler” tools.
17. The Detection of Faults Other faults can be mitigated by the audit or removal of certain classes of statements that have been shown to generate unintended, unspecified, or implementation dependent operations : if ( a = b ) then c = 0; // typographic error if ( a == b ) then c = 0; // intended operation The code in red was a typographic error, and was not the intended operation; it also has side-effects! It is however, a valid “C” language construct.
Rule 13.1: Assignment operators shall not be used in expressions that return Boolean values
18. Where does MISRA C/C++ Help? Helps to reduce the 15% of defects in D&I errors
Does not really address the other errors
Must be part of an overall structured development process (it can start the process…)
19. What is MISRA C/C++? The MISRA C/C++ guidelines are a set of rules, primarily intended to address : Inadequate Design Inadequate Implementation Inadequate Review and Auditing
20. Inadequate Design Basic Housekeeping : Uninitialized Variables Uninitialized/Bad Pointers
Poor Program Structure Interface Rules Enforce structured programming concepts
21. Inadequate Implementation C/C++ Language A Weakly Typed Language Some constructs not well defined Implementation Dependent constructs
Programmer/Implementer Must have knowledge of implementation dependencies Reuse of older code, code libraries
C/C++ Compilers Errors in the Compiler itself Quality and Predictability
22. C/C++ and MISRA C/C++ Subsets
23. C/C++ Coding Guidelines Some programmers will initially object to the coding limitations imposed by MISRA compliance.
Some rules may create bigger or slower programs if not implemented correctly.
100% compliance is rare, you need to document your exceptions to the rules.
24. The MISRA Audit Process
25. Highlights of the Rules The following in intended to give you a flavor of “The Rules”, not an exhaustive list.
The Rules are categorized to parallel the ISO conventions for C/C++
Many are common sense, others a bit more obscure…
26. MISRA Rule Categories Environment
Arithmetic Type Conversion
Pointer Type Conversion Expressions
Control Statement Expressions
Pointers and Arrays
Structures and Unions
27. MISRA Rules Highlights 1.1 All C/C++ Code must conform to ISO/IEC 9899/14882 standards
1.4 Identifiers significant within 31 characters
2.2 Only /* */ style comments shall be used
2.4 No code sections shall be commented out
5.6 Identifiers in different namespaces must be unique and not have the same spelling
5.7 Identifier names shall not be reused
28. MISRA Rules Highlights 6.3 typedefs that indicate size and signedness should be used in place of the basic types: char, int, short, long, and float Specific length types should be used for the target platform and compiler. typedef signed long s32; typedef signed short s16; typedef signed char s8; typedef unsigned char u8;
29. Types and Platform Differences Differences in the same code on different target platforms requires that types be explicit in size - i.e. s32, u8, etc.
30. Arithmetic (Type) Conversions 10.1 The value of an expression of integer type shall not be implicitly converted to a different underlying type… (when NOT to use a cast ?) e.g. signed integer to unsigned integer larger integer to smaller integer larger float to smaller float
31. Permitted Type Conversions
32. Pointers Types 11.1 Conversions shall not be performed between a pointer to a function and any type other that an integral type.
Bad pointer arithmetic or conversions can cause a program to jump “into the weeds”, and yield serious malfunctions…
33. Control Flow 14.4 goto statement shall not be used
14.5 continue statement shall not be used
14.7 a function shall have a single point of exit at the end of the function
14.8 while, switch, do, and for statement bodies shall be compound statements (i.e. use braces)
34. Functions 16.1 Functions should not have a variable number of arguments
16.2 Functions should not directly or indirectly call themselves (no recursion…)
16.10 Functions that return error codes, must have those codes tested
35. Standard Libraries 20.8 Signal handling of signal.h shall not be used
20.9 stdio.h shall not be used
20.10 atof, atoi, atol of stdlib.h shall not be used
20.12 the time handling function of time.h shall not be used
36. Runtime Failures 21.1 Minimization of runtime failures shall be insured the use of : a) Static Analysis Tools b) Dynamic Analysis Tools c) explicit runtime fault handling
37. MISRA C++ Targeted to ISO/IEC 14882:2003 C++
Rules grouped around the section numbers of ISO/IEC 14882:2003
Rules Layout is similar to MISRA-C
38. Commercial Tools (Static Analysis)
39. Commercial Tools (C Compilers)
40. Commercial Tools The above lists of tools claim to support MISRA-C version 1 and/or version 2. There is no implied or express recommendation of any of these tools. Neither have I, or anyone else as far as I know, have completely and independently certified these tools for all MISRA-C compliance.
41. Other Standards to Note MISRA is not the only group working on safer software and development methods, there are many others, such as the : SAE, JSAE, ISO/IEC, ANSI, JAMA, Herstellerinitiative Software and others.
42. International Electrotechnical Commission IEC – International Standards for safe and reliable operation
New and Evolving Standards for embedded software and microprocessors (eg: IEC 60730 – self test class library)
Only loosely coordinated with MISRA
Best practices combine these together – this is still an evolving discipline…
43. Action Plan Audit your development process, what steps are you already taking?
Audit your development tools, what checking and static analysis do they already support – that you may not be using?
Audit your testing procedures.
Identify the weak points in your process.
Propose a plan to improve your process.
Rinse, lather, repeat…
44. A few words on Specifications The earliest part of the process to be improved; it yields the most benefit.
Consider a method of “Executable Specifications” The human mis-interpretation of specifications is still a large problem in the industry overall. (This is a subject for another evening…)
45. Summary MISRA is only one tool for “Prevention”, it is not a complete cure. Only good engineering and testing can provide that.
MISRA will help to eliminate some common errors in the coding phase, where they are faster and less expensive to fix than in the testing phase.
46. Summary With increased visibility in Congress and the NHTSA, MISRA may become a requirement in the near future.
Documenting a MISRA audit of your software may help to limit your liability in the case of future problems.
47. Thank You! Questions?