- | Home |
- Company |
- Contact |
- News |
- S/ware Eng |
- Standards |
- Academic Support |
- Documents |
- | Requirements |
- Validation |
- RTOS |
- Analysis |
- Software |
- Resources |
- Products |
 |
MISRA-Matters Column
|
 |
The two the most common questions we get are “What is MISRA conformance?” and “How do I deviate?” The next question is “Can you recommend a certified MISRA checking tool?” Well the three questions are interlinked and in some cases have legal significance so what I can do is explain the situation and that should let you make appropriate decisions.
First some history: The MISRA C Guidelines were originally conceived as guidance for the UK Automotive industry. In many ways it is no different to the very many other coding standards out there: It was just released. However it went global across all embedded and many mission critical domains. It surprised the MISRA team! What they had not envisaged was tool certification, test suites or how to formally claim compliance outside your own company. So there was nothing in place when the genie escaped from the bottle and as we know you can’t put genies back into bottles.
One of the problems is that many companies claim to have MISRA checking tools but none of them have been checked, certified or measured by MISRA. As there is no test suite these tools may have interpreted the rules differently to each other. As far as I know the reputable tool makers have implemented the rules in good faith and they are no more right or wrong than each other. However if MISRA compliance or checking is required for your project you should specify the tool used for checking. If you use tool A and someone else, e.g. the customer, uses tool B there could be some discrepancies.
Also remember that not all of the MISRA rules are statically checkable: they were never intended to be, for example Rules 6.1.3, 6.1.5, all Rules 6.3.x. So no one can claim 100% coverage for a static analyser or indeed any tool.
So what is MISRA conformance? It is source code that conforms to the MISRA coding guidelines. So source code can claim to be MISRA compliant but not an organisation or process. An organisation can put a process in place that is conducive to producing MISRA compliant code in the same way speed restriction signs are placed by the road to control speed….
One of the problems we are asked is “What about 3rd party code?” If it is source code it should be MISRA compliant. Compiled or object code where the source is not available can not be tested. So at a minimum the header (“include”) files should be MISRA compliant. Many suppliers of libraries and other “off the shelf” code are now tending to MISRA conformance. This is partly due to customer pressure and a gradual maintenance of their own product over time. Where possible insist on MISRA conformant code. You will of course need to know which tool(s) they used to test it. So you will probably want to see their compliance matrix and deviation documents. What is a compliance matrix? This is explained in section 4.3.1 of MISRA C and C++.
One of the problems we are seeing is people wanting “100% compliance” with every rule without understanding what they are asking for. Blindly enforcing all the rules all the time “just to keep the checker quiet” is not always the sensible way to go; it becomes a box ticking exercise. Instead you need to use engineering common sense since the rules cannot cover every eventuality or combination of circumstances. This is why MISRA C and C++ both provide a deviation mechanism.
For the obvious reasons of legality and liability neither MISRA nor any of its team members will ever tell you specifically how or when to deviate. That needs to be decided in your company to suit the project and the other standards, contractual or legal requirements you have to work to. In fact there is a whole section of this in MISRA C and C++. It is formally laid out in Chapter 4. You did read the first 5 chapters before the rules? You should do so. It is explained in a way that is applicable to larger companies such as automotive, medical or aerospace manufacturers.
For SME’s where there is often no formal “design authority” or formal procedures the rule of thumb I give is: “Document it fully and if it still makes sense to some one else 3 months later and you feel it would stand up in a court of law then it is probably OK.” By the way the “some one else” should not be some one on the same team. You need an objective outside view probably from some one non technical. Also the deviation should be in clear language “it’s neat”, “it’s cool” or programming jargon is not going to impress a Judge and Jury. Most projects will not end up in-front of a court under current law but things change.
As we have said MISRA does not certify, test or approve any tools. Neither does it approve anyone giving MISRA training courses or people offering testing or certification to MISRA guidelines. As with testing using static analysers that claim “MISRA checking” it is up to you and your customers or suppliers to determine a suitable baseline and criteria.
There are some very reputable test and certification houses who do formal testing to other standards such as IEC 61508 who have accreditation with various bodies like UKAS etc. It is unlikely that these people will do a bad job checking your project but it is on their reputation and they are not “MISRA Approved”. Compliance with the MISRA AC AGC (Autocode) Guidelines can be claimed in two ways. Firstly, compliance can be claimed for the C code modules that are produced by an automatic generator in much the same manner as compliance with MISRA C might be claimed for manually generated code. Secondly, compliance can be claimed for an automatic code generation tool itself. This is a statement that all code generated by the code generator, but not the manually entered code, will comply at the level indicated provided that the code generator has been configured as specified by the code generator vendor in its compliance statement.
As with other tools MISRA does not provide any compliance or conformance scheme or certification for tools or code.
Many standards such as IEC 61508 and ISO 26262 require the use of static analysis and a subset of C. MISRA C or C++ is a well researched subset. Sensibly applied MISRA conformance should improve your software quality as it removes many of the known problem areas and much of it is automatically testable. So you should have fewer problems and be able to find them faster. You should read the first five chapters in both MISRA C and C++ on how to implement MISRA into a project. Not least the Compliance Matrix [section 4.3.1] to show were each rule is tested (or deviated), not all of the rules are tested in the static analysis phase.
Finally whilst MISRA C or C++ does not recommend any particular style guide one should be used so the code is uniform to look at making it easier to visually spot errors. There are many available but do not spend too long arguing over which one. All you really need is consistency.
The MISRA web site www.misra.org.uk has information on all the MISRA projects and an active Bulletin Board (see www.misra.org.uk/forum) for discussion of all topics. The MISRA C Exemplar Suite is on the forum under “Resources” The Bulletin Board is also where MISRA Working Groups will post official replies to technical queries. The teams will only reply to questions on the Bulletin Board so please do not email technical questions to the Working Group chairs.
Chris Hills is a member of MISRA C WG and Chair of MISRA Languages. He can be reached at
chair-lang@MISRA.org.uk
Author Details and contact
Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE FRGS FRSA is a Technical Specialist and can be reached at This Contact
Copyright Chris A Hills 2003 -2010
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988