Phaedsys

 At last there is an authoritative, generally available, C standard for embedded and real-time work [ref. 1].It is also inexpensive at 25-00 UKP (around 30USD) in the UK. It grew out of a need in the automotive industry with the rapid increase of the use of software to control the modern car. Engine management, brakes, instruments and those annoying gizmo's that say "Fasten your seat belt!".

In April 1998 MISRA [Ref. 3],the software consortium managed by MIRA [Ref. 2] released their "Guidelines For the Use Of The C Language In Vehicle Based Software". Don't be misled by the title! Whilst it was developed for the automotive industry the acknowledgements page spans universities, compilers writers, R&D organisations, SW specialists, SW tools companies, a list of 36 individuals, several of which are household names (in the SW industry). Many will be familiar to members of the ACCU [ref. 4]. It also mentions that the automotive companies involved came from Austria, Scandinavia, Germany, USA, UK, and Japan.

I was told that this standard took two years to produce so it has not been done lightly though with the speed at which the ISO crowd work one might think so. (That is a subtle hint to the C, C++ and JAVA ISO committees!)

So much for the pedigree what does the standard actually contain? The usual preamble of the why's and wherefore's, scope and usage. Also how to use the rules in Sw development [ref5] The real meat is in The Rules. There are over one hundred and twenty of them. The are split in to seventeen sections such as Environment, Types, Control Flow, Functions. The rules are further sub-divided into "Required" and "Advisory".

Each rule is numbered and stated simply. For most some explanation is given with source code in a few examples. In many cases there is a reference to source documents and where possible the ISO C standard. Remember the language standard is just that it defines the syntax. Good practice is not defined in ISO9899. At the end is a very useful cross reference to ISO 9899. So those of you without it can write your own in house coding standard using these guidelines and be able to reference ISO C as well. [NOTE The standard uses was ISO9899 1990 or C90 as it is known. It does not reference the C99 version (April 2002)]

Some (most?) of the "Required" Rules are obvious common sense.... well I thought so until I discussed one or two with some programmers and discovered I had a different interpretation on "obvious" and "common sense" to some of them. These guidelines will be useful just to keep your engineers on their toes. See how many know why some of the rules are there. As I said many should be obvious common sense but...

These rules are for use on all the MISRA safety levels (0 to 3) except the highest, level 4, which requires "a certified language with proven formal semantics". Level 4 will not be using C. This guide will get you as safe as you are going to get with C, not withstanding the disclaimer on page ii. Even with a good programming standard some programmers can make a right mess of it.

What MISRA C will not tell you is what to put in the source file identification, history copyrights etc., file naming conventions, code layout, intending. It does not delve into the religious argument of where the {} go, there is an internet newsgroup for that! None of these issues will affect the reliability of the software even if it does have a bearing on readability and maintenance.

Whilst mentioning readability I have to read a lot of standards and this is the most readable one to date. When I took it in to the office I actually had engineers reading it with interest! MISRA C is written with the idea that a real engineer, rather than a theoretical standards guru, will be using this guide. The rules are in simple and plain English. [April 2002:- It is for this reason it is not as precise as it could be and therefore there are variations in the way people understand the rules. Coupled with the fact there is no standard test suite and MISRA-C compliance test tools do have some differences. However this does not mean one or either of them is wrong.]

Having previously dismissed the preamble before the rules , six sections, it does contain a lot of useful information more than one would think, on first glance. Information such as what the compiler does and does not do. That will surprise a few people. How many programmers do you know who say "It must be correct: it compiles."?

There is a section on compliance matrix which is a useful idea on it's own. Basically it says we know what the rules are but where are they tested? More importantly can we prove that they have all been tested. See QuEST [Ref 5] where there are several Matrix available for download

There is information on how to claim compliance to the standard. For those not in the automotive trade it is a very sensible list of things we should all be doing anyway. All ISO9000 companies should have no trouble with the proof of conformance...... [April 2002 Because there is no standard test suite and some of the rules are a little ambiguous there is no definitive method of coding compliance. You will have to say which tool is to be used. This is not a problem as both the test suite and clarification of the rules is being worked on. ]

Do make sure you read the sections (1 to 6) before The Rules. Though it will probably be after you have gone through the rules. [April 2002: Reading the sections 1-6 is essential. however even if you only read the rules and you start to use some of them it will improve your code.]

I am looking hard to find something to complain about but apart from the title there is nothing. [April 2002: Notwithstanding all the additional comments I have made since I first wrote this I still think overall there is nothing else about to touch the guide. The deficiencies are not major and are being addressed.] The title comes about because previously they have produced the "MISRA Development Guidelines for Vehicle Based Software" and they wanted the names to match. Given the standard of these guidelines I am minded to look at their development guidelines. [April 2002: The title is no longer a problem. It is just known as MISRA-C around the world!]

So no complaints but a wish list. This is a generic guide for all embedded use. Perhaps in the next version "they" [see footnote 2] could do a series of appendices for the 8051 family, 166, H8 68* etc. Some of the RTOS manufacturers might like to produce their own addendum. (Talk to MISRA.) These MUST be complimentary to this guide. They will cover some of the idiosyncrasies of these families and RTOS. I am thinking of things like defines for the 8051 xdata. Also a portability matrix for writing code for use on more than one target. I would see these addendum as tightening things up. Thus there will be additional "8051 rules" containing things like: Rules 2,10, 40,86 move from "advisory" to "required". I would not expect to see any going the other way.

By the way, MISRA stands for the Motor Industry SOFTWARE RELIABILITY Assn [author's emphasis]. We all need reliable software and not just in cars. So whilst the standard has been done primarily for the automotive industry it is applicable to all embedded safety critical work. Given the cost and clarity of the standard there is little excuse for not using it as a guide on all embedded C. Come to that any C, embedded or not. I expect (hope) "MISRA-C" to become a de facto standard. [In Feb 2002 the US SAE had a meeting where MISRA-C was suggested for the core standard for all US Automotive manufacturers.]

For the record I have no connection with MIRA, MISRA or the production of these guidelines. I just have to produce (embedded) software that works. (see footnote 2)

Eur Ing Chris Hills BSc, C. Eng, MIEE, MIEEE, FRGS
Technical Specialist for iSystem Ltd.UK
email chris@phaedsys.org

 Footnote1:(1999)

Footnote 2: April 2002
Since the last foot note the author joined the Misra-C working group in 2001 to work on the second edition of the guide. The author is also a member of the BSI/ ISO C panel (IST/5/-/14) (and Convenor Dec 2000 to Dec 2004 ) so I am having to eat my comments on the time it takes to produce a standard!

Many tools have now been produced to test for the MISRA-C rules. However as there are still some anomalies in the guide and no standard test suite there is no definitive set of tests. Thus when claiming "MISRA-C Compliance you have to state which tool you are using. There is more on this in the Embedded C Traps and Pitfalls Paper [Ref 6].

Also available are MISRA-C Compliance Matrix for Lint and DAC (with others to follow) on the authors web site as part of the QuEST software Engineering series Click here for QuEST