Misra standard for embedded software.

Question

Hi I have a requirement to make a large amount of code MISRA compliant.
First question: Can somebody to give an estimation for passing well written code for embedded system based on experience. I understand that "well written" is poorly defined and vague so i ask for raw estimation.
Second question: Any recommendation for tool that can be customizable (i.e allowing suppress specific warnings) and used in automatic build environment (i.e command line interface)
Any other useful suggestions that can help with this task.
Thanks Ilya.

Answer 1

I use PC Lint for static analysis of C and C++ code. It can be configured to show what MISRA rules have been violated, and it has a command line interface.

Answer 2

Making code Misra compliant it not too much of a chore - if you follow fairly good programming practices. You might find some of the pointer rules slightly tricky, if the code you're trying to make comply has some weird and wonderful pointer arithmetic.

I'd second Greg's recommendation for PC Lint, but the open-source Splint is also worth looking at, although between them (and the compiler's warning system), I estimate you'll still only be able to cover 80% of the Misra rules - the rest will probably need to be code reviewed by hand.

Answer 3

I also highly recommend PC-Lint. If you happen to be compiling your code with Visual Studio I recommend a plug-in 'Visual Lint' from Riverblade. If you cannot compile the code in Visual Studio, you can still run PC-Lint from the command line to good effect.

Some embedded system compilers provide MISRA compliance testing as compiler warnings. I use the IAR compiler for Arm7/Arm9 development. It provides an easy to configure MISRA compliance checklist right in the compiler setup.

It is difficult to come up with a rule of thumb for estimating the time it would take you to make some well written code MISRA compliant. A lot depends on the existing coding habits of the programmers and how closely they follow the MISRA rules in the first place.

Rough estimates:
2 - 3 days to become adept at PC-Lint usage.
Initial pass at making existing code MISRA compliant: 10 to 25 percent of the time spent writing the code in the first place.
Keeping code MISRA compliant: 5 to 10 percent added to code development. Half of this cost is changing the habits of your coders to follow the 'MISRA way' of doing things. The other half is the extra cost of code testing and inspection to ensure MISRA compiance.

Answer 4

I have used a commercial tool called QAC. The tool is able to enforce MISRA

It has a command-line interface, so you can set it up to run from a automated build environment. The rules to be applied are configurable, but expect to have someone spending some time setting it u. The MISRA enforcement is pretty straightforward and worked well enough. I was told (and this is just 3rd hand) that this is one of the tools some agencies (such as the FDA) use to evaluate code. Like most static analysis tools there is noise (false positives) to deal with. The last time I used it, it didn't have a good means to mark/stop a false positive from occurring again (without changing the code it was complaining about).

I suspect a junior engineer will take up to a week (4-5 days) to get it setup (assuming they are determined to get it working as you want).

On a side note, other commercial static analysis tools likely have MISRA enforcement as well. Reportedly (per their sales rep), Klocwork does.

Answer 5

We had a similar problem of retrofitting Misra rules. We had some code quality issues on a large project and decided to use MISRA to improve the code quality.

We use the Green Hills compiler that has support for MISRA C rules. There is also stand alone checkers available. Depending on what you want to do it can be a bit over kill switching on all the rules. We switched one the rule on at a time to give people time to fix a limited number of similar problems else you get totally overwhelmed by the amount of errors.

Since our warnings was generated by the compiler and not by a standalone tool you see the errors as you develop and not only when you run the checker. As we continued developing we got our code compliant and not in one big bang. This also prevent old habits spoiling the new code causing you to having to rework the code again later.

Some times it is difficult to get old code complaint since nobody knows exactly how the code works. I hope you have unit tests.