Real-target evidence for embedded development
Building embedded systemsis not the same as yesterday.
Software development has entered a new era, with AI dramatically increasing the speed and scale of how software can be built and iterated.
For embedded systems, however, software does not end at the source code. It is compiled, optimized and executed on a specific processor, under real timing, resource and system constraints.
That is why confidence still comes from what the system actually does on real hardware - and from being able to see it clearly.
When development moves at machine speed, observation cannot stay human-speed.
Accemic builds that observation layer: coverage, timing and control-flow evidence from processor trace, measured on the optimized executable while it runs - and CEDARtools.Forge, which turns that evidence into an acceptance decision outside the generator, offered as a guided pilot.
We would all like a Devin™ for embedded.
Agentic development in application software has become genuinely impressive. The best of these tools propose a change, run it, read what happened and try again - unattended, over and over, through the night. It is the clearest picture anyone has yet drawn of development at machine speed.
It works because the substrate underneath is reproducible. A container starts the same way a thousand times, and what happened comes back as data. Not because the problems there are easier - because the ground is repeatable.
Embedded is physics. Cache state, interrupt latency, bus contention, supply and temperature - behavior no model carries in full, and that shows itself only on the real device. It cannot be assumed. It has to be observed.
So a generative system for embedded targets needs two additional layers that cloud-native workflows do not provide in the same form. An evidence layer, which turns what physically happened on the device into data while the device is still running. And a convergence layer, which decides outside the generator whether the criteria have been met, and returns that decision as the next iteration’s starting point.
Both are what we build, and we build them to be integrated. Whoever writes the code, the layer underneath is the same one. The architecture is public: the end-to-end loop is described in a published patent application, while the evidence layer beneath it is covered by granted patents and already measures real targets today.
If you are building the generation side - a platform, a model, a tooling stack - we would like to hear from you.
Ground truth starts on target.
Requirements describe what should happen. Source code expresses one implementation. Trace shows what actually ran on the target - giving us a dependable basis for understanding coverage, timing and control flow.
See why we choose trace, what it can reveal and where its limits are.
Go deeper: KnowledgeMeasurement recordsPublications
Safety proved the methods.
AI changes the economics.
CEDARtools® has its roots in aerospace and automotive, where software quality, traceability, and rigorous verification are non-negotiable.
The methods developed in these domains were never inherently limited to safety-critical systems. Their limitation was economic: producing and reviewing the required evidence takes substantial engineering effort, time, and specialized tooling. Where regulation or risk justified that investment, it became standard practice. For most other embedded products, the same level of rigor was simply too expensive.
AI changes those economics. Forge* brings verification into the same machine-speed loop as development itself. Evidence can be produced, evaluated, and fed back into the next iteration continuously, reducing much of the manual effort that made rigorous verification costly.
That democratizes methods once reserved for the highest-assurance domains. Practices proven in aircraft and automobiles can become economically viable for everyday embedded systems as well - improving software quality and robustness whether the controller is flying an aircraft or making coffee.
Granted European and US patents
see the jurisdiction-level patent ledger
Target support, answered per configuration
a documented reference configuration - send us yours
Conference and magazine publications
we were substantially involved in
Collaborative research projects
with role, funding program and project outcome
A trace processor built for continuous evidence.
Live reconstruction and metric processing while the target keeps running - designed to sit beside the debugger and feed the verification chain.
Where to start
Engineering management
Close the representativeness gap
At integration and system level, application-side instrumentation can require a different build. Accemic measures the optimized executable under test and records when configuration control establishes identity with the delivered artifact.
Developers & testers
Measure what runs on the target
Coverage, timing and control flow are reconstructed from processor trace while the target runs. Where optimization removes a required source-level distinction, CEDARtools.Anchor adds a bounded trace-visible anchor and reports its measured effect.
Toolchain owners
Add the missing evidence layer
Keep the compiler, debugger, HIL bench and assurance suite. Accemic supplies continuous, machine-readable target evidence through documented interfaces - into TESSY Hyper Coverage and Teamscale, and into AbsInt TimeWeaver for hybrid WCET.
RISC-V® core and SoC teams
Turn trace into infrastructure
Evaluate CEDARtools.TraceEncoder as open RTL and use the commercial integration path for a named core, protocol scope and acceptance test. The same observation channel can feed human analysis, verification tools and automated development workflows.
AI-assisted development
Separate generation from acceptance
Forge* connects requirements-driven generation to build, target execution and an acceptance decision outside the generator. Live target evidence becomes feedback for the next iteration. Offered as a guided pilot under NDA.