Services · AI Engineering
AI on the device, in the cloud and in your engineering
Three things you can commission separately: a model in your device, the evaluation of your fleet data, and the AI tools for your own engineering. You decide where to start.
AI changes everything and nothing
For us, as technology enthusiasts, innovators and passionate system and product developers, AI opens up entirely new possibilities. At the same time, it brings an entirely new range of requirements: things that have to be considered, planned, tested and maintained. We aim to move forward driven by innovation, and we are glad when our customers and partners benefit from what we learn.
AI on the device
Evaluating camera images and sensor data on the device. The raw data stays in the machine.
AI in the cloud
Bringing data from the whole fleet together, evaluating it and building better models from it.
AI in your engineering
Setting up the AI tools your team works with every day.
AI on the device
What we do with it
Object recognition, face recognition, pattern recognition, anomaly detection and predictive maintenance. The device recognises, classifies and reports a condition, without the raw data leaving the machine.
On which hardware
qdSBC is built on the STM32MP25. Its accelerator delivers up to 1.35 TOPS; TensorFlow Lite and ONNX can be run on it.
When the computing power is not enough
Then we optimise the method, or we use a different module. Short feasibility studies establish which route will work.
From feasibility into series production
A model from a development machine does not simply run on the accelerator of an edge device. Quantisation, conversion and many other optimisations are part of the job until performance and runtime meet the demands of robust series production.
AI in the cloud
What a single device cannot see shows up across many.
Bringing fleet data together
Readings, states and logs from every device in one place, through qdCloud or through your own environment.
Seeing what a single device hides
Outliers only stand out once the normal case across many devices, sites and seasons is known.
Training and retraining models
The fleet data produces the next model version. It goes to the devices as a signed update, with fallback to the last working state.
AI in your engineering
What you get
We set up the AI tools your team works with, in your environment: agents that write requirements, derive test cases, produce technical analyses and check every change. Configured and tuned to your procedures and processes.
You decide how much human involvement the process keeps
The whole spectrum is possible: purely agentic processes at one end, and at the other, processes in which people keep an understanding of the entire implementation and processing, as functional safety ultimately requires.
Linked to your written procedures
Procedure instructions, work instructions and engineering rules can be held in a form that humans and AI read alike. The team benefits: the AI works the way you want it done, not the way someone else would have done it.
Skill and data training
It has proven worthwhile to build good test and simulation environments for skill development, so that most of the behaviour is as deterministic as possible before the first release. Here too you are developing procedures and, in the end, software that has a major influence on product quality and on potential technical debt.
Every way of working is measured
Before a way of working goes live, we compare the same tasks with it and without it. What makes no difference stays out. Most people skip this step.
AI on the device, in the cloud or in the engineering process brings the same challenges that software has long brought. For it to work over the medium and long term, it has to be well designed, maintainable and understandable.
Safety and evidence
The model belongs in the bill of materials
Runtime, framework, drivers and model version belong in the device's SBOM. Without them, the evidence under the Cyber Resilience Act remains incomplete.
Evidence of which model version ran where
Every model version belongs to a release and to an update. If something goes wrong in the field, you can prove what was on the device at the time.
Model changes can still be qualified
The system's requirements, performance and latencies are managed and therefore verifiable. A model change can be qualified before it goes into series production.
The accredited body is involved from the start
We develop functionally safe electronics and software from SIL 1 to SIL 3 and from PL a to PL e, and we align early with the accredited body. The same order applies to AI: what has to be provable in the end is settled before the architecture.
We settle in the concept phase how far AI may enter the safety chain
Whether a model can be part of a safety function is decided on the evidence, together with the accredited body. A split often works: the model delivers the result and a conventional monitor safeguards it. Since 2024, ISO/IEC TR 5469 has addressed functional safety and AI together.
How an on-device AI project runs
The first step can also be commissioned on its own, before you commit to hardware.
Feasibility and data
What has to be recognised, how reliably and how fast? We test on your data whether the goal is achievable. That includes where the data comes from, how much of it is needed and who decides what it shows. Without that labelling, a model learns nothing, and more is decided at this stage than in the model itself.
Model
Training, quantisation and conversion to the target format. Which method fits best follows from the requirements on your product: how reliably it has to recognise, how fast it has to respond and what may happen when it is unsure. Much of that is already settled during feasibility.
Onto the board and into the image
We measure runtime, memory and heat on the target hardware. If the model fits, it becomes part of the image, with the same bill of materials and the same signed update as the rest of the software.
Operation
Watching how the model behaves in the field, retraining it when its performance drops, and rolling out the new version.
Products that save time in the project
- HardwareView
qdSBC
Single-board computer on the STM32MP25 with an AI accelerator and graphics unit. In development.
View 
Operating systemViewqdCoreX
Buildroot Linux with signed updates, SBOM and CVE report. The model is managed in it like any other package.
View
IoT platformViewqdCloud
Collecting fleet data and rolling out new model versions. In Germany or at your site.
View
What we work with
Runtimes on the device
- TensorFlow Lite
- ONNX Runtime
- X-LINUX-AI
Compute units
- NPU (STM32MP2)
- GPU
- CPU
Tools
- ST Edge AI
- Python
Transparency from the start
Do we need a cloud for AI on the device?
Not for operation. The model runs on the device, even without a connection. A cloud is worthwhile where you want to evaluate data across many devices or roll out new model versions.
How much data do we need?
For a first assessment, whatever you already record is enough. How much it takes in the end depends on the task. That is exactly what the first step answers, before you go into development.
What happens to our data?
Your data stays yours. Where training happens, with which tools, and what leaves your premises is set out in the development contract before the first file is handed over.
What does the AI Act mean for us?
We clarify at the start whether and how the regulation affects your product, and we record the classification. The deadlines for high-risk systems have been postponed, to 2 December 2027 and, for AI in products that are already regulated, to 2 August 2028; AI under the Machinery Regulation is to be largely exempted. A good deal will change before then, which is all the more reason to plan classification and evidence in from the start. In functional safety, we have worked in this order for years.
May a model carry a safety function?
That depends on the evidence, and we settle it early. For a safety-related function, you have to show that it reacts correctly under every condition considered; for a trained model, that is demanding and sometimes not achievable. That is why a split often works: the model delivers the result and a conventional monitor safeguards it. What works in your case is determined by the hazard analysis and the discussion with the accredited body. We do both anyway, from SIL 1 to SIL 3 and from PL a to PL e.
Can you check feasibility only?
Yes. The first step can be commissioned as a separate, clearly bounded assignment. Afterwards you know whether the development is worth it, and you can still say no.
Where would you start?
On the device, in the cloud or in your own engineering: tell us what you have in mind and which data already exists for it. We will tell you whether it will work and where we see risks. The assessment, up to an indicative price, is free of charge.
