From Silicon to Software: What It Takes to Deploy Embedded AI in a Safety-Critical System
What it takes to turn an AI model into a real product
A model is not a product. Many AI models can demonstrate impressive results in a lab. The real challenge is making that intelligence run safely, reliably and efficiently inside a product that operates in the real world for years.
Over this series we have written about what embedded AI is, why it has to respect physics, why the data behind it is hard to build, and how the network is designed. This article is about the last mile, which is really the hardest mile: what it actually takes to get that intelligence running inside a real product, in real time, safe and secure.
Our product, BOS (Battery Optimisation Software), is a piece of software, and it is in production. It has to operate in a highly constrained, safety and security critical embedded system, on resource constrained silicon, in real time. And you cannot write software that survives there unless you understand the entire stack it runs inside, from the silicon up. That understanding is the hard part, and it is the thing most software companies do not have.
Building the model is only the beginning
There is a version of AI development that ends when the model performs well on test data. For a lot of applications, that is genuinely most of the work. Deploy it to a server, expose an interface, and you are done.
Embedded AI does not work like that. The software has to run on the processor that sits inside the product, which is small, power-constrained, and shared with everything else the system has to do. It has to run in real time, continuously, for the life of the asset. It has to be safe, because the systems it operates within carry real energy and real consequences. It has to be secure, because anything intelligent inside critical infrastructure is a target, and the intelligence is only as trustworthy as the system protecting it. And it has to survive the real world: extreme temperature, sensor noise and drift, part to part variation, unexpected user behaviour.
None of that is model work. All of it stands between a model and a product.
“A working model feels like the finish line. It is closer to the starting line.”
Silicon is a design decision, not a procurement decision
It starts with the chip. Most people treat silicon selection as procurement: pick a processor with enough headroom and move on. For embedded AI, the choice of silicon shapes what the software can be.
We spent a long time evaluating AI accelerators and embedded processors. The goal was not raw benchmark speed, but understanding which architectures can actually sustain the kind of AI we run: recursive, iterative, continuous, cell-level. A chip that is excellent at single-shot inference for a camera can be the wrong tool for software that has to continuously maintain and update its internal states thousands of times a second inside a battery. That understanding only comes from doing the work, at the level of the silicon, over years.
It also comes from working alongside the people who build the silicon. Over the years, we have worked closely with leading semiconductor companies to understand the strengths and limitations of different architectures and how best to deploy embedded AI on them. That kind of co-development is how you learn what a processor can really do, and how you shape software to get the most out of it. It is a different relationship from licensing a component, and it is not one you can establish quickly.
The embedded intelligence is the product. The full stack is what you have to understand to build it.
Above the silicon sits everything that turns a model into real time software a customer can rely on. The low-level drivers. The middleware. The safety mechanisms that keep the system inside its limits. The security architecture that protects it. The integration with the rest of the system software. The calibration tools. The diagnostics. BOS is the intelligence that runs on top of all of it, but it cannot be written well by anyone who treats those layers as someone else’s problem.
This is the distinction that matters. We do not sell middleware or operating systems . We sell the intelligence layer that runs on top of them. But we can build that intelligence to work in this environment precisely because we understand the whole stack beneath it, and the system around it, as well as the people who build those layers do. Safety and security are not features of the model. They are properties of the whole system, and software that ignores that is a liability no matter how good the model is.
That understanding is not theoretical. We have developed battery management systems across multiple programmes against the most demanding safety and security requirements in the automotive industry. That work is what proves the capability is real. In engineering, reality is the ultimate benchmark. Systems either work in the field or they do not. It is one thing to claim you understand the full stack. It is another to have built to the standards where being wrong is not an option, alongside the most demanding partners in the sector.
“We do not sell middleware or operating systems. We sell the intelligence that runs on top of them.”
Why this understanding cannot be assembled quickly
Here is the part that is easy to miss from the outside. Understanding a stack this deep takes years, and it is not the kind of thing you can hire or buy your way into overnight.
You can hire a great ML team. You can license a good chip. You can buy middleware. What you cannot shortcut is the experience: knowing the silicon, the safety and security layers, and the system software well enough to write software that behaves correctly across all of them, in the field, for years. That knowledge lives in the seams between the layers, and it is earned by doing the work, with silicon partners and against the hardest requirements in the industry, over a long time.
That is the gap between a model and a product. A model performs on test data. A product performs for years, inside the system, under conditions that cannot be fully predicted in advance. Everything in this article is what fills that gap, and almost all of it is invisible from the outside.
“You can hire an ML team, buy a chip, license middleware. What you cannot shortcut is understanding the whole stack well enough to build software that survives in it.”
The model often gets the attention because it is visible. The engineering required to deploy it is usually invisible. Yet that invisible engineering is often where the majority of the value is created. In safety critical embedded systems, success depends on understanding the entire stack, from silicon and software architecture to safety, security and system integration. That understanding is what turns AI from a promising concept into a product that customers can trust.
Over the last seven years, one lesson has come up repeatedly: physics matters, data matters, architecture matters, but none of them create value until the software is deployed in the real world.
In the final article of this series we will step back from how we build and look at where this is going: the shift towards smart end nodes across every electrified system, and why the intelligence inside them is about to matter more than it ever has.
Dr Umut Genc is CEO of Eatron Technologies, a UK-based deep-tech company specialising in AI-powered Battery Optimisation Software for mobility and energy applications. Eatron’s Battery Optimisation Software is production-validated across automotive OEMs, two-wheeler platforms, and grid-scale energy storage systems.
