When a display fails on a consumer device, the user restarts it. When it fails on a patient monitor or an industrial control panel, the consequences are far more serious.
LVGL Safe is built for the teams that cannot afford to get it wrong: teams building medical devices (IEC 62304), industrial systems (IEC 61508), automotive (ISO 26262), aerospace (DO-178C), and more.
The Problem#
Building a graphical interface for a medical device, an industrial machine, or an automotive system is a fundamentally different undertaking from building one for a consumer product. In regulated environments, the software running your display must meet certification standards like IEC 61508 for functional safety, IEC 62304 for medical device software, ISO 26262 for automotive, and DO-178C for aerospace.
These are not optional. They are the price of admission to the market.
The most established commercial path for safety-qualified UI today is Qt Safe Renderer, a pre-certified runtime component that runs alongside Qt's main UI framework. It is a credible solution that has been widely used in production. But it is designed around a specific architectural pattern: safety-critical UI elements run in an isolated certified process, separate from the main Qt application, and their output is composited onto the display.
This architecture assumes you have the resources for a multi-stack system often requiring MPUs and added integration complexity. For teams that need a lightweight, fully certifiable UI runtime they can deploy on constrained embedded hardware, all the way down to an MCU, without pulling in a broader, heftier stack, it simply does not work. And if teams want full, unrestricted access to every line of source code in their certified software, any closed commercial framework presents challenges.
The other path has been building a custom display stack from scratch, which avoids external dependencies but trades them for high and unexpected engineering cost, consistent recertification risk, drawn-out re-certification cycles, and lengthy time-to-market.
What LVGL Safe Is#
LVGL Safe is a complete, purpose-built UI runtime written from the ground up with safety as the core design constraint. It is not a stripped-down version of LVGL Open. It is a separate codebase where the entire library is designed for safety-critical deployment, targeting ASIL-B and SIL-2 compliance, with full source code availability to partners to audit and integrate into their own certification documentation.
A few of the architectural decisions that define LVGL Safe:
-
No dynamic memory allocation. LVGL Safe does not use
mallocat runtime. Every widget and display object is statically allocated. Dynamic allocation is prohibited by most safety certification standards and is a common source of undefined behavior. -
Flat layout model. There is no parent-child widget hierarchy. Widgets are positioned on screen directly using explicit coordinates, which simplifies the execution model and makes behavior easier to trace and verify.
-
Explicit render control. Rendering is triggered by your code, not managed by a hidden event loop.
-
Full source access. Every line is available for review and integration into your certification documentation. There is no opaque boundary to manage.
LVGL Safe is an entirely separate codebase from LVGL Open. It shares the team's decade of embedded UI experience, but every API and internal structure is designed specifically for safety-critical constraints.
Built on Ten Years of Embedded UI#
LVGL Safe is built by the same team behind LVGL Open, the most widely used open-source graphics library for embedded devices, running on over 100 million screens across consumer and industrial products today.
That matters because the people building LVGL Safe understand what it means to build embedded UI. The team has spent a decade learning the constraints of real hardware: the memory limits, the display driver requirements, the rendering tradeoffs, the workflows that product teams actually live with. That experience is reflected in every design decision in LVGL Safe.
It is also why active integration work is underway targeting the safety-oriented RTOS environments where certified products actually run. A safe UI runtime that does not fit into your existing OS and toolchain is only half a solution.
Evaluating Embedded UI for Functional Safety Compliance#
If you are evaluating UI software for a regulated product line, the most important distinction to understand is what each solution actually lets you build.
Qt Safe Renderer is certified, but what it does is narrowly scoped: it blends pre-rendered images, primarily for safety-critical telltales and warning indicators. It is not a full UI library.
LVGL Safe targets ASIL-B and SIL-2 compliance and provides a complete, interactive UI library. That means full widget support, dynamic data binding, input handling, and layout. Everything required to build a real product interface, not just overlay warning icons onto a screen.
For most regulated products, the question is not which solution has the highest certification level on paper. It is which solution can actually build the UI your product needs, within a certifiable boundary, with access to the source code your certification program requires.
How LVGL Safe Works: Architecture and Integration#
The concepts will feel familiar if you have worked with LVGL Open, with a much simpler API built for safety from the ground up. Here is how the key pieces fit together.
Runtime Model#
- Displays are initialized with explicit resolution, color format, and stride settings
- All widgets and display objects are statically allocated structs. No
malloc, no heap - A single render call in your main loop renders the active screen to the frame buffer
- No hidden event loop, no background state. You define exactly what runs
Widget and Input System#
- Widgets (labels, buttons, rectangles) are initialized directly on a screen with explicit coordinates
- Several widgets support states such as normal, focused, pressed, checked, and disabled
- Custom render callbacks let you add dynamic visual logic without leaving the safe execution model
- Assign event callbacks to interactive widgets
Toolchain and Editor Integration#
- UI layouts can be authored visually in LVGL Pro's XML editor, with the workflow designed so device-side code can be generated for deployment
- Because the runtime never touches the filesystem, fonts and images are converted to C arrays at build time via converters included in the editor
- The XML editor and code generation tools sit outside the certified runtime boundary, used during development only
- OS agnostic: works in bare-metal, RTOS, or Linux environments, with active integration work underway for safety-oriented RTOS environments
The LVGL Pro editor and code generation tools are development-time only. They sit entirely outside the certified runtime boundary, so they do not affect your certification scope.
Current Status and What Comes Next#
LVGL Safe is currently in early testing and targeting general availability by the end of Q2 2026. It is intentionally scoped: the goal is a minimal, correct, certifiable UI foundation, not a feature-complete general-purpose library. Today LVGL Safe stands as feature complete, and the team continues to write documentation for the ease of certification for product teams.
Teams building regulated products who want to evaluate fit, validate against their certification requirements, or engage on the roadmap are encouraged to reach out now rather than wait for the public launch.
Ready to Build Safety-Critical UIs?
LVGL Safe is open for early access. If you are building a regulated product and want to evaluate LVGL Safe against your certification requirements, reach out to us directly.
Limited Slots Available
