Local AI for embedded C and C++: unit tests, MISRA findings and documentation, offline

Unit tests and MISRA fixes with a local LLM

Local AI for embedded C is an open coding model on a workstation in your engineering network. It drafts unit tests from requirements and source code, explains MISRA findings, proposes compliant fixes and documents modules nobody has touched in years; the code, which often belongs to an OEM customer under a non-disclosure agreement, stays in the building. The most detailed published result comes from TUM and Hydac Software: with a search index over headers, sources and old tests, 84.5 per cent of generated tests passed runtime validation, against 50.5 per cent without it. A workstation with one NVIDIA RTX PRO 4500 Blackwell (32 GB) is the smallest configuration we recommend for a small team.

This guide is for heads of software and test at automotive suppliers, machine builders and medical device makers, and for the IT staff who run their build infrastructure. Our guide to local AI for PLC programming covers IEC 61131-3 code on controllers; this page covers C and C++ on microcontrollers and embedded processors. For unit and end-to-end tests in business software, see our guide to AI test generation on-premise, and for review bots on merge requests our guide to self-hosted AI code review.

What the EmbC-Test study measured

The EmbC-Test paper was submitted to arXiv on 10 March 2026 by authors from the Technical University of Munich, including its Munich Institute of Robotics and Machine Intelligence (MIRMI), and from Hydac Software GmbH. It is the most detailed public test of LLM test generation on industrial embedded C that we found. The authors built a retrieval-augmented generation (RAG) pipeline: a search index over C header files, source code and the company's existing tests, from which the five most relevant chunks go into the prompt together with the requirement. The generated tests were Python-based tests for embedded C, like the company's own suite, and had to "compile and run against the target software".

EmbC-Test, arXiv 2603.09497v1 of 10 March 2026, Table 1 and text, read on 30 October 2026. Runtime-valid: the generated test passed the authors' three-step check of syntax, compilation (import) and run. Measurements by the authors on Hydac's code; two independent domain experts rated the tests. Of the reviewed tests, 38.9 per cent were kept as they were, 55.6 per cent needed changes and 5.6 per cent had to be rewritten. Manual test writing ran at about one test per hour in the same comparison.

Retrieval decides more than anything else: the right chunks lifted the share of runnable tests by 34 points, random chunks by only 12, by our arithmetic from the table. Coverage stays well below the hand-written suites, which the authors note took months of iterative refinement, while the generated tests came from a single run without feedback. Review stays as well, since more than half of the tests needed changes before they were accepted. On that basis the authors estimate that the testing effort for a library with 57 software requirements could fall from 57 hours to 19.2 hours, a saving of 66 per cent.

The paper also sets limits. Its authors write that zero-shot generation is unreliable and that generated tests can encode incorrect expectations, and that the approach works best on well-documented code bases with unified naming and a rich store of legacy tests. They highly recommend a human in the loop. All results come from one company's code base. The embedding model in their pipeline was "locally hosted", and they suggest "a code-optimized embedding model" as a starting point; the generating model was "a cloud-hosted LLM" that the paper does not name. We found no published comparison of open models on this task, so the local route has to be measured on your own requirements.

The test loop on your own hardware

The workflow keeps every step that the paper checked and adds the feedback the authors list as future work.

1. Index the project. Header files, sources, existing tests and your coding guidelines go into a search index. Qwen3-Embedding-0.6B (Apache 2.0) is one small embedding model whose card names code retrieval among its capabilities. Rebuild the index after each merge, so that the model sees current interfaces.
2. Draft from a requirement. The engineer picks a requirement; the model receives it with the five best chunks and drafts a test in your framework: the company's Python harness, as at Hydac, or a C framework such as Unity, which its authors describe as "a unit-testing framework for C", with CMock (MIT) for mocks and stubs.
3. Build and run. A build machine compiles the test for the host or the target simulator and runs it. Compiler errors and failed assertions go back to the model for a fixed number of rounds, then the draft is dropped and the reason recorded.
4. Measure coverage. Your coverage tool reports what the new tests add, the measure EmbC-Test compared with the manual suites.
5. Review. An engineer accepts, edits or rejects each test against the requirement and records the decision, so that after a month you know your own acceptance rate.

The GPU is busy only while the model writes. Compiling and running take time on the build machines, so one workstation serves more engineers than its number of parallel sessions suggests.

You can order the workstation alone, the setup of the model and the code index alone, or both together: the workstation delivered with everything installed and configured. The link to your build machines, test framework and coverage tool depends on your toolchain, so we agree it in a pilot; write to us and we suggest the best solution for your tasks and budget.

MISRA C findings explained and fixed with a local model

MISRA C:2025 is the current edition of the guidelines; the MISRA Consortium's shop states that it was "Updated in March 2025" and supersedes the versions of 2023, 2019, 2012, 2004 and 1998. Your static analyser finds the violations. A local model adds the part that takes engineers time: it reads the function around a finding, explains in plain words why the rule applies, proposes a compliant rewrite or, where the code has to stay as it is, drafts the rationale for a deviation that an engineer then completes. The analyser runs again on the changed code, and the unit tests run again to show that the behaviour did not change. The model never marks a finding as resolved; only the next clean run of the checker does.

The open-source analyser Cppcheck (GPL-3.0) ships a MISRA add-on whose manual, read on 31 October 2026, says it "is used to verify compliance with MISRA C 2012"; the same manual states that "Misra checkers in open source Cppcheck only cover MISRA rules partially" and points to Cppcheck Premium for full coverage. Teams that need complete MISRA C:2025 checking therefore keep the commercial checker their process has qualified. The rule texts need care too. The Cppcheck manual notes that its script "does not provide rule texts, those should be downloaded from MISRA", and MISRA sells its documents as "single user licenses for the named individuals" that "may not be shared or transferred". Before anyone puts the full guideline text into a shared search index, check what your licence allows; a short note per rule in your team's own words, with the rule number, gives the model what it needs.

VectorCAST Reqs2x and local models

Test tool vendors are adding the same capability. Vector's VectorCAST 2026 includes Reqs2x, which Vector calls an "AI-powered Requirements-Based Test Creator". According to Vector's product page, read on 31 October 2026, it uses program slicing and LLMs to map requirements from DOORS, Polarion or CSV files to the functions that implement them, generates test cases linked back to the requirements and presents both for review: "Nothing is accepted automatically." The page describes a "Bring Your Own Model" approach and states that "On-premises, cloud, and hybrid deployments are all supported", without naming models or interfaces. For a VectorCAST customer, a model server on your own GPU can therefore be the on-premises model; ask Vector which interface its model option expects before you plan the hardware. The page says the feature was designed with MISRA C:2025 and EU AI Act requirements in mind and does not mention ISO 26262 or tool qualification.

Why the model stays outside the ISO 26262 evidence

Generated tests become safety evidence only through your process. ISO 26262-8:2018, clause 11, deals with confidence in the use of software tools. It derives a tool confidence level from the tool impact, whether a tool error can introduce or miss an error in the product, and from the tool error detection, how likely such an error is caught, and asks for tool qualification at the higher confidence levels.

We recommend a setup in which the model only drafts. An engineer reviews each test against the requirement, your qualified test tool runs it and your qualified coverage tool measures it, so the evidence is a reviewed test with a recorded run, exactly like a test written by hand. How your safety case classifies the model as a tool is a decision for your functional safety manager and assessor. For medical device software, your regulatory team applies its own rules for tools and evidence; our guide for medical device manufacturers covers the regulatory files, and our guide for automotive suppliers the quality documents around the code.

Which workstation or server for embedded test generation

We size by our users-per-card rule, as in our guide on how many users one RTX PRO 6000 serves: 90 per cent of the memory the driver reports, less 3 GiB per card, less the weights. That leaves 25.7 GiB on a 32 GB card, 61.5 GiB on the RTX PRO 5000 72 GB and 83.0 GiB on a 96 GB RTX PRO 6000. A session of 32,768 tokens holds the requirement, the retrieved chunks, the unit under test and the compiler output. Every row includes Qwen3-Embedding-0.6B for the index.

Our estimates by the users-per-card rule, not measurements: sessions that fit in memory; how fast each one runs depends on the card's bandwidth. Weights: gpt-oss-20b 13.76 GB, Qwen3-Coder-30B-A3B 31.2 GB in FP8, Qwen3-Coder-Next 80.4 GB in FP8, Qwen3-Embedding-0.6B 1.19 GB (Hugging Face file lists). 16-bit cache per 32K session: 0.75 GiB (gpt-oss-20b), 3 GiB (Coder-30B-A3B, FP8 cache in brackets), 0.75 GiB plus a fixed state (Coder-Next, 110 sessions without the embedding model, as in our PLC guide).

Entry, one RTX PRO 4500. The RTX PRO 4500 Blackwell has 32 GB of GDDR7, 896 GB/s and 200 W. It holds gpt-oss-20b (21B parameters, 3.6B active, Apache 2.0) with the embedding model and 15 sessions. Qwen3-Coder-30B-A3B, a coding model with 30.5B parameters, 3.3B active and tool calling, fits in Ollama's 4-bit build of 19 GB but leaves room for only two sessions. The 24 GB RTX PRO 4000 keeps 18.5 GiB by our rule, enough for gpt-oss-20b with 6 such sessions; our page on 30B models on 24 GB cards covers that class. A workstation with one RTX PRO 4500 draws about 0.6 kW at the wall by our estimate (the card, a 350 W-class processor and 15 per cent for the rest), and our page to buy an RTX PRO 4500 workstation lists the builds.

Entry for a team, one RTX PRO 5000 72 GB. Qwen3-Coder-30B-A3B runs in FP8, with 8-bit weights where the RTX PRO 4500 needs 4-bit, and holds 10 sessions, 20 with an FP8 cache, at about 0.75 kW by our estimate.

Mid, one RTX PRO 6000. The Workstation Edition (600 W) or Max-Q (300 W) with 96 GB holds the same model with 17 sessions, or gpt-oss-120b with 18 sessions of 32K by our rule for teams that want a larger model; one Workstation Edition draws about 1.1 kW by our estimate. Two Workstation Edition cards are the realistic maximum for that edition, and three or four Max-Q belong only in a chassis built for them with strong directed airflow.

Large, a two-card server. The entry server on our AI servers page carries two RTX PRO 6000 Server Edition cards, two AMD EPYC processors and 384 GB of DDR5 ECC memory, at about 1.8 kW by our estimate. As a pair the cards hold Qwen3-Coder-Next (80B, 3B active, Apache 2.0) for several teams by day and draft tests for a whole module library at night.

No published speed exists for these models on embedded test generation. Speed depends on the card's memory bandwidth, the model's active parameters and the length of the prompt, so time a sample of your own requirements before you promise a turnaround.

We build these workstations and servers to order; send us your toolchain, one sample module with its requirements and the size of your team, and our team replies with a configuration.

Setting it up offline, for the IT team

1. Install without internet access. Driver, container runtime, model server and weights reach the machine from a staging host, as our guide to an air-gapped LLM server describes. The machine then needs no internet connection, and customer code under NDA stays inside your network.
2. Serve the models. Ollama is enough for a pilot on one workstation; vLLM serves a team more efficiently. vLLM's --api-key protects only some of its paths, so put an LLM gateway with keys and a query log in front.
3. Connect the build machine. Give the assistant one tool that builds and runs a single test file with your cross-compiler or simulator and returns the output. Without it, every draft waits for an engineer to compile it.
4. Decide on logs. Prompts contain customer code. Decide before the first run how long the gateway keeps them and who may read them; our article on trade secrets, NDAs and AI tools covers the contractual side, and our guide to an AI coding assistant policy the internal rules.
5. Measure. Take 20 requirements with reviewed tests from a finished project and rerun them after every model or prompt change, counting runnable tests, coverage and the share accepted without edits, the measures EmbC-Test used.

FAQ