Developing software for safety-critical environments leaves no room for ambiguous, undefined, or error-prone language features.
In sectors like automotive, industrial automation, and healthcare, writing C or C++ code requires strict adherence to standardized safe programming subsets to protect system reliability and user safety.
The guidelines established by the Motor Industry Software Reliability Association (MISRA) serve as the primary framework for:
- Eliminating dangerous language constructs
- Protecting against software failures
- Maintaining codebase clarity over a device’s long operational lifespan
While MISRA compliance is often seen as a steep operational hurdle, establishing an automated workflow makes continuous safety verification seamless.
Achieving compliance involves understanding standard updates, integrating automated checks into development pipelines, maintaining audit-ready documentation, and meeting industry-specific regulatory standards.
Understanding the Standards, Rule Structure, and AI Code
MISRA guidelines are organized into distinct categories to reflect their necessity.
Rules are categorized as Mandatory, Required, or Advisory, along with a Disapplied label for guidelines MISRA no longer expects compliance with. Crucially, guidelines are also distinguished by whether they are decidable or undecidable.
Decidable rules can be assessed by automated static analysis, while undecidable rules always need manual review. A small number of MISRA rules require human judgement and cannot be verified by static analysis, such as rules regarding design intent or documentation practices.
MISRA documentation identifies which rules these are, and teams address them through code review processes alongside automated checks. This is why tool vendors evaluate automated capabilities on covering 100% of automatically testable rules rather than 100% of everything.
Static analysis tools must support current standards, including MISRA C:2025 and MISRA C++:2023, rather than relying exclusively on legacy editions.
MISRA C:2025 introduces key targeted refinements, adding four new rules covering pointer handling, union access, include guards, and tentative definitions, while updating thirteen existing rules for improved usability. This update also formally disapplies the single point of exit rule.
The change with the widest reach addresses code provenance. MISRA C:2025 explicitly establishes that AI-generated code must comply with the exact same rules as handwritten code.
When using coding assistants, provenance ceases to be a separate category. The Axivion MISRA Checker analyses all C and C++ code in a project regardless of how it was produced, and enforces this consistently across the entire codebase on every run.
Managing Rule Deviations for Independent Audits
Deviations are a normal part of engineering safety-critical systems, not an admission of structural failure. Hardware constraints, legacy code, or compiler limitations frequently require exceptions to specific rules.
What auditors evaluate is whether every exception is properly documented, justified, and tracked.
Every deviation must record the exact rule, justify the exception, include a risk assessment confirming safety is maintained, define its scope as global or local, and carry formal sign-off from authorized personnel.
Final project documentation must evidence four core artifacts for each exception:
- The deviated rule
- The rationale
- The risk assessment
- The authorization record
Managing these records manually adds significant administrative friction.
With Axivion, deviations can be specified inline in the code or managed centrally in external deviation files. Each deviation is recorded with a rationale, stays traceable, and is automatically included in the generated compliance reports, giving a complete auditable record without manual overhead.
Navigating Functional Safety and Regulatory Requirements
Compliance with MISRA guidelines is regularly required across the embedded sector, particularly where functional safety applies. In regulated industries, static analysis forms a foundational pillar of software certification.
Automotive (ISO 26262)
ISO 26262 classifies safety requirements from Automotive Safety Integrity Level (ASIL) A through D. Compliance requires running a full functional safety lifecycle, including:
- Coding standards: adopt MISRA C/C++ as your coding standard
- Static and dynamic analysis, with Axivion covering MISRA, CERT, and CWE in a single pass
- Bidirectional requirements traceability between code and safety requirements
- 100% branch coverage at ASIL D
- Toolchain qualification
- Automated report generation
Medical Devices (IEC 62304)
Categorizing software into Class A, B, or C based on potential severity of harm, IEC 62304 compliance aligns with US FDA and EU MDR requirements.
Adopting MISRA guidelines protects patient safety, and ensures maintainability across a device’s long operational lifespan.
Choosing Static Analysis Capabilities
Selecting a static analysis tool comes down to standard coverage, workflow efficiency, and certification overhead. Low-cost or partial-coverage options often require manual effort to fill compliance gaps, resulting in higher overall project costs.
Axivion Suite covers 100% of the automatically testable MISRA C and C++ rules across all current standard editions, including MISRA C:2025 and MISRA C++:2023. It offers built-in delta analysis for CI/CD pipelines, manages deviation tracking, and holds SGS-TÜV Saar certification up to ASIL D, SIL 4, and IEC 62304 Class C.
Axivion capabilities can be licensed standalone within the Axivion Static Code Analysis package or integrated as part of the broader Axivion Suite, giving teams a direct path toward automated functional safety compliance.
