What Is MISRA? The Definitive Guide to MISRA C and C++ for Indian Automotive Teams

What Is MISRA?

MISRA stands for the Motor Industry Software Reliability Association. It publishes the MISRA C and MISRA C++ coding guidelines, which restrict those languages to a safer, more predictable subset rather than changing the languages themselves. The guidelines tell you which constructs to avoid, which to prefer, and how to document an intentional departure.

Two structural facts explain most of how MISRA is used in practice. First, the guidelines are split into directives and rules, and classified Mandatory, Required or Advisory. Second, compliance is not “the tool reports zero findings”: to claim compliance, every Mandatory rule must be met and every Required rule and directive must either be met or be covered by a formal, documented deviation.

If you work in embedded software anywhere in the automotive, aerospace, medical, or industrial sectors, you have encountered MISRA. The name appears in customer requirements documents, in functional safety plans, in OEM supplier quality manuals, and in job postings for embedded engineers across India. But what exactly is MISRA, where did it come from, and why does it hold the position it does? This guide provides a comprehensive answer.

Origins: The SafeIT Programme and Automotive Roots

MISRA stands for the Motor Industry Software Reliability Association. It was established in 1994 as part of the UK government’s SafeIT programme, a collaborative initiative between the automotive industry and academia to improve the reliability of software in vehicles. The founding members recognised that the C programming language, while essential for embedded development, contained constructs and behaviours that were inherently dangerous in safety-critical contexts: undefined behaviour, implementation-defined behaviour, and constructs that were technically legal but practically hazardous.

The first MISRA C guidelines were published in 1998. They were not a language standard in the ISO sense. They were, and remain, a set of industry-consensus coding rules designed to restrict the use of C to a safer, more predictable subset. This distinction matters. MISRA guidelines do not change the C language. They tell you which parts of the language to avoid, which constructs to prefer, and how to document intentional deviations.

MISRA is a registered trademark and is governed by a consortium of automotive and technology organisations. Its guidelines are developed through a formal committee process, drawing on decades of accumulated field experience with safety-critical embedded systems.

MISRA C: From 1998 to 2025

The MISRA C guidelines have evolved through several major revisions, each reflecting changes in the C language standard and lessons learned from industry adoption.

Guideline counts per Perforce, MISRA C and C++ resource; publication dates per misra.org.uk; 1998 and 2004 rule splits per Wikipedia, MISRA C.

Directives and Rules: How the Guidelines Are Structured

The word people reach for is “the MISRA rules”, but MISRA C:2012 onward divides its guidelines into two kinds, and the difference decides what a tool can and cannot do for you.

A rule is a technical requirement that can be judged from the source code itself. Wikipedia’s summary of the MISRA C structure describes directives, by contrast, as covering matters “more open to interpretation, or [that relate] to process or procedural matters”. A directive might require that a design decision be justified in documentation, which no analyser can confirm by reading a translation unit. For compliance purposes there is no distinction: both directives and rules must be addressed.

MISRA C:2012 added two further classifications that matter operationally:

This is the practical reason a MISRA report and a MISRA compliance claim are different artefacts. The report is tool output. The claim requires someone to have dealt with the undecidable rules and the directives too.

Mandatory, Required and Advisory

Every MISRA guideline carries one of three categories, and they determine what you are allowed to do when your code breaks one.

The Mandatory category was introduced in MISRA C:2012; the 1998 and 2004 editions classified rules only as required or advisory. The practical consequence for a team migrating from MISRA C:2004 is that an existing waiver list cannot simply be carried across, because a guideline the project used to waive may now sit in a category that permits no deviation at all.

Category definitions per Wikipedia, MISRA C.

Deviations: What a Compliance Claim Actually Requires

This is the part most teams underestimate, and it is the part an OEM audit examines first. MISRA compliance is a documented position, not a build result.

The threshold is precise. To claim compliance with the MISRA C guidelines, every Mandatory rule must be met, and every Required rule and directive must either be met or be subject to a formal deviation. Advisory guidelines may be disapplied without a formal deviation, but that should still be recorded in the project documentation.

A deviation is documented either in the code or in a separate file, and it identifies the guideline being deviated from together with the rationale for deviating. A note that says only “legacy code” is not a deviation. The rationale has to explain why the departure is acceptable in this specific context.

MISRA publishes separate guidance on all of this. MISRA Compliance:2020, released in February 2020, is described by MISRA as an updated version of the guidance on complying with MISRA Coding Guidelines, “now mandatory from MISRA C:2012 Third Edition, First Revision + AMD2”. If your customer contract says “MISRA compliant” without further definition, that document is what defines the obligation, and it is worth reading before the first scan rather than after the first audit finding.

The commercial consequence for India is direct. Indian engineering services teams are usually the ones producing this documentation on behalf of a Tier 1 or OEM customer. A codebase with a low violation count and no deviation documentation will struggle in a supplier audit, while a codebase with a higher violation count and complete, reasoned deviations frequently passes.

Compliance threshold and deviation content per Wikipedia, MISRA C; MISRA Compliance:2020 description per misra.org.uk publications.

MISRA C++: From 2008 to 2023

C++ adoption in safety-critical embedded systems has grown steadily, particularly in automotive and aerospace, where the language’s abstraction capabilities offer productivity benefits if used carefully.

MISRA C++:2008 was the first edition, targeting C++03. It followed the same philosophy as MISRA C: restrict the language to a safer subset. MISRA C++:2023 is a ground-up rewrite covering C++17. It represents a modern approach to safe C++ usage in embedded systems and aligns with the AUTOSAR C++ guidelines, which were themselves derived from MISRA C++:2008. For teams operating in the AUTOSAR ecosystem, MISRA C++:2023 provides a natural migration path.

MISRA C vs MISRA C++

The choice between MISRA C and MISRA C++ is not simply about which language your project uses. MISRA C addresses the broader embedded ecosystem where C dominates: microcontrollers, real-time operating systems, bare-metal firmware, and legacy codebases. MISRA C++ targets applications where object-oriented design and modern C++ features offer genuine advantages in safety-critical contexts, such as autonomous driving software stacks and avionics middleware.

Many Indian automotive teams maintain both C and C++ codebases within the same product line. In these environments, enforcing both MISRA C and MISRA C++ with consistent tooling and deviation management processes is essential.

Why MISRA Matters Beyond Automotive

MISRA’s influence extends well beyond the automotive industry that gave it its name. The guidelines are referenced in functional safety standards across multiple domains.

The practical result is that MISRA compliance is a customer requirement in nearly every safety-critical embedded market. It is not optional. It is the cost of entry.

Enforcement: Helix QAC and Klocwork

MISRA guidelines are designed to be enforced by automated static analysis tools. Manual enforcement through code review is neither scalable nor reliable for a rule set of this size.

Helix QAC covers the MISRA editions a project is realistically claiming against. Perforce lists MISRA C:2004, MISRA C:2012 with all amendments, MISRA C:2023 and MISRA C:2025, plus MISRA C++:2008 and MISRA C++:2023, and states that QAC is TÜV SÜD certified for ISO 26262 up to ASIL D and IEC 61508 up to SIL 4. That certification is the reason its output can be used as tool-qualification evidence rather than merely as a report.

Klocwork complements QAC with defect detection and security analysis mapped to CWE and CERT C rules. Teams that need both MISRA compliance and security vulnerability detection often deploy QAC and Klocwork together, with QAC handling coding-standard enforcement and Klocwork handling interprocedural security analysis.

Note what tooling does not do. Undecidable rules and directives cannot be settled by analysis alone, so a MISRA claim always contains human judgement that has to be written down.

Coverage and certification per Perforce Helix QAC, Perforce Software.

The Indian Context

The Perforce 2026 State of Automotive Software Quality report provides data that is directly relevant to Indian embedded teams. MISRA usage increased by 8% in 2026 compared to the previous year. Sixty-one percent of automotive software teams now use MISRA guidelines. Fifty-two percent of teams comply with ISO 26262, with customer mandates identified as the primary driver of adoption.

India’s automotive engineering services sector is deeply integrated into global OEM supply chains. When Tier 1 suppliers in Germany, Japan, or the United States require MISRA compliance from their software development partners, Indian teams are on the receiving end of those requirements. Understanding MISRA, not as an abstract standard but as a practical engineering discipline with specific tools, processes, and deliverables, is essential for competitiveness.

GSAS has delivered over 50 MISRA workshops across India, covering automotive, industrial, and defence teams. These workshops go beyond tool training. They establish coding standard baselines, configure enforcement tooling to match project-specific rule profiles, define deviation management workflows, and prepare teams for OEM audits.

Start with a MISRA Baseline

If your team is beginning its MISRA journey or upgrading from an older guideline version, the most effective first step is a compliance baseline assessment. GSAS conducts baseline workshops where we analyse a representative portion of your codebase against the current MISRA C or C++ guidelines, identify the most common violation patterns, and help you build a prioritised remediation plan. Contact us to schedule a MISRA compliance baseline workshop for your team.