Zigbee Introduction

Zigbee Introduction PowerPoint PPT Presentation


  • 244 Views
  • Uploaded on
  • Presentation posted in: General

Download Presentation

Zigbee Introduction

An Image/Link below is provided (as is) to download presentation

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.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


3. Introductions Tom Moxon – Director of Engineering Westmark Electronics [email protected] Bill Murray – Senior Associate Westmark Electronics [email protected]

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 Design Inadequate Implementation Inadequate Review and Auditing Inadequate Testing

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[16]; some_array[17] = 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 Language Extensions Documentation Character Sets Identifiers Types Constants Declarations Initialization Arithmetic Type Conversion Pointer Type Conversion Expressions Control Statement Expressions Control Flow Switch Statements Functions Pointers and Arrays Structures and Unions Preprocessor Directives Standard Libraries Run-Time Failures

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?

  • Login