Putting safety-critical and general-purpose workloads on the same processor is straightforward. Doing it in a way that holds up is not.
The phrase "mixed-criticality" has become a checkbox. Almost every embedded software stack on the market claims to support it. In practice, what that claim means varies enormously, and the differences matter.
There is a useful test. Ask the vendor: if the lowest-criticality partition fails in the worst way possible — runaway thread, memory corruption, malicious actor with root — what changes for the highest-criticality partition?
The honest answer in many architectures is: something. Maybe latency. Maybe scheduling. Maybe a shared resource the safety case did not fully account for. The architectures that hold up are the ones where the honest answer is: nothing. Not by convention. Not by careful coding. By construction.
Isolation as a Property, Not a Feature
Real isolation between workloads on the same processor is a property of the layer underneath the operating systems. It is not something an operating system can enforce on itself. The mechanisms are well understood, they involve a small, rigorously designed layer (a separation kernel hypervisor) that partitions CPU time, memory, I/O, and increasingly GPU resources, and presents each guest with a strictly bounded view of the hardware.
The hard part is not naming the mechanisms. The hard part is building them in a way that:
- Can be reasoned about formally enough to support certification.
- Is small enough that the safety case is tractable.
- Is fast enough that consolidation is worth doing.
- Extends to modern accelerators, GPUs and AI engines, not just CPUs and memory.
The vendors that can say 'nothing changes' when a low-criticality partition fails are the ones whose architecture was designed for that question from the beginning.
Determinism for the Workloads That Did Not Used to Need It
There is a second piece that gets less attention. Classical mixed-criticality architectures handle CPU and memory partitioning well. The newer challenge is everything else on the chip — GPUs, AI accelerators, high-bandwidth I/O — which were not designed with bounded latency in mind.
When a perception or inference workload runs on a shared GPU, the timing of every other GPU-touching task in the system becomes a question instead of a guarantee. For a safety-critical display or a real-time control loop, a question is not good enough.
Time-bounded execution for heterogeneous compute — scheduling that gives accelerator workloads predictable latency, not just average throughput — is what brings GPUs and AI engines into the mixed-criticality story properly. Without it, consolidation onto modern silicon stops working as soon as the GPU comes into play.
What the Architecture Enables
Put isolation and accelerator determinism together, and the result is a platform where:
- Safety-critical and general-purpose workloads coexist — without the latter putting the former at risk.
- AI and perception move to the edge — without breaking the timing the rest of the system depends on.
- Modern graphics drives certifiable displays — alongside non-critical infotainment or operator interfaces.
- Security monitoring runs underneath the guests — where it can actually see what is happening.
Our patent portfolio is concentrated in exactly these areas — separation kernel architecture, secure domain isolation, hypervisor-level security and monitoring, deterministic execution for accelerators, and the graphics stack that ties them to modern displays.
The whitepaper walks through how the pieces fit together, and what kinds of systems they make possible. If you are building a platform where consolidation has to be real, not aspirational, it is the right starting point.
Advancing Mission-Critical Edge Systems
A deeper look at the IP, architecture, and engineering decisions behind the next generation of secure, certifiable edge platforms.
