MISRA C & AUTOSAR C++: Coding Standard Compliance Tools

MISRA C and MISRA C++ are guideline sets for writing C and C++ that behaves predictably in critical systems. AUTOSAR C++14 was the automotive C++ guideline set built on top of MISRA C++:2008, and AUTOSAR has since handed that work to MISRA. Adopting the guidelines is only half the job. MISRA publishes a separate document, MISRA Compliance:2020, that defines what a compliance claim actually means, what evidence a supplier owes an acquirer, and what a static analysis tool has to be able to do before you may credit it with checking a guideline.

This page sets out what the guideline documents say, which clauses of MISRA Compliance:2020 bear on tool selection and verification, and how the toolchain GSAS Micro Systems carries maps onto those specific obligations. Every clause, section and guideline count cited below comes from the MISRA and AUTOSAR documents themselves. Tool capabilities and certifications are attributed to the vendor that publishes them.

Which document applies to your project

MISRA C editions and current status

MISRA lists five editions of MISRA C on its own MISRA C page, with the following publication dates.

Edition	Published
MISRA C:1998	1998
MISRA C:2004	2004
MISRA C:2012	18 March 2013
MISRA C:2023	April 2023
MISRA C:2025	March 2025

MISRA describes MISRA C:2023 as work that “consolidates the work over the previous years, and extends support to the C11 and C18 versions of the language whilst maintaining guidelines for the earlier standards”. Its product page describes it as the third edition, second revision, which incorporates the text of Amendments 2, 3 and 4 together with Technical Corrigendum 2, and which “supersedes all previous versions of the MISRA C document (published in 2019, 2012, 2004 and 1998)”.

Two points matter for teams still specifying MISRA C:2023 in a development interface agreement. First, MISRA now marks it superseded: the MISRA C:2023 product page carries the notice “This document is no longer current but is retained in case older projects need it. MISRA C:2025 is the latest version.” Second, MISRA describes MISRA C:2025 as “an incremental update to the guidance, maintaining support to the C11 and C18 (and earlier) versions”, so the migration is a re-baselining exercise rather than a rewrite.

Of the incremental amendments, only Amendment 3 (October 2022) publishes its own delta. Its Foreword states that it “adds one new directive and twenty-three new rules, as well as revising a number of existing guidelines and supporting material”.

The structure of MISRA C:2025

MISRA does not publish a headline guideline count. What it does publish is a complete guideline-by-guideline table in MISRA C:2025 Addendum 6, section 3. That table lists 22 directives and 201 rules, and it classifies each one:

• By category: 22 Mandatory, 152 Required and 49 Advisory. All 22 Mandatory guidelines are rules. There are no Mandatory directives, which split 14 Required and 8 Advisory.
• By decidability: of the 201 rules, 150 are Decidable and 51 are Undecidable. Directives carry no decidability classification.

That same table shows the numbering is not stable across editions. Former Rule 21.2 now appears as R.5.10, where the addendum’s comment column records “Previously Rule 21.2”, and Rules 1.2, 11.7, 17.6, 21.1 and 21.2 are absent from the MISRA C:2025 numbering entirely. Any tool configuration, deviation record or guideline enforcement plan written against an older edition has to be re-mapped rather than copied forward.

MISRA C++:2008 and MISRA C++:2023

MISRA C++:2008 “was published and officially launched on 5 June 2008”, according to the MISRA C++ page. Its successor, MISRA C++:2023, is titled “Guidelines for the use C++:17 in critical systems”, was published in October 2023, and targets ISO/IEC 14882:2017, that is C++17. Like MISRA C, it contains both directives and rules.

AUTOSAR C++14 and its handover to MISRA

AUTOSAR C++14 targets C++14 as defined by ISO/IEC 14882:2014 (section 3, Scope), and it is explicitly a delta on MISRA C++:2008 rather than a standalone document. Section 2.1 of the AUTOSAR document states that “As a result, MISRA C++:2008 requires an update. This document is therefore an add-on on MISRA and it specifies: 1. which MISRA rules are obsolete and do not need to be followed; 2. a number of updated MISRA rules (for rules that only needed some improvements); 3. several additional rules.” Section 5.1.1 puts it plainly: “The rules in this document are defined as a ‘delta’ to MISRA C++:2008.”

Counted from the rule definitions in chapter 6 of the document, AUTOSAR C++14 contains 397 rules. 253 are AUTOSAR-authored “A” rules and 144 are “M” rules adopted from MISRA C++:2008. The obligation split is 362 required and 35 advisory. Unlike MISRA C, AUTOSAR C++14 has no Mandatory category. Section 5.1.2 defines required rules as “mandatory requirements placed on the code. C++ code that is claimed to conform to AUTOSAR C++14 shall comply with every ‘Required’ rule. Formal deviations must be raised where this is not the case”, while advisory rules “do not have the mandatory status of ‘Required’ rules” and “Formal deviations are not necessary for ‘Advisory’ rules, but may be raised if it is considered appropriate.”

AUTOSAR C++14 also classifies every rule twice more, which is useful when building an enforcement plan. Sections 5.1.3 and 5.1.4 classify each rule by static-analysis enforceability (automated, partially automated or non-automated) and by allocated target (implementation, verification, toolchain or infrastructure). The document notes that “Most of the rules are automatically enforceable by a static analysis” and that “The compliance to all rules that are not ‘enforceable by static analysis’ shall be ensured by means of manual activities like review, analyses.” Per section 5.2, the rules are organised to mirror the structure of ISO/IEC 14882:2014.

The critical planning fact is that AUTOSAR C++14 is closed. Section 3 of the AUTOSAR document states: “This specification is obsolete and will be removed from the standard in an upcoming release. The work has been handed over to MISRA and will no longer be maintained by AUTOSAR.” The document change history shows it was “Marked the specification as obsolete” at release 18-10 (31 October 2018), with the obsolete statement added at release 19-03 (29 March 2019). That 19-03 document is the final release. Teams starting new C++ work should evaluate MISRA C++:2023 rather than adopting a guideline set its own authors have retired.

How MISRA classifies each guideline

The four classification axes below drive everything downstream: which guidelines a tool can settle, which need a human, and which may be deviated.

Rules and directives. Per MISRA Compliance:2020 section 3.1, “The MISRA C:2012 Guidelines introduced a system of classification under which a guideline is described as either a rule or a directive.” A rule “imposes requirements on the source code which are complete, objective, unambiguous and independent of any process, design-documentation or functional requirement”. A directive “is not defined with reference to the source code alone. Analysis tools may be able to assist in checking compliance, but a directive will also refer to, or impose requirements on processes, documentation or functional requirements.” Directives therefore always carry a process or documentation obligation that no tool discharges on its own.

Analysis scope. Section 3.2 states that “The analysis scope of each MISRA rule is described as either ‘Single Translation Unit’ or ‘System’.” System-scope rules cannot be settled by looking at one source file, which is the reason the tooling clause later insists on whole-program analysis.

Category. Section 5 defines the three categories: Mandatory guidelines are those “for which violation is never permitted”; Required guidelines “can only be violated when supported by a deviation defining a set of clear restrictions, requirements and precautions”; Advisory guidelines are “Recommendations to be followed as far as is reasonably practical. Violations are identified but are not required to be supported by a deviation.” The Mandatory category was introduced by MISRA C:2012.

Decidability. Section 3.5 defines a rule as decidable “if it is always possible to answer the compliance question with an unequivocal ‘Yes’ or ‘No’ answer”, and undecidable “if an analysis tool cannot guarantee to respond to the compliance question with a ‘Yes’ or a ‘No’ in every situation”. The same section explains why this drives tool selection: “Tools vary widely in their capability to diagnose non-compliance to undecidable rules. What is important is the degree to which a tool is successful in distinguishing and reporting definite violations as well as possible violations, thereby managing to avoid both false positives and false negatives.”

What a credible compliance claim requires

MISRA Compliance:2020 is not optional guidance. The MISRA Compliance page states that it “supersedes the compliance, deviation and process requirements published previously in the various MISRA C and MISRA C++ guidelines, and forms a Mandatory reference to MISRA C:2023 and MISRA C++:2023 (and any subsequent updates)”, and that “a credible claim of compliance with MISRA C and MISRA C++ guidelines can only be made when code is developed under a process which meets the principles laid out in the MISRA Compliance document”.

Compliance is claimed per project, not per organisation. Section 4.1 is explicit: “Compliance cannot be claimed for an organization, only for a project, and it is important to establish agreed processes and acceptance criteria at the outset of the project.” A company cannot be MISRA compliant. A project can.

Guideline enforcement plan (GEP). Section 3.3 requires that “A guideline enforcement plan (GEP) listing each guideline within The Guidelines shall be produced to indicate how compliance with the guidelines is to be checked.” For every tool named in the plan, the same section requires four supporting records: the tool version; the data and/or configuration files used by the tool; any options used when invoking the tool; and evidence proving that the tool is able to detect violations of the guidelines it is credited with checking. Details of any manual process in the plan must also be recorded. That last item is the one teams most often miss, and it is why “our analyser supports MISRA” is not by itself an acceptable answer to an assessor.

Deviation records. Section 4.2 requires five items in a deviation record: the guideline or guidelines being violated; a concise description of the circumstances in which a violation is acceptable; the reason the deviation is required; background information explaining the context and the language issues; and a set of requirements including any risk assessment procedures and precautions that must be observed.

Deviation permits. Section 4.3 distinguishes these from records: “A deviation permit is not the same as a deviation record but it can supply much of the material which is required in a deviation record.” Permits define an approved use case, and may be published by MISRA, produced by the acquirer or produced by the supplier.

Justifying a deviation. Section 4.4 lists the circumstances in which deviations must not be permitted: “Simply to satisfy the convenience of the developer; When a reasonable alternative coding strategy would make the need for a violation unnecessary; Without considering the wider consequences of a particular violation on other guidelines; Without the support of a suitable process; Without the consent of a designated technical authority.” A proposed deviation may be approved only on one of four stated reasons: code quality, access to hardware, adopted code integration, or non-compliant adopted code.

Guideline re-categorization plan (GRP). Section 5.1 requires that “At the outset of a development project, the acquirer and supplier shall agree a guideline re-categorization plan (GRP) to determine how The Guidelines are to be applied.” The GRP introduces a fourth category, Disapplied. Movement between categories is constrained: “A Mandatory guideline may not be re-categorized in any way” and “A Required guideline may not be re-categorized as Advisory or Disapplied”. Required may be raised to Mandatory. Advisory may be raised to Required or Mandatory, or lowered to Disapplied.

Guideline compliance summary (GCS). The end artefact is not a “compliance report”. Section 7.3 requires that “At the conclusion of a project, a guideline compliance summary (GCS) shall be produced to record the final compliance level claimed by a project in its totality.” Four levels may be claimed per guideline: Compliant, Deviations, Violations and Disapplied. What may be claimed depends on category: Mandatory guidelines may only be claimed Compliant; Required may be claimed Compliant or Deviations; Advisory may be claimed at any of the four levels.

Project delivery. Section 7.4 lists the artefacts the supplier must make available to the acquirer on completion: the guideline enforcement plan; the guideline compliance summary; details of all approved deviation permits, if used; and deviation records covering all violations of guidelines re-categorized as Required.

Staff competence. Section 7.1 adds a requirement teams rarely plan for: “The supplier shall maintain staff competence records to allow an acquirer to confirm that the staff responsible for the project’s MISRA-related activities have the relevant skills and experience.”

What MISRA Compliance says about tools

Five clauses in section 2.6 set the tooling bar, and they are the clauses that should drive a tool decision.

Static analysis is effectively unavoidable, and it must be whole-program. Section 2.6.2 states that “any realistic process for checking code against them will therefore involve the use of at least one static analysis tool” and that “it is essential that the tool is capable of performing checks across the whole program, and not only within a single source file”. The same section rules out the perfect tool: “it is not, and never will be, possible to produce a static analysis tool that meets this ideal behaviour” of zero false negatives and zero false positives, and notes “it might be necessary to use more than one tool in order to maximize the coverage of issues”.

Compilers may be validated with a conformance test suite. Section 2.6.1 says confirmation of conformance “should be supplied by the compiler developer, for example by providing details of the conformance tests that were run and the results that were obtained”, and where that is not available it endorses “Performing and documenting independent validation testing, e.g. by using a conformance test suite or by compiling existing applications”.

Some process standards require tool qualification. Section 2.6.3 carries the only cross-standard statement this page makes: “some process standards, including IEC 61508 [6], ISO 26262 [7] and DO-178 [10], require the qualification of compilers and static analysis tools in some situations.” For the clause-level detail of those standards, see the dedicated pages linked at the end.

Both the compiler and the analyser must be configured for the real target. Section 2.6.4 requires that “If the compiler provides a choice between language version, it must be configured for the variant being used on the project. Similarly, if the compiler provides a choice of targets, it must be configured for the correct variant of the selected target.” Section 2.6.5 extends this to the analyser: “It is therefore important to configure each static analysis tool to reflect the implementation decisions made by the compiler. For example, static analysers need to know the sizes of the integer types.”

Metrics are recommended, thresholds are yours to set. Section 2.5 states that MISRA “does not offer any guidance on software metrics” because thresholds “will be determined by the industry, organization and/or the nature of the project”, while also noting that “The use of tools to collect metrics data is highly recommended. Many of the static analysis tools that may be used to enforce MISRA Guidelines also have the capability to produce metrics data.” Any specific complexity threshold on your project is a project decision, not a MISRA requirement.

The Standard Library is treated separately. Section 6.6 states that “As it is part of the implementation, and its functionality and interface are defined in The Standard, Standard Library code is not required to comply with MISRA Guidelines”, but adds that “guidelines that rely on the interface provided by standard header declarations and macros are still applicable”, and that “Where a project decides it is of benefit, The Standard Library may be treated in exactly the same way as any other piece of adopted code.” Section 6.1 lists adopted code sources as the Standard Library, device driver files, middleware, third party libraries, automatically generated code and legacy code.

Mapping the GSAS toolchain to the obligations

GSAS Micro Systems is an engineering partner for the vendors below. The table maps each tool to the specific clause it helps satisfy rather than asserting that one tool is better than another.

Obligation in MISRA Compliance:2020	GSAS-carried tool	What it addresses
Section 3.3, a GEP naming a checking tool per guideline, with tool version, configuration, options and detection evidence	Perforce Helix QAC, Perforce Klocwork	Per-guideline enforcement mapping and the tool records the GEP has to carry
Section 2.6.2, whole-program checking, and possibly more than one tool	Helix QAC, Klocwork	System-scope rules (section 3.2) cannot be settled from a single translation unit
Section 2.6.3, qualification of compilers and static analysis tools under IEC 61508, ISO 26262 and DO-178	Helix QAC, Klocwork	Perforce lists TUV SUD certification for both tools, plus a DO-330 Tool Qualification Pack for Helix QAC
Section 2.6.1, independent validation of the compiler, for example with a conformance test suite	Solid Sands SuperTest, SuperTest Qualification Suite	Conformance testing of the C and C++ compiler against the ISO language standard, and qualification packaging
Section 6.6, Standard Library exempt from the guidelines but its interface in scope, and treatable as adopted code	Solid Sands SuperGuard	Qualification of the C and C++ standard library layer
Section 2.6.5, configuring the analyser to reflect the compiler’s implementation decisions, including integer type sizes	Arm Compiler 6, Arm Compiler for Embedded FuSa plus GSAS field application engineers	Aligning analyser configuration with the actual toolchain and target variant
Section 2.5, tool-collected metrics recommended, thresholds set by the project	Helix QAC, Klocwork	Metrics collection alongside guideline enforcement, with thresholds left to the project
Not covered by MISRA Compliance at all: dynamic verification and structural coverage	Razorcat TESSY, Razorcat CTE	Unit, module and integration testing with coverage measurement, and systematic test case design

Helix QAC and Klocwork: the sourced distinction

Both tools come from Perforce and both are available through GSAS. The honest, sourced difference between them is edition currency, taken from Perforce’s own product pages.

	Perforce Helix QAC	Perforce Klocwork
MISRA C editions listed	MISRA C:2004, MISRA C:2012 (all amendments), MISRA C:2023, MISRA C:2025	MISRA C 2004, MISRA C 2012, MISRA C 2023
MISRA C++ and AUTOSAR listed	MISRA C++:2008, MISRA C++:2023, AUTOSAR C++14	MISRA C++ 2008, AUTOSAR C++ 14
Other standards listed	Barr-C, JSF AV C++, HIC++, CERT, CWE, CWE Top 25, ISO/IEC TS 17961	HKMC, JSF AV C++, CWE, OWASP, CERT, PCI DSS, DISA STIG, ISO/IEC TS 17961
Functional safety certification listed	TUV SUD certified for ISO 26262 to ASIL D, IEC 61508 to SIL 4, EN 50716 to SW-SIL 4, IEC 62304 to Software Safety Class C, and IEC 60880; plus ISO 9001 and ISO 27001; plus a DO-330 Tool Qualification Pack for DO-178C and DO-278	TUV SUD certified for ISO 26262 to ASIL D, IEC 61508 to SIL 4, EN 50716 to SW-SIL 4, IEC 62304 to Software Safety Class C

Read practically: if your project is being written against the newest MISRA editions, Perforce lists MISRA C:2025 and MISRA C++:2023 support for Helix QAC and does not list them for Klocwork, whose published list stops at MISRA C:2023, MISRA C++:2008 and AUTOSAR C++14. Klocwork’s published breadth is in multi-language security and DevSecOps standards and in CI/CD gating. If a superlative is wanted, take it from the vendor rather than from us: Perforce says its “safety experts actively shape MISRA and Rust standards” and that Helix QAC is “backed by experts who actively participate in MISRA C/C++ and Rust standards committees”.

Note on naming: Helix QAC is the current name for the product previously sold as PRQA QA-C and QA-C++, and Perforce also markets it as Perforce QAC. It is one static analysis product lineage, not two separate tools, and it is not a version control system.

Undecidable rules are where tools actually differ

Section 3.5 is candid that no tool settles every undecidable rule, and that “Tools vary widely in their capability”. With 51 of the 201 MISRA C:2025 rules classified Undecidable in MISRA’s Addendum 6 table, roughly a quarter of the rule set is territory where the analyser reports possible violations and a competent engineer has to adjudicate them. That adjudication load, not a coverage percentage, is what determines how much effort a MISRA programme costs. It is also why section 3.3 asks for evidence that a tool can detect what it is credited with, rather than a vendor’s assertion.

MISRA compliance is not dynamic verification

MISRA Compliance:2020 contains no structural coverage requirement and no unit test requirement. Guideline conformance says nothing about whether the code does the right thing. Where a project also has to demonstrate dynamic verification, that is a separate toolchain: Razorcat TESSY performs unit, module and integration testing for embedded C and C++ with C0, C1, decision, MC/DC and MCC coverage, and Razorcat CTE supports systematic test case design using the Classification Tree Method.

Frequently asked questions

Should a new project adopt MISRA C:2023 or MISRA C:2025?

MISRA’s own product page for MISRA C:2023 states “This document is no longer current but is retained in case older projects need it. MISRA C:2025 is the latest version.” MISRA describes MISRA C:2025 as an incremental update maintaining support for C11, C18 and earlier. For a new project, MISRA C:2025 is the current document. Where a contract already names MISRA C:2023, note that guideline numbering changed between editions, so tool configurations, deviation records and the guideline enforcement plan need re-mapping rather than copying.

Is AUTOSAR C++14 still maintained?

No. The AUTOSAR C++14 Guidelines document states: “This specification is obsolete and will be removed from the standard in an upcoming release. The work has been handed over to MISRA and will no longer be maintained by AUTOSAR.” It was marked obsolete at release 18-10 and the obsolete statement was added at release 19-03. Existing programmes built on AUTOSAR C++14 remain checkable, and both Helix QAC and Klocwork list AUTOSAR C++14 support, but new C++ work should evaluate MISRA C++:2023, which targets C++17.

What is the difference between a rule and a directive?

Per MISRA Compliance:2020 section 3.1, a rule “imposes requirements on the source code which are complete, objective, unambiguous and independent of any process, design-documentation or functional requirement”, so analysis tools can check it, subject to the decidability limits in section 3.5. A directive “is not defined with reference to the source code alone” and “will also refer to, or impose requirements on processes, documentation or functional requirements”. Directives always carry a process or documentation obligation, which is why the guideline enforcement plan in section 3.3 has a manual review column as well as tool columns.

Can a company be MISRA certified?

No. MISRA Compliance:2020 section 4.1 states that “Compliance cannot be claimed for an organization, only for a project”. The same document provides no route to a MISRA certification of a tool either: section 2.6.3 places the burden on the tool supplier’s validation activity and, failing that, on the developer, since “the onus is on the developer to ensure that the tools are of adequate quality.” Tool vendors may hold certification from an independent assessor, which is what Perforce’s TUV SUD certification for Helix QAC and Klocwork is, but that is a different thing from a tool being “MISRA certified”.

What do we have to hand over at the end of the project?

MISRA Compliance:2020 section 7.4 lists four artefacts the supplier makes available to the acquirer: the guideline enforcement plan; the guideline compliance summary; details of all approved deviation permits, if used; and deviation records covering all violations of guidelines re-categorized as Required. Section 7.1 separately requires staff competence records. Note that the closing artefact is a guideline compliance summary recording a compliance level per guideline, not a free-form compliance report.

Does the Standard Library have to be MISRA compliant?

No. Section 6.6 states that “Standard Library code is not required to comply with MISRA Guidelines”, because it is part of the implementation. Two qualifications apply. Guidelines “that rely on the interface provided by standard header declarations and macros are still applicable”, and a project may choose to treat the Standard Library “in exactly the same way as any other piece of adopted code”. Where a project takes that second route, library qualification tooling such as Solid Sands SuperGuard is the practical answer.

Does MISRA compliance mean the software is free of defects?

No. MISRA guidelines constrain the use of the language. They do not address functional correctness, and MISRA Compliance:2020 sets no structural coverage or testing requirement at all. Section 2.6.2 also states that a static analysis tool with zero false positives and zero false negatives is not achievable. Guideline conformance is one layer, alongside compiler and library qualification, dynamic testing with structural coverage, integration testing and review.

MISRA and AUTOSAR support across India

GSAS Micro Systems works with 25 technology partners. Four of them carry the tooling this page describes: Perforce for static analysis, Solid Sands for compiler and library qualification, Razorcat for dynamic testing, and Arm for the embedded toolchain the analyser has to be configured against.

The layer teams in India most often find missing is not the analyser. It is everything section 2.6 asks for around the analyser: a compiler validated against the ISO language standard, an analyser configured to that compiler’s actual integer type sizes and target variant, and the records in section 3.3 that prove the tool detects what the guideline enforcement plan credits it with. GSAS field application engineers work on that layer directly, which is why the Solid Sands compiler and library qualification tooling sits alongside the Perforce analysers in our portfolio rather than being treated as an afterthought.

GSAS operates 11 physical offices in India, with engineering and support presence in Bengaluru, Hyderabad, Chennai, Pune, Mumbai and Delhi NCR, alongside Coimbatore, Vadodara and Visakhapatnam. Teams we support on coding standard programmes work in automotive Tier-1 and OEM software, industrial controls, medical devices, avionics and rail. Engineers in Bengaluru, Pune and Chennai can run a proof of concept on your own codebase, and teams in Hyderabad, Mumbai and Delhi NCR can work through guideline enforcement plan and deviation process design with your quality group.

Talk to a compliance specialist

---

Related compliance pages: ISO 26262 Automotive Safety | IEC 61508 Industrial Safety | DO-178C Aerospace | UNECE R155/R156 Cybersecurity

Related solutions: Automotive Solutions | Testing and Validation