The Qt Safe Renderer runtime component is designed to be integrated into a system that has separate processes for safety-critical and non-safety functionality. This topic describes essential architectural aspects in the Qt Safe Renderer runtime.

The commercial customers of Qt Safe Renderer have access to the module architecture and design documentation. These documents provide more detailed information about the Qt Safe Renderer structure and architecture. After you have installed Qt Safe Renderer to your host platform, you find the documents under <Qt installation directory>/Docs/QtSafeRenderer-<version>/.

For more information about how to integrate the Qt Safe Renderer runtime component into your system, see Integrating Qt Safe Renderer.

Partitioning Safety-Critical Functionality

The Qt Safe Renderer runtime component has been studied for several architectural models for the underlying system. In case of all kind of underlying architectural models, Qt Safe Renderer observes the status of the main UI, that is, the UI that contains all non-safe UI elements. Errors in the main UI do not affect the rendering of safety-critical information. Instead, Qt Safe Renderer restarts the main UI after detecting errors. As the Qt Safe Renderer runtime and the main UI run on separate processes, the main UI functionality does not depend on the Qt Safe Renderer runtime.

Qt Safe Renderer receives a periodical heartbeat signal that indicates the main UI is running. If the heartbeat signal times out, Qt Safe Renderer assumes that the main UI is no longer running.

Qt Safe Renderer is only responsible for rendering the safe content to the screen. Non-safe content is rendered using the compositor provided by the underlying system.

Architectural Options

Software architecture for a system that combines Qt and Qt Safe Renderer breaks one CPU virtually in two. Depending on the operating system used and the level of functional safety certification that is required, this may be possible to do within the operating system itself. If it is not possible, the addition of a hypervisor can keep software in each portion isolated from one another. In either case, the goal is to certify the smaller portion for functional safety while the remaining software can be built using standard practices and existing methodologies.

Using of external monitor component makes it possible to run Qt Safe Renderer on the QM hardware. The control and monitor functionality is in separate hardware with the rendering process. The monitor verifies the rendering output based on the output CRC values and compares the results to the expected CRCs. The output monitor requires the hardware which supports the output CRC calculation.

For more information about the architectural models, see the Qt Safe Renderer architecture documentation and White Paper: Functional Safety and Qt.

Recommended Architecture

Our recommendation for the application architecture using Qt Safe Renderer is that there would be a single thread in the renderer application. The system proxy process receives the system events and controls the Qt Safe Renderer process through the event queue.

Messaging Interface

Qt Safe Renderer takes care of rendering the safety-critical UI in its own process. Qt Safe Renderer uses its messaging interface to communicate via a system bus with the non-safe part of the UI and the underlying system. However, the system bus communication protection is not part of the Qt Safe Renderer functionality. When you integrate Qt Safe Renderer to your own system, you must take care of the system bus communication protection yourself.

A heartbeat signal from the main UI occurs periodically. It informs Qt Safe Renderer that the non-safe partition is running. If the heartbeat signal times out, Qt Safe Renderer assumes that the non-safe partition is no longer in a known good state. If the heartbeat signal stops, the application developer needs to decide how to handle the situation. Qt Safe Renderer keeps rendering the safety-critical UI elements even if the heartbeat signal has stopped.

The main UI can request to position the safety-critical UI elements. The non-safe partition may request to place the UI elements at a certain position on a target device. Qt Safe Renderer ignores illegal position requests and throws exceptions depending on how the sanity check of the layout data has failed. An adaptation of Qt Safe Renderer can catch and ignore the illegal layouts or send error messages about them.

See Integrating Qt Safe Renderer for detailed information about the messaging interface issues that you must consider when you integrate Qt Safe Renderer into your system.

The following Qt Safe Renderer classes are related to the messaging interface:

• SafeRenderer::StateManager
• SafeRenderer::QSafeEvent and its inherited classes

Design and Implementation Constraints

Qt Safe Renderer design and implementation have the following constraints:

• As recommended in table 3 in ISO 26262 Part 6, the module structure is as small and focused as possible.
• After initialization, dynamic memory allocation is not allowed.
• The safe rendering process has only one thread.
• Whenever possible, Qt Safe Renderer follows static configuration techniques instead of dynamic configuration techniques. Thus a compile-time configuration is preferred over a run-time configuration.
• Coding follows MISRA C++ Guidelines for critical systems.

  Note: The MISRA C++ guidelines are followed in the classes that are included into the SafeRenderer namespace. The example code that is part of the Qt Safe Renderer installation does not fully follow the MISRA C++ guidelines.

Qt Safe Renderer System Requirements

To use Qt Safe Renderer, your target device system must fulfill the following requirements:

• System must support partition between the safe and non-safe functionalities.
• There must be independent rendering of safety-related graphical output.
• It must be possible to concurrently render safe and non-safe graphical output.