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, 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 behavior.
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.
However, 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, 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 in Table 1 below is taken from section 9 of MISRA-C:2004 and ensures that all automatic variables are assigned values prior to being used:
As you can see from this example in Table 2 below , MISRA-C++:2008 follows a similar style:
The MISRA compilation of rules is enormously valuable. However, if there was 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.
<><><><><> has automated 90% of the 141 MISRA-C:2004 rules in its TBmisra product. Of the unsupported rules, 14 standards are not deemed to be statically analyzable 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's 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's 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 organization. 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 (Figure 1 below ).
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 a software engineer with LDRA Ltd. He 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.