Modern flight displays look like consumer screens. The software underneath them has almost nothing in common with consumer software, and the reasons matter.
A modern cockpit looks, from the pilot's seat, like a row of high-resolution displays running smooth, animated, full-color graphics, synthetic vision, moving maps, sensor fusion, and tactical overlays. It looks like consumer software, and that is the point. Pilots, operators, and crews are used to a level of visual clarity that the previous generation of avionics could not provide.
Underneath, the software is almost nothing like consumer software, and it cannot be.
Three Constraints That Change Everything
Three constraints separate a certifiable display system from anything you might run on a desktop or a phone:
- Determinism — Every frame must render inside a known time budget, every time. Not on average. Not most of the time. Every time.
- Isolation — The display software cannot be allowed to interfere with flight-critical software, even if it crashes, even if it is compromised, even if it tries to.
- Certifiability — Everything in the stack must be auditable to DO-178C, DO-254, or the relevant standard, including the parts the GPU vendor wrote, which were almost certainly written for a different market.
Any one of these constraints is manageable. The combination is what defines the discipline. You cannot have a certifiable cockpit by taking a consumer graphics stack and adding monitoring. You have to start from a foundation that was designed for these constraints in the first place.
A certifiable cockpit is not a consumer graphics stack with safety features added. It is a different kind of system, built differently from the start.
Where Modern Graphics Meets Legacy Reality
There is a second tension that does not get discussed enough. The industry has clearly moved to Vulkan and other modern, programmable graphics APIs. That is where new GPU silicon, new tooling, and new vendor investment now live. Programs designed today should be on that path.
But programs designed today are not greenfield. They inherit:
- Display applications written against OpenGL, sometimes for decades.
- Certification artifacts that took years and millions of dollars to produce.
- Engineers and tools knowing one API, not the other.
- Subsystems that depend on fixed-function pipeline behavior that modern GPUs no longer implement natively.
Forcing a program to rewrite all of that, all at once, is not a technology decision. It is a schedule and budget decision, and it is usually the wrong one.
The Architecture That Resolves the Tension
The right answer is an architecture that lets the program run modern Vulkan-class hardware without abandoning the OpenGL ecosystem on top of it, and that lets fixed-function legacy code keep working on GPUs that no longer have fixed-function hardware. That requires real engineering: OpenGL-to-Vulkan translation that preserves semantics, shader generation that emulates fixed-function behavior, and EGL integration that ties the whole stack to the display system.
Combine that with a separation kernel hypervisor underneath, and the cockpit suddenly has properties that were very hard to deliver before: modern graphics performance, legacy application compatibility, strong isolation from flight-critical software, and a certification story that holds together.
Our whitepaper walks through how this architecture is constructed, the specific innovations that make it work, and the use cases across avionics displays, defense electronics, and mission systems that it enables. If you are designing a display system that must last a generation, it is worth the read.
Advancing Mission-Critical Edge Systems
A deeper look at the IP, architecture, and engineering decisions behind the next generation of secure, certifiable edge platforms.
