Safety-critical graphics is where a rendering bug is not a cosmetic annoyance. On a certified glass cockpit the wrong pixel at the wrong moment is a flight-safety problem, and the software has to prove it behaves the same way every time, under a standard like DO-178. We write graphics that run on constrained, certifiable, embedded hardware and hold up when the display is not allowed to fail.
Certifiable glass-cockpit rendering
We wrote a DO-178-style glass-cockpit rendering library for an experimental glass-panel avionics product, Avilution XFS. That means a rendering path you can actually defend to a certification authority: bounded, predictable behavior, no surprise allocations mid-frame, and a display that draws what it is told and nothing else. Glass cockpits are not only certified panels: for Precog's Skyline we built an iPad-based glass-cockpit augmented-reality device that overlays synthetic-vision terrain on the pilot's view, using a Stratux ADS-B and GPS receiver to capture aircraft pose, part of our mobile work.
OpenSceneGraph on embedded and mobile
We have ported OpenSceneGraph and osgEarth to iOS and to embedded hardware for aviation synthetic vision, so the same terrain engine that runs on a workstation runs in the aircraft. We have also ported OpenSceneGraph into automotive navigation and infotainment core toolkits, working with Altia on the rendering behind instrument clusters and in-vehicle displays.
Trustworthy from the silicon up
Getting graphics onto certifiable hardware often starts below the application, at the driver. We work in that driver layer, where the display stack has to be dependable from the silicon up, not just at the top of the application. And when the processor itself is bespoke, that is our RISC-V core work.
Hardware, from low-end boards to Jetson
We work across the embedded range, from low-end single-board computers to NVIDIA Jetson modules, fitting the renderer to the memory, the GPU, and the thermal and power budget the box actually has. Embedded is where you find out whether your graphics code was ever really efficient, because there is nowhere for waste to hide.
How it connects
This is the constrained-hardware end of our avionics, real-time 3D graphics, geospatial, visual simulation, and Linux driver work: the same engines and terrain, made to fit and made to certify.
Who works on it
AlphaPixel is a US-owned small business, founded in 2004, with senior developers who each have 25-plus years in real-time 3D, embedded, and driver-level work. DLA DD2345 / ITAR registered. We take closed-source defense work and open source alike, and we do not sell a display, so our advice is not a sales pitch for one.
Frequently asked questions
What is safety-critical graphics software?
It is rendering where a defect is a safety problem, not a cosmetic one. On a certified glass cockpit the wrong pixel at the wrong moment is a flight-safety issue, so the software has to behave the same way every time. We write graphics that run on constrained, certifiable, embedded hardware and hold up when the display is not allowed to fail.
Do you write DO-178 certifiable rendering software?
We write DO-178-style rendering software: a path you can defend to a certification authority, with bounded, predictable behavior, no surprise allocations mid-frame, and a display that draws what it is told and nothing else. We wrote exactly that kind of glass-cockpit rendering library for an experimental glass-panel avionics product. We are not a DER and do not sign off your certification, we build the rendering so it survives the process your program runs.
What makes certifiable rendering different from ordinary 3D graphics?
Ordinary 3D graphics can allocate memory when it likes, vary its frame time, and fail gracefully. Certifiable rendering cannot: it has to be deterministic and analyzable, with predictable timing and no hidden state. That constraint shapes everything from the data structures to the driver.
What hardware do you target for embedded and certifiable displays?
We work across the embedded range, from low-end single-board computers up to NVIDIA Jetson modules, fitting the renderer to the memory, the GPU, and the thermal and power budget the box actually has. Embedded is where you find out whether your graphics code was ever really efficient, because there is nowhere for waste to hide.
Can you run OpenSceneGraph or osgEarth on embedded and mobile aviation hardware?
Yes. We have ported OpenSceneGraph and osgEarth to iOS and to embedded hardware for aviation synthetic vision, so the same terrain engine that runs on a workstation runs in the aircraft. We have also ported OpenSceneGraph into automotive navigation and infotainment core toolkits for instrument clusters and in-vehicle displays. osgEarth and OpenSceneGraph will never be certifiable as safety-critical, however.
Do you work below the application, at the driver level?
Yes. Getting graphics onto certifiable hardware often starts at the driver, where the display stack has to be dependable from the silicon up. We work in that layer, and when the processor itself is bespoke, that is our RISC-V core work.
Can you handle classified or export-controlled safety-critical work?
Yes. AlphaPixel is a US-owned small business, DLA DD2345 and ITAR registered, and we take closed-source defense work and open source alike. We are used to programs that cannot be discussed publicly.
How do we scope a safety-critical graphics project with you?
It depends on the target hardware, the standard you certify to, and how much of the stack you need us in, from the driver up to the display. Tell us the box, the budget (memory, GPU, power, thermal), and the certification basis, and we will scope it. Contact us to start.
Talk to us
Tell us what you’re building and where it’s stuck. We’ll tell you straight whether it’s something we can help with, and how we’d approach it.
Or see how we run consulting and software development engagements.
