Written by Alexander WeissPublished 2026-09-17

---

Suppose your compiler is flawless. Not certified. Not extensively tested. Flawless.

Could your embedded software still be unsafe?

Of course. It could implement the wrong requirement, act on stale sensor data, or deliver the right response too late. The compiler could translate every line correctly and leave every one of those problems intact.

Compiler qualification can be valuable. But letting it set the assurance agenda is a mistake. The starting point should be the failures the product must avoid, not the tool for which we can most readily buy an assurance package.

The chain of trust in AI-assisted embedded development

A simplified development chain looks like this:

Human → (AI) → Compiler → Target

Human intentions become requirements and code, sometimes with an AI assistant in the middle. The compiler translates the code. The result runs on hardware, in an environment that has its own demands.

Now imagine an assurance checklist in which the compiler claim is closed, but essential claims about the requirements, generated code and target behavior remain open:

0 × 0 × 1 × 0 = 0

Human × (AI) × Compiler × Target

Here, 0 means an unresolved evidence obligation; 1 means a claim accepted within its stated scope. We grant the compiler that 1 for the argument. The result means an incomplete safety argument, not a system certain to fail. This is an illustrative checklist, not a multiplication of failure probabilities. Without AI, omit that factor.

The point is simple: closing the compiler claim does not close the others.

Nor does this require us to dismiss formal methods. CompCert demonstrates that substantial compiler transformations can be formally verified. Its guarantee has explicit assumptions and boundaries; it is not a proof of the application’s requirements or of the complete physical system.¹

A correct translation and a correct product are different achievements.

The requirement is a working braking system

The engineering task is to demonstrate that the braking system performs its required function: the required deceleration, within the required response time, under specified operating and fault conditions.

A pedal that transmits the driver’s demand without breaking is one necessary link in that system. Its strength is a comparatively well-bounded property to substantiate. Establishing it closes a real question. It does not establish the braking function.

The rest of the argument must connect the demand to the response: sensing, control logic, actuation and their interaction. Does the complete system deliver the required braking behavior, including when something goes wrong?

The mistake is not proving the pedal. It is letting the most tractable component claim stand in for the function we actually need to establish.

That is the compiler analogy. Correct translation is one obligation within the argument for correct system behavior. It is not the objective around which the rest of that argument should be organized.

Compiler qualification under ISO 26262, DO-178C and EN 50716

The standards do not offer a universal choice between “qualified compiler” and “some testing”.

ISO 26262 makes tool impact and the detection of tool errors central to tool-confidence classification. A justified TD1 assessment can lead to TCL1, including for a tool with impact; that does not happen merely because an application test suite passes.²

DO-178C and DO-330 likewise tie qualification to how a tool is used and to the assurance credit taken for its output. The operative question is which objective would otherwise depend on trusting that tool. Alternative verification can change that qualification argument, but it must itself satisfy the applicable objectives.³

The railway standard offers a particularly concrete example. EN 50716:2023, 6.7.4.4, informative Note 1 describes how use of a non-trusted compiler can be justified through tests, checks and analyses of the object code. The example calls for sufficient coverage and techniques capable of detecting relevant compiler errors. Further compilation means repeating the tests, checks and analyses.⁴

That is a demanding route, not a loophole. A coverage percentage is not, by itself, an argument that compiler errors will be detected.

The qualification decision belongs in the assurance plan. It cannot be replaced by either a purchase order or a passing test report.

What, exactly, are we buying?

A good qualification kit can save real engineering work. It can provide reusable tests, documented constraints and evidence for a defined use case. Depending on the project, qualifying the compiler may be more economical than constructing sufficient alternative verification.

But the decision should follow the intended use and the failure modes, not the availability of a package.

Consider a small but revealing distinction in supplier language. The FAQ of one qualification-kit supplier states that open-source tools and libraries “must be qualified for their intended use”. The same supplier’s own explanation of tool confidence levels recognizes that TCL1 requires no formal qualification.⁵

The point is not the vendor. The point is the order of reasoning: classify the tool in its intended use, establish how potential tool errors are detected or prevented, and only then decide whether qualification is required and economical.

For software tools, what the first sentence leaves out matters: classification and the actual verification strategy come first. Open source is not a tool-confidence level. This is not an argument about library qualification, which is a separate question.

Nor is this an accusation that kit suppliers ignore downstream verification; their own material often discusses it. My disagreement is with making qualification the default purchasing answer before establishing the project’s actual assurance needs.

If the compiler case is already adequate while a safety-relevant requirement remains untested, the next investment should need a better justification than “we can buy more compiler confidence”.

Build the evidence shell: requirements-based verification on target

Instead of asking the pedigree of each producer to carry the safety argument, build an evidence shell around what the chain produces. This does not replace good development practice or qualified tools. It gives their contribution a place in a product-level argument.

That shell needs six things.

Requirements that can withstand challenge. Start with hazards, intended behavior, interfaces, operating limits and failure responses. Make timing and data-validity assumptions explicit. Review whether the requirements describe the right product, not merely whether they are clear enough to implement. Perfectly implementing the wrong requirement is still failure.

Tests that can disagree with the implementation. Derive expected behavior from the requirements, not from whatever the code currently does. Equivalence classes, boundary values and robustness cases help make the reasoning inspectable. They do not remove the need to justify the expected results. A separate test generator is useful only if it can challenge the implementation’s assumptions.

Coverage of logic and interactions. Statement coverage, decision coverage and modified condition/decision coverage (MC/DC) address particular questions about exercised code and decision logic. None is a finish line for system verification. Assess data and control coupling as a distinct dimension: how components exchange information and influence one another during requirements-based integration tests. Measure the relevant interactions, investigate gaps and unexpected dependencies, and check the behavior against the requirements. A covered interaction is not automatically a correct one.⁶⁷

Static analysis for what execution may miss. Check coding constraints, data flow and relevant classes of runtime errors. Where sound analyses or formal proofs are feasible, use them. Record their assumptions: an analysis is only as applicable as its model of the program and its environment.

Timing evidence with an honest boundary. The longest execution observed is not automatically a worst-case bound. Hybrid WCET analysis combines measurements of shorter execution segments with static analysis of possible paths. Whether its result supports a bound depends on justified path, timing and interference assumptions. More hours of observation do not, on their own, establish what can happen in an unobserved hardware state.⁸

Functional verification at the levels where failures occur. Host-based unit tests are useful. They do not replace target integration and system tests involving real interrupts, DMA, scheduling and peripherals. Exercise the release executable on the intended target, or justify the relationship between the tested configuration and the released one. A correct calculation delivered after its deadline can still be the wrong system behavior.

Bind the evidence to a controlled baseline: requirements, source, executable, compiler and linker versions, options, libraries and target configuration. When something changes, establish which evidence remains applicable and which must be repeated.

The useful deliverable is not a folder of green reports. It is a traceable explanation of which failures were addressed, by what means, and under which assumptions.

Beyond MC/DC: dynamic data and control coupling analysis

MC/DC asks whether each condition has been shown to independently affect a decision’s outcome. It does not, by itself, establish that the right information reached that decision at the right time.⁶

Data coupling concerns dependencies created when one component uses information supplied by another. Control coupling concerns dependencies through which components influence execution. Analyzing them dynamically means examining those relationships in actual executions, against the intended architecture and interface requirements - not merely listing possible calls.⁷⁹ The assurance objective is the coupling evidence; runtime observation is one way to strengthen that evidence, not the only possible implementation.

Consider an illustrative integration defect. One component validates a new sensor sample. Another consumes an older sample while acting on the new sample’s validity flag. Tests can satisfy the routines’ MC/DC obligations without exposing that mismatch.

The missing question is not simply whether both routines ran. It is whether the consumed sample and its validity decision belonged together.

This is where dynamic coupling analysis earns its place: identify the producer-consumer relationships and relevant transfers of control, then check which requirements-based tests exercise them. For critical interactions, examine the data instances, order, freshness and timing that the requirements depend on. Investigate both required relationships that remain untested and observed relationships the design did not intend.

The evidence must actually support those claims. An interaction that has only been inferred is not an interaction that has been checked, and every limit of the evidence belongs in the report.

Used only to complete an assessment table, coupling analysis becomes another report. Used to challenge how the components actually work together, it becomes an engineering instrument.

This is not “a higher percentage than MC/DC”. It is evidence about a different part of the problem. Neither replaces functional checks of the required system behavior.

The shell must earn its own trust

There is an obvious objection: have we merely exchanged trust in the compiler for trust in a collection of testing and analysis tools?

Yes, part of the trust moves. That is a responsibility, not a free safety improvement.

A coverage calculation may be deterministic and still be wrong. The trace may be incomplete. Source attribution may be incorrect. The set of obligations being counted may omit the very code that should have been examined. Reliable arithmetic cannot repair unreliable inputs.

The advantage we should seek is specific, checkable claims: this execution belongs to this binary; these observations are complete for this stated purpose; these tests check these requirements; this unresolved result cannot silently become a pass.

That applies to us at Accemic too. We develop trace and runtime-analysis tools, so we have a commercial interest in this debate.

Our evidence must earn its place in the safety argument by the same rules as the compiler’s.

What AI changes

Consider an assistant implementing a requirement to reject invalid sensor data. Suppose it interprets “invalid” as “missing”, overlooking data that is present but stale. Now let the tests be generated from that same interpretation.

Code and tests can agree perfectly. The compiler can translate perfectly. The system can still make a dangerous decision.

This is an illustrative common-assumption failure, not an allegation about a particular model. Humans can create it too. Automation makes it possible to carry the same interpretation through requirements, code, tests and documentation without ever introducing a genuinely different check.

The answer is not to call a second prompt “independent verification”. It is to establish where the expected behavior comes from, who challenges it, and who has authority to change it.

Independence is a property of the evidence path, not the number of prompts.

A generator may propose changes to requirements, tests or acceptance criteria. It must not be allowed to approve the changes by which its own implementation will be judged. Those decisions need a separate, controlled authority.

AI does not make compiler defects harmless. It makes an assurance strategy centered on faithful translation even less convincing: faithful translation cannot rescue a mistaken premise.

The next assurance euro

Required assurance objectives are not optional. Beyond them, additional investment should follow the most consequential unresolved failure modes, not the most convenient deliverable.

Qualify the compiler when the argument calls for it. Use a kit when it is the right way to obtain the evidence. But do not let an answer about translation stand in for an answer about the product.

Which concrete failure mode makes additional compiler qualification your next priority - rather than closing a gap in requirements, integration or timing evidence?

The objective is a working braking system. The pedal is one part of the evidence.

---

Acknowledgment. This argument was sharpened in long, often controversial and very instructive discussions with Martin Heininger of HEICON. Thank you, Martin. We do not agree on every point; the positions taken here, and any errors, are mine.

Further reading

For the scope of individual metrics, see the kinds of code coverage and what each establishes.

Related: what the standards actually require of structural coverage · MC/DC, worked through

Sources and scope

The argument about budget priorities is the author’s position. The numerical illustration is not a reliability model. The standards below have different scopes and conditions; this article is not a project-specific qualification decision.

Footnotes

1. CompCert, CompCert C: a trustworthy compiler, especially sections 1.2-1.3 on semantic preservation, assumptions and unverified surrounding phases. Accessed 15 September 2026. ↩

2. ISO 26262-8:2018, Clause 11. Public supporting sources: Reactive Systems, Reactis Safety Manual - Tool Classification, including the TI/TD/TCL mapping. This is a supplier explanation, not a substitute for the normative text. Accessed 15 September 2026. ↩

3. FAA, AC 20-115D, section 10; Frederic Pothon, DO-330/ED-215: Benefits of the New Tool Qualification Document, particularly sections 3 and 6. The latter is an explanatory paper by a participant in the standards work, not the standard itself. Accessed 15 September 2026. ↩

4. EN 50716:2023, 6.7.4.4, informative Note 1, printed page 35; full text made available by the Norwegian Electrotechnical Committee (NEK), PDF page 37. The example was checked directly against the displayed standard page. Accessed 15 September 2026. ↩

5. Public FAQ and tool-confidence glossary of a commercial qualification-kit supplier, rechecked 16 September 2026. The supplier is deliberately not named: the point concerns a recurring pattern in procurement language, not one company. ↩

6. Hayhurst et al., A Practical Tutorial on Modified Condition/Decision Coverage, NASA/TM-2001-210876, 2001. A research/tutorial source, not current regulatory guidance. ↩ ↩²

7. FAA, AC 00-69, Best Practices for Airborne Software Development Assurance Using EUROCAE ED-12() and RTCA DO-178(), section 3.2, printed page 3. Data coupling and control coupling have different types and purposes, and depend on specified interfaces and intercomponent dependencies. Complementary best-practice information, not a substitute for the standards. Text and displayed page checked 16 September 2026. The sample/validity mismatch above is the author’s illustrative example, not a reported incident or a claimed tool demonstration. ↩ ↩²

8. Daniel Kästner et al., TimeWeaver: A Tool for Hybrid Worst-Case Execution Time Analysis, WCET 2019, especially section 3.3. The qualification about unobserved timings is the author’s methodological caution; a bound obtained from measured segment times remains dependent on the adequacy of those timings and the analysis assumptions. ↩

9. FAA, Object-Oriented Technology Verification Phase 2 Handbook - Data Coupling and Control Coupling, DOT/FAA/AR-07/19, 2007, executive summary and sections 3-4. Research on the DO-178B context, used here to distinguish intercomponent dependency evidence from intracomponent structural coverage, not as a substitute for DO-178C. Executive summary and information-flow discussion (printed pages vii and 12) rechecked against the displayed pages on 16 September 2026. ↩