Changes in Architecture for Qt Quick Ultralite Integration

The original Qt Safe Renderer architecture was designed under the assumption that the target hardware platform supports separate processes and dedicated graphics pipelines for safety-critical and non-safety-critical rendering. This design allows the Qt Safe Renderer runtime component to operate as an independent process, owning the topmost graphics layer and verifying that all safety-critical elements match the expected layout.

In contrast, the Qt Quick Ultralite (QUL) environment targets microcontroller units (MCUs), which typically lack the hardware resources and isolation needed for multiple graphics pipelines or separate rendering processes. Due to limitations such as constrained memory, CPU power, and graphics capabilities, both safe and non-safe UI elements are rendered within a single Qt Quick Ultralite process.

To ensure functional safety, a Qt Safe Renderer Monitor process supervises rendering performed by the Qt Quick Ultralite process. The Qt Safe Renderer Monitor acts as the master controller, forwarding UI change requests to the Qt Quick Ultralite process and employing hardware-backed verification methods (for example, using Discom on RH850) to confirm that the displayed content matches the expected safe state.

The expected Cyclic Redundancy Check (CRC) values for each UI state are precomputed at build time using the same algorithm employed by the hardware for verification. This allows the Qt Safe Renderer Monitor to directly compare hardware-calculated CRCs against the expected values to confirm that the UI is displayed correctly and safely.

For dynamic content, such as changing text, a possible solution is to render the text offscreen using the Qt Safe Renderer library. The offscreen buffer can then be used to compute expected CRCs for the specific content at runtime, allowing flexibility while maintaining safety compliance.

The following diagram outlines the responsibilities and components in an AUTOSAR Classic environment. All communication between software components, as well as between external inputs and software components, is routed through the AUTOSAR Runtime Environment (RTE). To simplify the diagram, the Runtime Environment is not explicitly depicted.

See Adapting Output Monitor to AUTOSAR for guidelines how to adapt the monitor to AUTOSAR Runtime Environment.