Embedded & safety-critical software development (MISRA, ISO 26262, IEC 62304)

Firmware for cars, machines and medical devices must be written to coding standards, traced from every requirement to code and test, and backed by verification evidence. Teams spend a large share of effort on this paperwork and on fixing rule violations. LLM assistants speed up drafting, MISRA remediation and traceability maintenance, while deterministic tools (compiler, static analyser, tests) and qualified humans remain the gate. The AI proposes; the toolchain and the safety engineer decide.

Problem & value

• Today: engineers hand-write C/C++ for resource-constrained MCUs, run MISRA checkers, fix hundreds of findings manually, maintain traceability matrices in ALM tools (ASPICE, ISO 26262-6, IEC 62304 §5) and assemble evidence for assessors. Rework late in the V-model is expensive.
• AI value: faster first drafts of components and unit tests, automated remediation of rule violations, suggestions for missing trace links, review of requirements for ambiguity, and first-draft work products (design descriptions, test specifications) that humans verify.
• Evidence: a 2025 study found that none of the tested LLMs produced MISRA C++-compliant code unprompted, but all could fix individual violations when told to [10]; Woven by Toyota reports a proof-of-concept multi-agent "MISRA Copilot" that resolved 81.5% of violations on internal code, with a human approving each fix (vendor-reported) [11]; and research pipelines use retrieval grounded in ISO 26262/ASPICE to draft test specifications from requirements [12]. Published numbers vary by setup and are not generalisable; measure on your own code base.
• Hard limit: AI output is never evidence by itself. Standards require independently verified work products and, for tools whose errors could go undetected, tool confidence or qualification (ISO 26262-8 clause 11, IEC 61508-3, DO-330).

Variants

• Automotive (ISO 26262, ASPICE, AUTOSAR Classic/Adaptive, ISO/SAE 21434): ECU software, MISRA C:2012 / C++ (MISRA C++:2023), CERT.
• Medical device software (IEC 62304, MDR/IVDR): class A–C lifecycle, risk files (ISO 14971), cybersecurity (IEC 81001-5-1).
• Industrial / machinery (IEC 61508, ISO 13849, IEC 61131-3 is in CODE-016): SIL-rated firmware, drives, sensors.
• Rail, avionics, space (EN 50128, DO-178C, ECSS): stricter objectives; AI use mostly limited to non-credited assistance.
• SMB / supplier: small teams using AI for tests, MISRA clean-up and documentation while the OEM defines the process.

How it works

1. requirements / safety goals (ALM)
2. AI-assisted refinement (ambiguity, testability, missing safety requirements)
3. code generation / modification in IDE or agent (restricted to approved templates, coding standard in prompt)
4. deterministic gates: compiler warnings-as-errors, MISRA/CERT static analysis, formal/abstract-interpretation checks
5. AI remediation loop (patch
6. re-run analyser
7. accept only if violations drop and tests pass)
8. test generation + coverage (statement/branch/MC/DC) on host and target / HIL
9. traceability update (requirement ↔ code ↔ test) with AI-suggested links
10. human review + independent verification + safety-manager sign-off
11. baseline and evidence package

• Generation: a code LLM with retrieval over the project's coding guidelines, HAL, AUTOSAR configuration and existing modules; output limited to the language subset (no dynamic allocation, no recursion, bounded loops).
• Closed loop with analysers: the analyser report is fed back to the model; a patch is only accepted if the analyser and test suite confirm it. This makes hallucinated "fixes" detectable.
• Traceability: embeddings + LLM propose links and flag orphaned requirements or untested code; humans confirm.
• Human-in-the-loop: all code review, deviation approvals (MISRA deviation records), safety analysis (FMEA/FTA/HARA) conclusions and release sign-off.

Data preparation

Preparation is moderate (roughly 25 to 35 percent of effort) and is mostly about making requirements, code and evidence machine-readable. Data lives in ALM tools (DOORS, Polarion, Jira), Git or SVN, Word and Excel requirement documents, static-analysis reports, test and coverage results and shared drives with deviation records and safety analyses. Typical gaps: requirements in documents without IDs, broken or missing traceability links, MISRA deviations recorded as free text, inconsistent tool versions and rule sets, scanned review protocols, and knowledge of the HAL or AUTOSAR configuration in a few heads.

Preparation steps: - Export requirements with stable IDs (ReqIF or API; PREP-005) and convert document-based ones into structured items (DOC-014, PREP-007). - Fix the rule set, compiler and analyser versions so results are reproducible. - Structure deviation records and review decisions as tables with rule, reason and approver (PREP-011, PREP-020). - Collect gold-standard modules and past fix patches as examples and evaluation set (PREP-016, PREP-018). - Write the coding guideline and HAL conventions as short retrievable documents (PREP-013, PREP-014). - Classify code by confidentiality and contract restrictions (PREP-024).

Use GUIDE-003 to check readiness before the pilot.

Implementation paths

Which path for whom

• enterprise: Path C — OEM contracts and export control often forbid sending safety-relevant code to clouds, shared tooling across projects justifies HW3 hosting, and the analyser-gated loop works with open-weight models.
• developer: Path B — a coding agent wired to clang-tidy, Cppcheck and tests via MCP gives a working remediation loop quickly for non-confidential code.
• smb: Path B — suppliers and device makers need project-specific MISRA and traceability pipelines that no product covers fully; use EU-region APIs with zero-retention terms and keep OEM-confidential modules out, or switch to Path C if the contract demands.

Path A — Buy (off-the-shelf)

• Assistants with safety-aware features: GitHub Copilot, Cursor, Claude Code, Kiro (successor to Amazon Q Developer), JetBrains AI used under company policy; embedded-specific vendors integrate AI into established toolchains.
• Static-analysis vendors with AI assist: Perforce Helix QAC and Klocwork, Parasoft C/C++test (AI-assisted test and fix), Synopsys Coverity, MathWorks Polyspace (Bug Finder / Code Prover), LDRA, TrustInSoft (EU), Vector Informatik (EU) with VectorCAST, Axivion (EU, Qt Group), Bosch/ETAS tooling, Siemens Polarion and Jama/Codebeamer (PTC) for ALM traceability.
• Choose A when: you want vendor-qualified tools and an auditable process; AI features are add-ons around an existing certified chain.

Path B — Build on cloud APIs (recommended)

• Frontier code models (Claude, GPT, Gemini) or EU providers (Mistral Codestral) via EU regions; orchestration with an agent framework calling your analyser, compiler, simulator and ALM APIs through MCP or scripts.
• Pattern: the model never sees unreleased safety-critical IP unless contracts and export-control rules permit; use EU region endpoints and zero-retention terms.
• Choose B when: you need a project-specific remediation or traceability pipeline and have no strict air-gap requirement.

Path C — Self-host (open source)

• Open-weight code models: Qwen3-Coder, DeepSeek-Coder family, Codestral open variants, Granite code models (IBM) served with vLLM or Ollama; IDE integration via Continue or Cline.
• Stack: clang-tidy, Cppcheck (MISRA addon), GCC/Clang warnings, Frama-C, CBMC, Unity/Ceedling or GoogleTest, Renode/QEMU simulation, Eclipse SCA tools, Sphinx-needs / StrictDoc / OpenFastTrace for traceability.
• Hardware: HW3 for 30–120B coder models for suppliers with IP or air-gap constraints; HW2 suffices for smaller models with the remediation loop.
• Choose C when: OEM contracts forbid cloud code transfer.

Path D — Custom training

Fine-tuning on your own MISRA-compliant code and past deviation decisions can improve fix quality for your dialect, compiler and HAL. Needs thousands of reviewed before/after patches; use the analyser as automated reward signal.

State of the art (2026)

• Analyser-in-the-loop agents are the working pattern: generation alone produces rule violations; verified remediation loops are far more reliable than one-shot prompts.
• Formal and bounded checks (Frama-C, CBMC, Polyspace) combine with LLM-written annotations or contracts; correctness proofs still need expert review.
• Requirements-to-test generation for ASPICE SWE.1-SWE.6 work products is an active research and vendor area [6].
• Standards in motion: MISRA C++:2023 consolidated C++ guidance; ISO/IEC TS 22440 (functional safety and AI systems) and ISO/PAS 8800 (road vehicles, safety and AI) address AI inside products, not AI as a development tool, but shape tool-confidence thinking [4].
• Limits / failure modes: subtle undefined behaviour, integer promotion errors, timing and WCET violations, wrong hardware register semantics, hallucinated HAL functions, and over-confident safety rationales. Tests on host do not prove target behaviour. LLMs are non-deterministic, which complicates tool qualification; treat them as unqualified suggestion engines whose output is verified by qualified tools.

Shared resources & combinations

• Same stack: CODE-001/002 (assistants and agents), CODE-003 (review), CODE-004 (test generation), CODE-006 (documentation), CODE-014 (bug triage), CODE-005 (modernisation of legacy C), SEC-004 (secure code scanning and auto-fix; ISO/SAE 21434 and CRA), CODE-016 (PLC code), CODE-019 (RTL/chip verification), ROBO-016 (AI inside machine safety functions).
• Shared: code LLM server (HW2/HW3), embedding index over requirements and code, CI runners with analysers, ALM integration.

Effort, cost & KPIs

• Path A: weeks to enable AI features in an existing toolchain; licence cost per seat.
• Path B: 2–4 months for a remediation and traceability pipeline plus process documentation.
• Path C/D: 4–9 months; GPU server, MLOps and safety-process integration.
• Main cost drivers: tool-confidence argumentation, assessor alignment, integration with ALM and CI, review effort.
• KPIs: MISRA violations closed per week and accepted-patch rate, review time per change, escaped defects, traceability coverage, test coverage (MC/DC where required), rework rate in late phases, assessor findings.

People & change

• Involve: management (liability, tool budget), the engineering lead as process owner, developers, testers and the safety manager as daily users, quality management and legal for ISO 26262 or IEC 62304 tool-confidence arguments and contracts, IT security for code protection, and suppliers or OEMs whose confidentiality terms limit what the model may see.
• Works council: depends. The assistant analyses code, but IDE and agent logs and per-developer acceptance metrics can monitor performance; then §87(1) no. 6 BetrVG applies. Inform the works council in good time under §90(1) no. 3 BetrVG, and consider an expert under §80(3) for a works agreement on AI tools.
• Data protection: mostly no personal data; developer identifiers in logs are the exception. Involve the DPO briefly and sign an AVV (Art. 28 GDPR) with providers. A DPIA is normally not needed.
• AI literacy: support developers with training on typical hallucinations in C/C++ and why analyser output, not the model, decides (Art. 4 AI Act as amended).
• Pilot and communication: start with MISRA remediation on a non-critical module, reviewed by a senior engineer.
• Concerns: "AI-generated code is not certifiable" — answer with the same review and verification evidence as for human code and a documented tool-use policy.
• Humans in control: deviations, safety rationale and release sign-off stay with qualified people.

See GUIDE-007, GUIDE-008 and GUIDE-014.

Risks, regulation & compliance

• EU AI Act: the development tool itself is typically minimal risk (AI literacy duty, Art. 4). The product may be high-risk: safety components of products under Annex I harmonised law (machinery, medical devices, and so on) fall under Art. 6(1); vehicles under type-approval are covered via sectoral rules. Not an Art. 5 prohibited practice.
• Sector rules: ISO 26262 (including tool confidence, part 8), ASPICE 4.0, IEC 62304 and MDR/IVDR, IEC 61508, UNECE R155/R156 for cybersecurity and updates, EU Cyber Resilience Act and the new Machinery Regulation (EU) 2023/1230 for software safety functions [2][3].
• Liability: the manufacturer remains responsible; AI suggestions need the same review as junior-engineer code.
• IP and export control: do not send proprietary or OEM-confidential code to APIs without contractual clearance; GDPR is mostly irrelevant, except developer identities and logs.
• Mitigations: analyser and test gates, independent review, no AI-generated safety rationale accepted without expert review, logged prompts and outputs, documented tool-use policy and tool-confidence evaluation, restricted code subsets.

Getting started

1. Agree an AI-use policy with the safety manager and assessor: allowed activities, tool-confidence classification, review rules.
2. Start with low-risk tasks: MISRA clean-up in non-critical modules, unit-test drafts, documentation, with analyser gating.
3. Build the closed loop (patch → static analysis → tests → human review) in CI and measure acceptance rate.
4. Add traceability suggestions in your ALM tool; track precision of suggested links.
5. Run a pilot on one component, review with your assessor, then scale.

Sources

1. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
2. Regulation (EU) 2023/1230 (Machinery Regulation) — https://eur-lex.europa.eu/eli/reg/2023/1230/oj
3. Regulation (EU) 2017/745 (MDR) — https://eur-lex.europa.eu/eli/reg/2017/745/oj
4. ISO 26262-1:2018 Road vehicles, functional safety — https://www.iso.org/standard/68383.html
5. MISRA — Guidelines and compliance resources — https://misra.org.uk/
6. Automotive SIG — Automotive SPICE process assessment model — https://vda-qmc.de/en/automotive-spice/
7. IEC 62304:2006+A1:2015 Medical device software lifecycle — https://www.iso.org/standard/71604.html
8. Frama-C project — https://frama-c.com/
9. CBMC bounded model checker — https://github.com/diffblue/cbmc
10. Umer — Comparative analysis of LLM-generated code for MISRA C++ compliance (arXiv 2506.23535) — https://arxiv.org/abs/2506.23535
11. Woven by Toyota — Agentic AI for a zero-accident future (MISRA Copilot proof of concept) — https://www.woven.toyota/en/news/agentic-ai-for-a-zero-accident-future
12. Cluster-aware dual-level test specification generation for large-scale automotive software requirements (arXiv 2606.17197) — https://arxiv.org/abs/2606.17197