实例介绍
【实例简介】
主要是汽车电子行业c编程规范 UN_MISRA Compliance 2016
MISRA Compliance: 2016 Achieving compliance with MISRA Coding Guidelines April 2016 MISRA Mission statement We provide world-leading best practice guidelines for the safe and secure application of both embedded control systems and standalone software MISRA is a collaboration between manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-and security-related electronic systems and other sottware-intensive applications To this end Misra publishes documents that provide accessible information for engineers and management, and holds events to permit the exchange of experiences between practitioners Disclaimer Adherence to the requirements of this document does not in itself ensure error free robust software or guarantee portability and re-Use Compliance with the requirements of this document, or any other stondard, does not of itself confer immunity from legal obligations Foreword Ever since MISra C first appeared, it has been recognised that circumstances sometimes occur when t is impracticable or unreasonable to follow the requirements of a guideline. However, the concept of approved violations, known as deviations, has caused much debate, especialy when discussing their effect on a claim of MISRA compliance. A myriad of approaches to compliance have been proposed within projects, ranging from a"no deviations all owed"policy through to the liberal use of deviations n an attempt to justify areas of non-compliance MISRA Compliance: 2016 revises the guidance on compliance, and Defines what is meant by MISRA Compliance; Provides a mechanism for tailoring the classification of the guidelines to match the needs of a project Provides clearer guidance on the use of deviations provides a mechanism for establishing pre-approved"permits"to help streamline the deviation process Requires that a standardised declaration be issued to show the final level of compliance claimed by a project This gui dance will become the standard approach for all future editions of both the misra c and MISRA C++ Guide ines. It is also an optional enhancement to, and fully compatible with, all existing editions of the misra language guidelines encourage all users, and all organisations, to consider adoption at the earliest opportunity Andrew Banks FBCs citP hairman, MISRA C Working Group Acknowledgements The MISra consortium wishes to acknowledge the contribution made by the japan automobile Manufacturers Association to the preparation of this document The MiSra consortium would like to thank the fo lowing individuals for their significant contribution to the writing of this document Paul burden Independent Consultant( Formerly Programming Research Ltd) Chris Tapp RA Ltc /Keylevel Consultants Ltd The Misra consortium also wishes to acknowledge contributions from the following members of the MISRA C Working Group during the development and review process Fulvio baccaglini Programming Research Lto Dave banham Rolls-Royce plc Andrew Banks Frazer-Nash Research Ltd /Intuitive Consulting Mark bradbury Independent Consultant(Formerly Aero Engine Controls 」 i Britton Programming Research Ltd Peter Clayson Zytek Atomotive Ltd Mike hennell LDRA Lto Chris hills Phaedrus systems Ltd Liz Whting LDRA Lto The misra consortium also wishes to acknowledge contributions from the following individuals during the development and review process David ward H○R|BAM| RA LtO Contents Introduction The context 2.1 The development contract 2.2 The software development process Fundamental elements of compliance 3.1 Guideline classification 3.2 Analysis scope 3.3 The guideline enforcement plan 3. 4 Invest gating messages 3.5 Decidability Deviations 4.1 The role of deviations 4.2 Deviation records 4.3 Deviation permits 4.4 Justifying a deviation The guideline re-categorization plan 10 5. 1 Re-categorization 10 Adopted code 6.1 The nature of adopted code 6.2 System wide analysis scope 6.3 Adopted binary code 6.4 Adopted source code 6.5 Adopted header files 14 6.6 The Standard Library 14 Claiming Misra compliance 7.1 Staff competence 15 7.2 The management process 7.3 The guideline compliance summary 7.4 Project delivery 17 References Appendix a Example deviation record 20 Appendix b Example deviation permit 23 Appendix c glossary 24 1 Introduction The Misra language documents [1]. [2], [3]and [4]( The Guidelines") are compilations of guidelines for coding in the C and C++ languages. They are widely used in the development of critical software systems when the requirements of a quality standard must be met. Many software projects specify that code quality should be assured by meeting the requirements of The Guidelines. However, the meaning of the phrase "MI SRA compliant" needs to be carefully defined n order for a claim of MISRA compliance to have meaning, it is necessary to establish EXactly which guidelines are being applied, e The effectiveness of the enforcement methods The extert to which deviations have been used Use of a disciplined software development process; The status of any components developed outside of the project The guideline documents recognise that, in some situations, it is unreasonable or even impossible to comply with a coding guideline and that it is necessary to deviate. The freedom to deviate does not necessarily compromise claims of compliance but it does carry with it great responsibil ty In the absence of a disciplined development process, it is easy for that freedom to be abused. At best, that will undermine the credibility of any claims of MIsra compliance; at worst, it will compromise code quality, safety or secur ity. It is therefore important to emphasise that a credible claim of compliance ith The Guidelines can only be made when code is developed under a process which meets the principles aid out in this document The guidance given in this document supersedes the compliance, deviation and process requirements pub ished previously in the vario Is MISRA Guidelines Note: The various misra Guideline documents have been refined and revised over a number of years This document uses examples and extracts from both the misra c: 2004 and MISRA C: 2012 Guidelines, but the issues discussed are equally relevant to all of the guide ines published by MISra 2 The context 2. 1 The development contract A decision to adapt and apply mi sra guidelines should be taken at the outset of a project. The application of MISRa Guidelines will typically be one requirement among many of a contractual greement between two part es, the organization commissioning the project (the acquirer) and the organization developing the code(the supplier). These parties may be different commercial entities or they may simply be different departments within the same organization. Both will need to be actively nvolved in the task of assuring compliance with MISRA Guidelines. MISRA Compliance is not a rigidly defined concept and acceptance criteria will be a matter for negotiation however there are some clear principles which must be observed in order for the concept of compliance to have credibility 2.2 The software development process MISRA Guidelines are intended to be used within the framework of a documented software development process. They are of greatest berefit when a process is in place to ensure that, for ample 1. The sottware requirements, including any satety or security requirements, are complet unambiguous and correct 2. The design specifications reaching the coding phase are correct, cons stent with the requirements and do not contain any other functionality 3. The object modules produced by the compiler behave as specified in the corresponding g 4. The object modules have been tested, individually and together, to identify and eliminate errors A full discussion of the requirements for software development processes is outside the scope of this document. Further information may be found in standards such as ISO/lEC 12207: 2008 [5]. EC615082010[61S02626220117DO-178C81.N50128:2011[9] and iec62304:2006[101 ompliance with MIsRa Guidelines must be an integral component of the code development phase and compliance requirements need to be satisfied before code is submitted for review or unit testing. A project that attempts to check for compliance late in its lifecycle is likely to spend a considerable amount of time in re-coding re-reviewing and re-testing, and it is easy for this rework to ntroduce detects by accident. Code shall be checked for compliance as it is developed and not as part of a"tick-box"exercise to be completed as part of the final delivery phase f a project is building on code that already has a proven track record, then the benefits of gaining compliance by refactoring existing code may be outweighed by the risks of introducing a defect In such Cases a judgernent needs to be made based on the net benefit likely to be cbtained 2 【实例截图】
【核心代码】
主要是汽车电子行业c编程规范 UN_MISRA Compliance 2016
MISRA Compliance: 2016 Achieving compliance with MISRA Coding Guidelines April 2016 MISRA Mission statement We provide world-leading best practice guidelines for the safe and secure application of both embedded control systems and standalone software MISRA is a collaboration between manufacturers, component suppliers and engineering consultancies which seeks to promote best practice in developing safety-and security-related electronic systems and other sottware-intensive applications To this end Misra publishes documents that provide accessible information for engineers and management, and holds events to permit the exchange of experiences between practitioners Disclaimer Adherence to the requirements of this document does not in itself ensure error free robust software or guarantee portability and re-Use Compliance with the requirements of this document, or any other stondard, does not of itself confer immunity from legal obligations Foreword Ever since MISra C first appeared, it has been recognised that circumstances sometimes occur when t is impracticable or unreasonable to follow the requirements of a guideline. However, the concept of approved violations, known as deviations, has caused much debate, especialy when discussing their effect on a claim of MISRA compliance. A myriad of approaches to compliance have been proposed within projects, ranging from a"no deviations all owed"policy through to the liberal use of deviations n an attempt to justify areas of non-compliance MISRA Compliance: 2016 revises the guidance on compliance, and Defines what is meant by MISRA Compliance; Provides a mechanism for tailoring the classification of the guidelines to match the needs of a project Provides clearer guidance on the use of deviations provides a mechanism for establishing pre-approved"permits"to help streamline the deviation process Requires that a standardised declaration be issued to show the final level of compliance claimed by a project This gui dance will become the standard approach for all future editions of both the misra c and MISRA C++ Guide ines. It is also an optional enhancement to, and fully compatible with, all existing editions of the misra language guidelines encourage all users, and all organisations, to consider adoption at the earliest opportunity Andrew Banks FBCs citP hairman, MISRA C Working Group Acknowledgements The MISra consortium wishes to acknowledge the contribution made by the japan automobile Manufacturers Association to the preparation of this document The MiSra consortium would like to thank the fo lowing individuals for their significant contribution to the writing of this document Paul burden Independent Consultant( Formerly Programming Research Ltd) Chris Tapp RA Ltc /Keylevel Consultants Ltd The Misra consortium also wishes to acknowledge contributions from the following members of the MISRA C Working Group during the development and review process Fulvio baccaglini Programming Research Lto Dave banham Rolls-Royce plc Andrew Banks Frazer-Nash Research Ltd /Intuitive Consulting Mark bradbury Independent Consultant(Formerly Aero Engine Controls 」 i Britton Programming Research Ltd Peter Clayson Zytek Atomotive Ltd Mike hennell LDRA Lto Chris hills Phaedrus systems Ltd Liz Whting LDRA Lto The misra consortium also wishes to acknowledge contributions from the following individuals during the development and review process David ward H○R|BAM| RA LtO Contents Introduction The context 2.1 The development contract 2.2 The software development process Fundamental elements of compliance 3.1 Guideline classification 3.2 Analysis scope 3.3 The guideline enforcement plan 3. 4 Invest gating messages 3.5 Decidability Deviations 4.1 The role of deviations 4.2 Deviation records 4.3 Deviation permits 4.4 Justifying a deviation The guideline re-categorization plan 10 5. 1 Re-categorization 10 Adopted code 6.1 The nature of adopted code 6.2 System wide analysis scope 6.3 Adopted binary code 6.4 Adopted source code 6.5 Adopted header files 14 6.6 The Standard Library 14 Claiming Misra compliance 7.1 Staff competence 15 7.2 The management process 7.3 The guideline compliance summary 7.4 Project delivery 17 References Appendix a Example deviation record 20 Appendix b Example deviation permit 23 Appendix c glossary 24 1 Introduction The Misra language documents [1]. [2], [3]and [4]( The Guidelines") are compilations of guidelines for coding in the C and C++ languages. They are widely used in the development of critical software systems when the requirements of a quality standard must be met. Many software projects specify that code quality should be assured by meeting the requirements of The Guidelines. However, the meaning of the phrase "MI SRA compliant" needs to be carefully defined n order for a claim of MISRA compliance to have meaning, it is necessary to establish EXactly which guidelines are being applied, e The effectiveness of the enforcement methods The extert to which deviations have been used Use of a disciplined software development process; The status of any components developed outside of the project The guideline documents recognise that, in some situations, it is unreasonable or even impossible to comply with a coding guideline and that it is necessary to deviate. The freedom to deviate does not necessarily compromise claims of compliance but it does carry with it great responsibil ty In the absence of a disciplined development process, it is easy for that freedom to be abused. At best, that will undermine the credibility of any claims of MIsra compliance; at worst, it will compromise code quality, safety or secur ity. It is therefore important to emphasise that a credible claim of compliance ith The Guidelines can only be made when code is developed under a process which meets the principles aid out in this document The guidance given in this document supersedes the compliance, deviation and process requirements pub ished previously in the vario Is MISRA Guidelines Note: The various misra Guideline documents have been refined and revised over a number of years This document uses examples and extracts from both the misra c: 2004 and MISRA C: 2012 Guidelines, but the issues discussed are equally relevant to all of the guide ines published by MISra 2 The context 2. 1 The development contract A decision to adapt and apply mi sra guidelines should be taken at the outset of a project. The application of MISRa Guidelines will typically be one requirement among many of a contractual greement between two part es, the organization commissioning the project (the acquirer) and the organization developing the code(the supplier). These parties may be different commercial entities or they may simply be different departments within the same organization. Both will need to be actively nvolved in the task of assuring compliance with MISRA Guidelines. MISRA Compliance is not a rigidly defined concept and acceptance criteria will be a matter for negotiation however there are some clear principles which must be observed in order for the concept of compliance to have credibility 2.2 The software development process MISRA Guidelines are intended to be used within the framework of a documented software development process. They are of greatest berefit when a process is in place to ensure that, for ample 1. The sottware requirements, including any satety or security requirements, are complet unambiguous and correct 2. The design specifications reaching the coding phase are correct, cons stent with the requirements and do not contain any other functionality 3. The object modules produced by the compiler behave as specified in the corresponding g 4. The object modules have been tested, individually and together, to identify and eliminate errors A full discussion of the requirements for software development processes is outside the scope of this document. Further information may be found in standards such as ISO/lEC 12207: 2008 [5]. EC615082010[61S02626220117DO-178C81.N50128:2011[9] and iec62304:2006[101 ompliance with MIsRa Guidelines must be an integral component of the code development phase and compliance requirements need to be satisfied before code is submitted for review or unit testing. A project that attempts to check for compliance late in its lifecycle is likely to spend a considerable amount of time in re-coding re-reviewing and re-testing, and it is easy for this rework to ntroduce detects by accident. Code shall be checked for compliance as it is developed and not as part of a"tick-box"exercise to be completed as part of the final delivery phase f a project is building on code that already has a proven track record, then the benefits of gaining compliance by refactoring existing code may be outweighed by the risks of introducing a defect In such Cases a judgernent needs to be made based on the net benefit likely to be cbtained 2 【实例截图】
【核心代码】
标签：
好例子网口号：伸出你的我的手 — 分享！
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论