Vehicle software design outside the entertainment realm is tougher than most system designs. Reliability and safety usually hold greater significance than features or maximum performance. On the whole, hardware and software designs tend to be very conservative.
The C programming language is very popular for vehicle platforms. Unfortunately, creating bugs in C is notoriously easy. Dangling pointers, buffer overruns, and even a missing plus sign can wreak havoc on even the best system design. One way to minimize such errors is to reduce the power of C by restricting the features a programmer can use.
The Motor In-dustry Software Reliability Association (MISRA) takes this approach with its C guidelines. The MISRA "Development Guidelines for Vehicle Based Software" document contains 127 rules relating to the ISO/ANSI standard programming language for C, along with justifications and examples. A number of popular embedded C and C++ compiler vendors implement these rules so programmers can have abuses flagged as warnings or errors.
Although MISRA C, as it's called, is intended for the development of embedded automotive systems, it's equally applicable to almost any embedded application environment. Many of the MISRA C rules restrict the use of C features like pointers. Pointers are often used for efficiency purposes, even when alternatives such as array indexing can provide the same effect.
In the past, using pointers was explicitly more code-efficient and offered higher performance than arrays. Many current compilers internally transform array operations like these into pointer operations, essentially making the array-based source code into object code that's as efficient as the pointer version. The advantage is that the pointer-oriented compiler-generated code is created in a controlled fashion.
MISRA C's rules are divided into 17 sections, which include Declarations and Definitions, Control Flow, Pointers and Arrays, Structures and Unions, and Standard Libraries. Rules are additionally divided into required and advisory rules. Most C compilers implement MISRA C restrictions so that developers can employ the full standard or a subset of it. Selective use of MISRA C is handy when migrating an application to MISRA C.
Some may think that putting restrictions on programmers would result in mutiny, but most developers adept at using C will already implement many of the MISRA C rules informally. Rule 34 shown in the table is just one example. Embedded assignments are another. With over 120 rules, programmers will be hard-pressed not to find a few they prefer. Most are common-sense improvements that will appeal to programmers after they understand the rules and their implications.
MISRA C isn't a standard but more of a recommendation. The rules are written in plain English, although some rules are ambiguous, and some redundancy exists. There's no standard test suite, so MISRA C compilers or compliance testing tools can generate different error or warning messages for the same source code.
Not surprisingly, MISRA C is very popular in the automotive arena. MISRA C has also found a following in most embedded areas, simply because the recommendations are so complete. Any improvements through additional rules would be minor.
Programming experience is still important, even when using MISRA C. Although it won't completely eliminate bugs, MISRA C will help reduce the number of errors that find their way into an application.
www.misra.org.uk
| MISRA C EXAMPLE |
|
•Rule 34 (required) •The operands of a logical && or || shall be primary expressions Invalid if ( x= = 0 && ishigh ) Valid if ( ( x == 0 ) && ishigh ) Primary expressions are constants, a single identifier such as ishigh, or a parenthesized expression. Parentheses are important for readability and ensuring that the behavior is what the programmer intends. |
