The MISRA consortium has been in existence since the early 1990s, initially as a collaboration of the UK’s automotive industry, and resulting in the 1994 publication of the Development guidelines for vehicle-based software.
Subsequently, a collaboration led by the Ford and Rover motor companies, who decided to combine their efforts to create a create a C language subset – or coding standard, as they are known colloquially – led to the creation of MISRA C, the Guidelines for the use of the C language in vehicle-based systems.
LDRA have been active contributors to the MISRA working groups since shortly after their inception. Support for MISRA coding Guidelines in LDRA’s tools has always reflected that commitment and continues to do so today.
In any high-level language, there are hundreds of instructions and constructs. Some of them are very easy to get wrong (especially in C and C++) so coding standards were introduced to disallow the use of those error-prone functions and hence make the resulting code more likely to be error free. First released in 1998, MISRA C is one of a group of documents known collectively as coding standards – although the MISRA consortium itself always refers to them as “Guidelines”.
The MISRA Consortium consists of a group of likeminded individuals. As a collective, they offer guidance in developing embedded software associated with safety- and security-related electronic systems, and standalone software. Compliance with MISRA Guidelines helps developers to produce code that is robust, maintainable, and more portable.
Working group members are now drawn from industries and consultants across the safety-related embedded systems world, including the automotive sector. LDRA have active representatives on several of those working groups, including the chairpersons of MISRA C and MISRA C++ working groups.
Originally, MISRA was an acronym for the “Motor Industry Software Reliability Association”. That expansion is no longer used because “MISRA” no longer implies “automotive industry”. MISRA Guidelines are used in many other sectors too, and so the “Motor Industry” part of the acronym has become misleading over time.
The thread that runs through all LDRA tool, service, and consultancy offerings is the firm belief that well-written software is safer, more secure, and more reliable. That simple premise aligns perfectly with MISRA’s stated aim of “providing best practice guidelines for the safe and secure application of both embedded control systems and standalone software.”
It is that commonality of purpose that has driven LDRA to be part of MISRA for almost 25 years. The mutual benefit is that MISRA gains from LDRA’s long-standing expertise in the field, and LDRA can deliver up-to-the-minute support for the evolving MISRA editions that is second to none.
That tradition continues up until today. Andrew Banks is a Technical Specialist with LDRA and a long standing member of the MISRA working groups. He has been involved with MISRA since 2007 and has been Chairman of the MISRA C Working Group since early 2013.
LDRA are also represented on the MISRA C++ Working Group by Jim Hanson, Jim is a Lead Developer with LDRA with over 25 years’ experience in the industry. He has a keen interest in the development of the C++ language and how the changes to the language impact on testing and verification.
Andrew’s and Jim’s ongoing efforts continue a proud LDRA tradition of not only supporting the industry but leading it, too.
Andrew Banks
The answer to this question is very clear. There is no such thing! MISRA never calls their documents “Standards”, and only ever refer to them as “Guidelines” or “Coding Guidelines”. That said, many people do refer to them as standards, perhaps because they are part of a group of documents that are generally referred to as coding standards.
The terms “Guidelines” or “Coding Guidelines” can therefore refer to both MISRA C and C++ documents, one of those documents, or two or more of the Rules and/or Directives contained within those documents.
Although this may seem confusing, the context of the use of the word usually makes the meaning clear.
MISRA Guidelines are applicable to all critical systems. Whether a system is safety-critical, mission-critical, or security-critical, it must operate reliably under all defined conditions, avoid undefined behaviour, and remain robust in the face of unexpected inputs or states.
MISRA’s focus on eliminating ambiguous, error-prone, or non-portable language constructs directly supports these goals. In cybersecurity, this reduces the attack surface; in functional safety, it minimizes the risk of hazardous failures; and in mission-critical systems, it ensures consistent operation under stress.
Compliance with MISRA Guidelines helps to:
A Rule is a Guideline for which a complete description of the requirement has been provided. It should be possible to check that source code complies with each of the Rules without needing more information, and for static analysis tools to check those Rules (subject to some provisos).
A Directive is a Guideline for which it is not possible to provide the full description necessary to perform a check for compliance.
The number of Rules and Directives for each language varies in each edition
For example, MISRA C:2025 has:
Complete compliance matrices are available for MISRA C and MISRA C++. They detail all the coding Rules, and which ones are supported by LDRA’s MISRA C and MISRA C++ tools respectively.
MISRA rules have long been categorised, with “Advisory” and “Required” categories having been joined more recently by “Mandatory” and “Disapplied”. These can be described as follows
| Category | Meaning | Deviation policy |
|---|---|---|
| Mandatory | Must be followed without exception. | No deviation allowed. Must be satisfied. |
| Required | Must be followed unless there are exceptional circumstances | Must be followed unless there are exceptional circumstances |
| Advisory | Should be followed. Deviation is acceptable with minimal justification | Deviation is permitted with formal justification Requires documented and reviewed deviation. |
| Dissapplied | No enforcement | n/a |
For MISRA C:2025, the Guidelines are categorized as follows:
“Decidable” MISRA rules are those that can be assessed by means of automated static analysis. Conversely, “Undecidable” rules describe violations for which manual review is always necessary.
Although all “Decidable” rules are theoretically decidable, it does not follow that all compliance checkers can check all “Decidable” rules. For example, the more sophisticated tool suites are capable of system wide analysis (analogous to the work of a linker) whereas inferior tools offer only translation unit analysis (analogous to the compiler).
Historically, most embedded software developers leveraging these coding guidelines have done so as part of a safety critical development process, but they are equally applicable to other critical software development work – including where security is important.
MISRA’s name no longer includes reference to the automotive industry, reflecting the fact that MISRA has gained acceptance in many other sectors including aerospace, medical devices, financial, IoT, and industrial control systems (IIoT).
For example, companies from the industrial & energy, medical device, and automotive sectors have all used LDRA MISRA checkers to ensure that the Guidelines are complied with.
The body of MISRA’s work consists primarily of MISRA Guidelines and Compliance Guidance documents. The latest versions of MISRA C, MISRA C++, MISRA Compliance, and the supporting documents for automatically generated code (AC) are of primary interest.
March 2023 saw the introduction of MISRA C:2012 Amendment 4 (AMD4). It specifies Rules and Directives for multithreading and atomic types as well as clarifications on existing guidance to better align with how developers use the C language today.
It also saw the announcement of MISRA C:2023 which was a major update to the outgoing MISRA C:2012. It consolidated the previous versions of the Guidelines, amendments (including AMD4), and addenda into a single, comprehensive edition to facilitate compliance.
MISRA C:2025 was released two years later. Although a less substantive update than its predecessor, it built on the efficiency of MISRA C:2023 with significant policy changes, enhancements, and new Guidelines to further simplify the process of developing reliable and robust safety- and security-critical code. In addition, MISRA C:2025 lays the foundation for supporting the next revision to the C standard.
LDRA has continued its tradition of up-to-date support for MISRA Guidelines with the addition of MISRA C:2025 to the static code analysis and reporting capabilities of its tools.
In accordance with its announcement in January 2019, work to merge the MISRA C++ and AUTOSAR C++ Guidelines has now been completed in the form of MISRA C++:2023, which was released in October 2023. This integrated document represents a single “go to” language subset for use with safety-related C++ development processes. It remains applicable to the automotive sectors and other sectors alike.
LDRA were represented on the MISRA C++ working group throughout the development of this edition, and an LDRA representative chaired the group for a large majority of that time. That in-depth knowledge is reflected in LDRA’s support for the document.
The MISRA AC documents deal with the application of MISRA Guidelines to Automatically Generated Code.
MISRA AC AGC “Guidelines for the application of MISRA-C:2004 in the context of automatic code generation” was the core document in a set of five and was complementary to MISRA C:2004. Its guidance was integrated into the MISRA C Guidelines from MISRA C:2012 onwards.
The remaining four documents are therefore complementary to MISRA C. They are not language specific because they are focused on the model rather than the code generated from it:
Ask most MISRA newcomers to comply with MISRA C:2025 or MISRA C++:2023, and it’s likely that they’ll turn straight to the similarly named Guidelines documents. But in fact, the key to complying with either of them lies with their less famous sibling – MISRA Compliance:2020.
This document prescribes the required strategy for demonstrating compliance with MISRA Guidelines. It defines the processes, documentation, and artifacts required to justify compliance, including the Guideline Enforcement Plan (GEP), Guideline Compliance Summary (GCS), Deviation Records, and Deviation Permits. By standardizing compliance practices, it ensures consistency, transparency, and accountability in applying MISRA Rules.
Given that MISRA Compliance:2020 is now a mandatory framework for demonstrating compliance with MISRA C:2023 and MISRA C:2023++ Guidelines onwards, it is important to understand how the information highlighted by static analysis relates to the bigger picture of a MISRA compliant application.
Examples of MISRA Compliance principles
The following five examples typify the principles outlined in the MISRA Compliance document itself, which reflect a little technical wisdom and a lot of common sense.
This timeline illustrates how the MISRA language guidelines have evolved to meet the changing needs of developers.
| April 1998 | MISRA C:1998 “Guidelines for the use of the C language in vehicle based software” is released to target the C90 version of the C language. |
| October 2004 | MISRA-C:2004 “Guidelines for the use of the C language in critical systems” is released to address the feedback from engineers using the original version. The new title reflects the widespread uses of the document across various sectors. |
| June 2008 | MISRA C++:2008 “Guidelines for the use of the C++ language in critical systems” is released, recognizing the growing use of C++ in critical applications. |
| February 2013 | MISRA C:2012 “Guidelines for the use of the C language in critical systems” is released to address the later C99 version of the C language, while retaining backward compatibility with C90 |
| April 2016 | MISRA C:2012 – Amendment 1 “Additional Security Guidelines” is released as a free download. It details fourteen new security Guidelines to be used in conjunction with the main document. |
| June 2017 | MISRA C:2012 –Technical Corrigendum 1 “Technical clarification of MISRA C:2012” is released. It addresses issues raised since the publication of the main document and is supplemental to it. |
| February 2019 | MISRA C:2012 “Guidelines for the use of the C language in critical systems” is released in updated form to collate the contents of the original MISRA C:2012 document, Amendment 1, and Technical Corrigendum 1. |
| February 2020 | MISRA C:2012 – Amendment 2 “Updates for ISO/IEC 9899:2011/18 Core functionality” is released. It deals with the undefined, unspecified and implementation defined behaviours within C11 & C18. |
| March 2022 | MISRA C:2012 – Technical Corrigendum 2 “Technical clarification of MISRA C:2012” is released. It addresses issues raised since the publication of the third edition, first revision and is supplemental to it. |
| November 2022 | MISRA C:2012 – Amendment 3 “Updates for ISO/IEC 9899:2011/2018 Phase 2 — New C11/C18 features” is released. It deals with the new C11 & C18 features. |
| March 2023 | MISRA C:2012 – Amendment 4 “Updates for ISO/IEC 9899:2011/2018 Phase 3 — Multi-threading and Atomics” is released. It specifies Rules and Directives for multithreading and atomic types and acts on feedback to clarify some existing guidance. |
| April 2023 | MISRA C:2023 “Guidelines for the use of the C language in critical systems” is released. It collates the contents of MISRA C:2012 along with its subsequent amendments and technical corrigenda. |
| October 2023 | MISRA C++2023 ” Guidelines for the use of C++:17 in critical systems” is released. It targets the 2017 language version (C++:17) and integrates the MISRA C++ and AUTOSAR C++ Guidelines |
| March 2025 | MISRA C:2025 “Guidelines for the use of the C language in critical systems” is released. It introduces policy changes, enhancements, and new Guidelines to help simplify the process of compliant code development. It also establishes a basis for supporting the next C standard revision. |
The ability to statically analyse software efficiently with reference to MISRA Guidelines delivers tangible benefits to development teams in terms of code quality, consistency, and reduced time-to-deployment. Help is available from LDRA in the form of consultancy, training, and the MISRA tools (sometimes called “MISRA checkers”) found in the LDRA tool suite and LDRArules.
There are many rules in the MISRA Guidelines. In theory it might be possible to check by inspection that they have all been implemented, but that would be a highly skilled, labour-intensive, and error-prone job. MISRA checkers such as those provided by LDRA automate that process by means of static analysis.
Static analysis can be used to ensure MISRA compliance as code is developed, and automatically applied during unit, system, or integration test to ensure that compliance achieved at the outset is not compromised throughout the development processes associated with the software development life cycle. All versions of the MISRA Rules are completely integrated into LDRA tools for efficient MISRA checking within a familiar embedded software development environment.
LDRA static analysis tools locate and highlight areas of non-conformant code to aid documentation and modification. Extensive reports and graphical displays enhance understanding of the source code, facilitating improvements in testability, understandability, and maintainability in line with MISRA Rules. LDRA static analysis tools also facilitates structural coverage analysis to ensure that software “testedness” is measured and maintained, as recommended by the MISRA Guidelines.
The LDRA tool suite supports the creation of the four key MISRA Compliance:2020 artifacts (Guideline Enforcement Plan, Guideline Compliance Summary, Deviation Records, and Deviation Permits) and provides the option of a multi-tier coding violation exclusion option.
The pool of expertise that has developed LDRA’s tools for half a century and helps guide MISRA and other standards committees around the globe is now accessible to delegates from across the critical embedded application sectors.
LDRA has been a leader in software verification and requirements traceability tools for safety- and security-critical application development since 1975. LDRA’s experience and expertise helps guide standards committees across the world, and that same depth of knowledge provides outstanding learning opportunities for delegates across the critical embedded application sectors.
With training courses in MISRA C up to and including MISRA C:2025, LDRA’s tutors can help forge a path to help delegates to develop safe, secure, compliant application code.
System Wide and Single Translation Unit analysis
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707