Automating Compliance to MISRA C/C++ Standards

August 11, 2009 by  
Filed under Features

LDRA Staff - PDH Sho#47CD6A

By Paul Humphreys, software engineer, LDRA Ltd.

Thanks to their inherent flexibility and potential for portability across a wide range of hardware, C and C++ have become the languages of choice for the development of real-time embedded applications within the automotive industry. C and C++ have most of the features a software development team could wish for, and in the right hands they can be used to write well laid out, structured, and expressive code. In the wrong hands, this flexibility can lead to perverse and extremely hard to understand code.

The Motor Industry Software Reliability Association (MISRA) has done much to promote best practice guidelines for the C, and now C++, languages. In 1998, MISRA published their C standard to promote the use of “safe C” in the UK automotive industry, which was updated and re-released as MISRA-C:2004. Widely accepted as a “safe-subset” for use in the C language, the MISRA guidelines draw from a variety of sources, but in particular address the issues highlighted in the ISO standard regarding unspecified, undefined, and implementation-defined behaviour. 

 MISRA-C does not comment on the suitability of C for use in safety-critical systems, but in recognition of the widespread use of C, aims to promote the safest possible use of the language. Similarly, the suitability of C++ is not judged, and was in any case outside the scope of the 2004 guidelines. In response to the increasing popularity of C++, and despite the presence of existing guidelines such as the Air Vehicle (AV) C++ coding standards from Lockheed Martin, however,  MISRA followed its work with C by defining a suitable subset of C++, namely MISRA-C++:2008, launched in June 2008. As C++ becomes a more significant player in the automotive space, no doubt this standard will play a more dominant role.

 

What do the rules look like?

For each rule, MISRA-C offers a rule number, category, requirement text, and source reference. The motivation for the rule is given, and typically an example of non-compliant code is supplied. The  following rule is taken from section 9 of MISRA-C:2004 and ensures that all automatic variables are assigned values prior to being used: 

Rule 9.1 (Required)

 

All automatic variables shall have been assigned a value before being used.

 

[Undefined 41]

Rationale – A variable which is used before it has been assigned a value will likely cause data flow anomalies.

{

     int x;

     int y;

 

     x = y;

}

 

 

 

 

 

 

 

 

 

As you can see from this example, MISRA-C++:2008 follows a similar style:

 

Rule 10-1-3 (Required)

 

An accessible base class shall not be both virtual and non-virtual in the same hierarchy.

Rationale – If a base class is both virtual and non-virtual in a multiple inheritance hierarchy then there will be at least two copies of the base class sub-object in the derived object. This may not be consistent with developer expectations.

class A {};

class  B1:

public virtual A {};

class  B2:

public virtual A {};

class  B3:

public virtual A {};

class  C:

public B1, B2, B3 {}; // Non-compliant

 

The MISRA compilation of rules is enormously valuable. However, if there were no way to automatically apply these rules to your code, they would have very little impact on software quality. Indeed, MISRA-C places great emphasis on the use of static analysis tools to enforce compliance with the safer subset of C. Many of the rules would be extremely complicated to check manually as they involve tracing data flow across system components and tracking properties such as the underlying type of variables. Underlying type is a concept introduced by MISRA as part of its rigorous approach to strong typing and declarative consistency. Several sections of the document are dedicated to preventing type conversions deemed unsafe, unnecessary or non-explicit.

LDRA, a company specialising in software test and automation, has automated 90% of the 141 MISRA-C:2004 rules in their TBmisra product. Of the unsupported rules, 14  standards are not deemed to be statically analysable by a tool and are documented in the LDRA reports as such, but in some cases still receive a degree of support via another technique such as run-time analysis.

How have these standards helped?

Since software increasingly plays a more integral and sophisticated role in modern vehicles, the intangible nature of software proves a significant challenge. Traditionally, there has been little visibility into the software process and into the factors influencing software.

As well, project managers have been poorly equipped to control risks. At the project level, software has introduced cost and timeliness challenges while at the product level, there is a huge need to measure the consequences of failure. Just as physical components have required statistical analysis of the mean time between failures, there has been much debate about whether software within the automotive industry can tolerate a mean time between failures or whether it needs to be 100% reliable—and if so, how to achieve this.

For these problems, MISRA-C offers hope. The standard has brought a process for checking the quality of software design and development that has previously only been available for physical components and their manufacturing process. As a result, MISRA-C has been widely embraced by companies such as DENSO, Delphi, Paragon, Yaskawa, Ford, Continental, and Actia, to name a few, as a basis for encouraging good programming practice, focusing on coding rules, complexity measurement and code coverage, and ensuring well designed and tested code which is safe.

Notably, compliance can only be claimed for a product and not for an organisation. In order to rely on a tool to produce the correct results for each product, it is important that the developer has confidence in the static checking tool, which might be obtained by the tool supplier providing evidence of conformance with a MISRA-C validation test, or exemplar, suite. Continuing compliance with the standard is only possible if the static analysis tools chosen integrate the rules as they are updated. Some tool vendors choose not to offer programming standards checking, whereas LDRA, amongst others, are committed to offering standards compliance within their static analysis tools and through regular updates.

Notably, once an automated software test process is in place, automotive companies are able to track project readiness as well as product quality. For managers, tools such as LDRA’s TBvision offer next-generation graphical display of code quality, fault detection and avoidance measures (see Figure 1).

  DRA initialise_150

Code that does not conform to the guidelines is highlighted, aiding documentation and modification. Meaningful and graphical reports enhance understanding of the source code, leading to improvements in testability, error resolution and code maintainability. With these tools, managers are more able to effectively enforce the MISRA and company coding standards as well as prove conformance.

 

Paul Humphreys is responsible for the ongoing enhancement of the LDRA static analyzer. Paul has a Masters degree in Computing for Commerce and Industry, and possesses almost 20 years experience in software development with companies such as British Aerospace and GEC Marconi.

 

 

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!

Spam protection by WP Captcha-Free