logo slogan

MISRA-C:2004  the C for Safety Critical Systems

 

With much anticipation MISRA-C:2004 or “C2” as it is informally known arrived in the 13th of October 2004 at the Embedded Systems Show, NEC Birmingham.  Much anticipation? Before the launch the members of the working group have had quite a few calls from compiler writers, other test tool companies and engineers about to start new project for any advanced information.      

 

In the 7 years since the first version, "C1", quietly arrived on the scene in 1998, produced as a   supplementary document to the 1994 MISRA Software Development Guidelines, it has spread from a UK produced automotive guide to a world wide general purpose embedded C coding standard. At the recent MISRA-C forum only half the delegates were automotive. There were representatives of almost all the safety critical disciplines such as aerospace, medical, control systems etc.   this change of emphasis is highlighted by the change of the long title for MISRA-C to “Guidelines for the use of the C language in critical systems”.  Yes, it is no longer “… in vehicle based systems”

 

There has been a reported comment that some rules were dropped because “they were daft”. This was not exactly the case.  Initially the MISRA-C Working Group lead by Gavin McCall strove to keep the same rule numbering for C2.  However we now had 7 years of hindsight and feedback from the industry. The problem was that, as we clarified things some rules expanded (with parts a, b, c, d and e). With other rules we removed some of the overlaps and conflicts. In some cases we realised that we were going to loose some rules altogether because other amended rules now covered them.  We started with 127 C1 rules, lost 15 and now have 142 C2 rules.  We dropped the 15 rules because they were “daft” in the new line up not because they were necessarily wrong originally.

 

Eventually we had to re-order the rules. It became clear during the process, as we had split up some of the rules parts of them really belonged in other areas. This meant that we needed to move rules, insert new rules and delete some. So when we renumbered the rules we also took the step of putting the rules in to numbered sections. Therefore if we add or remove rules from any section in the future it will not effect the other sections and keep disruption to a minimum.

 

One complaint we had from a reviewer was that C2 was “C1 for static analysis tools”. Well in a way it is. What we strove to do was remove ambiguity and leaving things open to interpretation.  Despite improvements in fuzzy logic and expert systems, static analysers still need precise rules.  So whilst we did not design C2 as a “static analysers guide” we did take out as much of the guesswork and ambiguity as possible.   This also means that, we hope, all tools should interpret the rules in the same way.  Mechanical static analysis is one of the most efficient, and reliable, ways of checking source code and MISRA-C recommends some form of static analysis.   In addition, more precise but still plain English will make it easier for working engineers to use.

 

Hopefully it will now mean that all tools producers will be doing the same thing when they check for rule violations. This leads on to the next major topic for the MISRA-C Working Group.  Tool conformance.  In the past there was an attempt by several members of the MISRA-C Working Group to produce a test or example suite for MISRA-C.  These became combined under Les Hatton. The C1 “test suite” was never completed because it became clear that some of the major problems with the C1 test suite could be removed by clarifying the rules.  The clarification would of course be C2.

 

Now we have C2 we intend to produce and example test suite. This will be produced by the MISRA-C Working Group.  The intention is that it will be freely available to users.  Testing and certification is an expensive and time-consuming process fraught with legal pitfalls. So rather than MIRA or MISRA testing a tool’s conformance and issuing certification we felt it would be better to let the users and the tool vendors have access to the same test suite to do the testing themselves.

 

The Working Group has some administration matters to attend to but we hope to start the initial work on the test suite in Q1 2005.  By the end of Q1 we should have some idea how long it will take to produce. 

Another misunderstanding is the removal of the references to SIL levels.  MISRA-C2 is usable at all SIL levels. We simply removed the reference in C1 that said it was only suitable for SIL1-3 and not SIL4.

C is permitted for SIL4, see table C1 in 61508 part 7, but only if used as “C with subset and coding standard, and use of static analysis tools”. Otherwise C should only be used for SIL1.   So it follows if you are using MISRA-C and a static analysis tool you can use it for all SIL levels. However, there are many other requirements for working at SIL 4 apart from choice of language.

 

As many studies have shown the choice of language is a minor factor in the number and type of bugs in systems. It reminds me of a joke about some one who drives the half-mile from the office to the burger bar for lunch: orders a Big Burger, Large Fries and a Diet Cola and then drives back to the office firmly in the belief that he is being healthy by having the diet cola. MISRA-C can only help you as part of a calorie controlled SW process.

 

MISRA-C2 is still ISO 9899:1990 (C90) compliant. Why, when we have been asked for a C99 version? Well the answer is simple.  As of January 2005 there are no C99 conforming compilers.  There are plenty that are “somewhere between” C90 and C99 and a couple that claim to be nearly C99 compliant but 95% of the embedded compilers, and certainly all the mainstream embedded compilers, are still C90.  We expect that MISRA-C3 will be C05 compliant. There will be a C05 shortly which is C99 + TC1 and TC2. Anyone who wants the two TC’s please email me. chills@phaedsys.com

 

We have been asked, several times, for a MISRA-C++ and an MISRA-ADA. MISRA is a Motor (automobile) organisation not aerospace and there is already a SPARC-ADA so we will decline the offer! As for MISRA-C++, well C++ is an immensely more complex language than C. I think we did suggest that we would start on a MISRA-C++ when Les Hatton produces Safer C++, which will be his final work as he mentioned something about over his dead body….  We were a little surprised at the request as there is already a well supported Embedded C++ or EC++ so, as there is a group looking at a subset of C++ for embedded use we will decline the offer to do a MISRA-C++.   (never say never!!! See MISRA-C++:2008)

 

The final and overriding hurdle is time and resources. It has taken us 4 years to go from C1 to C2. We know how much work is involved and we still have to do the test suite. We simply do not have time and resources to take on another, more complex, language. 

 

Before you ask why we did C in the first place let me point out that we work in real industrial Engineering as it is now. Producing next year’s production cars. It is a fact of life that C is used for 95% of the software. The people, the tools and the experience is in C. We have to work with what is happening in reality. We could have done MISRA-Modular2 but it would not have much of impact in the automotive industry and been all but ignored by the rest. It would not have improved software in than automotive industry one jot.

 

One area we will have to look at early in 2005 is auto-code generators.  Many automotive companies use UML CASE tools and other tools that generate code. The code from these should be MISRA-C compliant but as these tools generate precise and consistently repeatable code should they need to work strictly to the MISRA-C rules?  Some tools may use specific constructs MISRA-C forbids because they can be misused but the tool is guaranteed use the construct in a precise and safe manner every time. There is no misuse of a  construct.

 

The other point about auto generated code is that whilst, in many cases the frame work is automatically done much of the content is still hand done so the code will have to be uniform and working to the same constraints. Remember you will still have to run the whole lot through a static analyzer anyway.  The static analyzer will need a standard MISRA-C (or probably a MISRA-C2a) configuration.

 

We would welcome feedback from anyone who has an auto code generator.  If we can get a standard system for all auto code generators it will help everyone. You can email me at chills@phaedsys.com or go to the MISRA-C web site www.misra-c.com.

 

The last thing I must point out, as I constantly did with MISRA-C1, is that The Rules are in chapter SIX. There are FIVE preceding chapters you should read before you read the rules. Let alone implement the rules.   These cover the background, what we expect you to do, the assumptions we made, the limits we saw and implementation suggestions. Read the fist five chapters.

 

What of those of you on MISRA-C1?  Firstly C1 will continue to be available as is. There are many projects using it that have a few years life yet. C1 is as good as it always was. However C2 is an improvement and we would recommend it for all new projects.  There will be no more TC’s of fixes etc for C1.  If you ask on the forum on www.misra-c.com your C1 questions will be answered. Though when we discussed this, the comment from one of the Steering Committee was that the clarifications are C2!  If you are using C1 do use the Technical Corrigendum. 

 

As MISRA is completely independent and will not endorse any commercial product

 

We have no idea when MISRA-C3 will be available but given the fun we had doing C2, the work we have to do for the test cases, autocode and catching up with the version of C in use 2-3 years time I would say it will not be before 2012.  So dive in. If you are using MISRA-C1 get the C2. If you are not using a coding standard with C: why not?  Get a copy of MISRA-C2  they are available from MISRA via the web site also Programming Research, LDRA  and  Phaedrus Systems Ltd.