A blog about MISRA-C, the open voluntary consensus standard for the safe and reliable design of high integrity software.
The focus will be on MISRA C:2004 and its application to automotive embedded software development and other application domains. However, we may also touch on MISRA C++:2008 as well as MISRA AC AGC/ADA:2009.
This site is about MISRA C and C++, the open voluntary consensus standards for the safe and reliable design of high integrity software in the C and C++ programming languages. It is intended to provide news and information on the standards, and places to obtain resources relating to them.
Please see our About page for more information.
MISRA-C is a set of guidelines for developing safe software in the C programming language. The MISRA-C guidelines were first published in 1998, and have been revised several times since then. They are widely used in safety critical systems. This blog will provide opinions, comments and news about MISRA-C and its use
About me: I am an engineer who has worked on safety critical software for over 30 years, mostly in aviation. My personal interests include history, wine, cats and music.
MISRA-C is a set of coding guidelines for the C programming language developed in response to the increased use of C in safety and critical systems.
MISRA C:2012 (Third Edition) Guidelines for the use of the C language in critical systems
MISRA C:2004 (Second Edition) Guidelines for the use of the C language in critical systems
MISRA C:1998 (First Edition) Guidelines for the use of the C language in vehicle based software
MISRA Compliance:2016 Guidelines for achieving compliance with MISRA Standards and demonstrating compliance
Guidelines on the Use of MISRA-C:2012 Guidelines on the Use of MISRA-C:2012 in safety related systems
The MISRA consortium is made up of industry experts, academics and developers. It was established by a working group convened by The Institution of Engineering and Technology Automotive Advisory Board, it has now grown to include many leading automotive companies, equipment suppliers and tool vendors.
The MISRA-C Working Group are pleased to announce the publication of MISRA C:2012. In a previous blog post, I considered what we could expect from it. Now that the standard has been published, we can see if we got what we wanted.
The first thing to say is that we have a new name. We no longer have an edition number, but have a publication date. This means that you can now tell which version you are reading without checking the fine print. The year 2012 appears in small type on the front cover and in larger type on the spine and back cover.
The second thing to say is that there are some significant changes (see below for all of them). Some of these were expected, based on discussions at the MISRA C Working Group meetings over recent years (and indeed, earlier than that). Others were less predictable.
MISRA C:2012 was adopted in February 2014 and is the latest version of the MISRA C language subset for safety-related systems.
Why a standard?
There are many reasons why a standard makes sense for safety-related systems, but the key one is that standards promote consistency, which helps to minimise error. A standardised approach to software development will help to reduce errors in the software by ensuring that the same techniques are used across a project or organisation. It will also help to reduce errors in code produced by different people, even if they are working on different parts of the same project.
In some sectors, notably aerospace, it is necessary to use specific standards; for example, DO-178B (for flight-critical software) and DO-178C (the forthcoming update). In other domains there are no mandatory standards but there are good reasons why you may want to adopt them voluntarily. For example, a medical device manufacturer may want to take steps to minimise risk of failure. Or a company working on automotive equipment may want its products to be easily portable between cars from different manufacturers.
Over the last week, I have been speaking at a number of events about MISRA-C:2012 and how it can help industry move to C11. The C11 standard is now supported by all major vendors. This means that there are no longer any barriers to using C11 in safety critical applications. At these events, the question of MISRA compliance has often come up.
Many people seem to be under the impression that you can only use a subset of C11 if you want to claim MISRA compliance. This is not true. In fact, as far as I can see all the features of C11 have been assigned a specific rule type in the MISRA-C:2012 guidelines.
The important thing to understand here is that the rules defined in MISRA-C:2012 (and any other standard) are just guidelines. These are not mandatory requirements that must be followed in order to claim conformance to the standard (or indeed any kind of conformance).
MISRA-C:2012 defines two levels of compliance: Required and Advisory. The Required rules are simply those that are considered so important that they should not be ignored (i.e., they should be followed). For example, rule 8.10 requires use of int or unsigned