Qt Safe Renderer Overview

Qt Safe Renderer Overview

Functional safety applies to many vertical industries, such as automotive, medical, and automation. In the automotive industry, it is essential that safety-critical information in the digital displays is rendered even if some malfunction prevents rendering of the non-safety information in the UI (user interface). In medical industry, nurses, doctors, and technicians use safety-critical medical devices that must be safe to use. In automation industry, there is need for well-placed, prominent error indicators.

Qt Safe Renderer provides a solution for rendering the safety-critical information in functional safety applications based on Qt. Qt Safe Renderer is a commercial product, that must be separately purchased as it is not part of Qt's Application Development or Device Creation licenses. For more information about the pricing and other product details, you can contact our sales team. See Contact The Qt Company.

Qt Safe Renderer is designed to be integrated into a system that has a separate processes for safety-critical and non-safety functionality. Qt Safe Renderer ensures graphical rendering of safety-critical information by partitioning the related functionality into an independent subsystem that is run on its own process. Qt Safe Renderer monitors operation of the main UI and 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.

For more information, see:

Functional Safety Standards and Qt Safe Renderer

The objective of functional safety is to avoid an unacceptable risk of injury or damage to the health of people. The following are examples of such cases:

The detection of brake failure in a car and showing indication about this to a driver.
The detection of a malfunction in a medical device and shutting down the device operations as a result of this. Functional safety standards are used to validate that components and systems are safe. The Qt Safe Renderer certification assessment report is based on the following standards:
ISO 26262:2018-6; ASIL D
- Road vehicles — Functional safety — Part 6: Product development at the software level
ISO 26262:2018-8 section 11; ASIL D
- Road vehicles — Functional safety — Part 8: Supporting processes - Chapter 11: Confidence in the use of software tools
IEC 61508:2010-3 – 7.4.4; SIL 3 and IEC 61508-3
- Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements – and Requirements for support tools – 7.4.4
EN 50128:2011 6.7.4; SIL 4
- Railway applications – Communication, signalling and processing systems – Software for railway control and protection systems; Software-Tools
[ IEC 62304:2006 C.7, fit- for-use ]
- Medical device software – Software life cycle processes [relationship to IEC 61508 - best practice]. Up to Class C application The Qt Safe Renderer product contains all the artifacts related to certification, including design documentation and verification results.

ISO 26262 Road vehicles – Functional safety standard ensures functional safety of electrical and electronic systems in road vehicles. IEC 62304 is a functional safety standard for medical device software and EN 560128 for safety-related software in the railway industry. All of these three standards are adaptations of the IEC 61508 Functional Safety standard which covers all programmable electronic safety-related systems.

Typically functional safety standards divide the failure risk into different discrete safety levels. ISO 61508 defines safety levels that are based on whether or not the device is in high demand (used more or less continuously) or low demand (used at most once a year). These levels are called Safety Integrity Levels (SIL). ISO 26262 defines safety levels that are based on three separate factors: severity, exposure, and controllability. They combine to form an Automotive Safety Integrity Level (ASIL). ISO 26262 identifies four ASILs: ASIL A, ASIL B, ASIL C, and ASIL D. ASIL D defines the highest integrity requirements on the product and ASIL A the lowest.

The implementation of the safety requirements and certification of Qt Safe Renderer concern only the Qt Safe Renderer module itself, that is, all the content inside the SafeRenderer namespace. See Qt Safe Renderer C++ Classes for detailed information about the classes in SafeRenderer.

The Qt Safe Renderer installation package contains some examples that demonstrate the Qt Safe Renderer functionality on a host platform and a target device. These examples do not fulfill the safety requirements and cannot be considered part of certified Qt Safe Renderer.

Qt Safe Renderer Use Cases

The safe UI contains safe indicators that are displayed on the screen. The indicators can be safe text, safe picture (single color icon) or safe image. The safe indicators are always working even if the main UI fails to operate correctly. For more detailed information, see the Qt Safe Renderer architecture documentation. You find the document under <Qt Safe Renderer installation directory>/Docs/QtSafeRenderer-<version>/ after you have installed Qt Safe Renderer to your host platform.

The three main Qt Safe Renderer use cases are as follows:

You use the QML Language to define the safe UI and you do not have the main UI at all. By using the related Qt and Qt Safe Renderer toolchains, you deploy the safe UI into one of the reference target environments. This is the simplest Qt Safe Renderer use case.
A more common use case is that you have a separate main UI parallel to the safe UI. The QML language is used to define both the safe UI and main UI. By using the related Qt and Qt Safe Renderer toolchains, you can deploy UIs into one of the reference target environments.
Whether you have defined just the safe UI or both the safe UI and main UI with QML, you can deploy them via Qt and Qt Safe Renderer toolchains to your custom environment, that is, environment that is not covered by the reference Qt Safe Renderer implementations. You need to make some adaptation to the reference implementation for the custom environment. There are two possible customizations:
- The target environment is using real-time operating system (RTOS) that is already covered by the reference implementation but the target environment for the safe UI has different display chipset. Some adaptation for the display chipset interface is needed in the predefined adaptation points in the Qt Safe Renderer runtime software.
- The target environment is using some other RTOS (or perhaps just bare metal) that is not covered by the reference implementation. Some adaptation for the RTOS is needed in the predefined adaptation points in the Qt Safe Renderer runtime software.

Confidence in the Use of Software Tools

The ISO 26262:2018-8 clause 11 addresses the confidence in the use of software tools. Below is the tool qualification, validation aspects, and evaluation support information summary.

Regarding the above use cases, the following methods are used to minimize the risks of the malfunction when using the Qt Safe Renderer toolchain and runtime software components. For more information about the development flow description, see Developing UI with Qt Safe Renderer.

When a user creates a UI with Qt Creator and the QML language, Qt Creator automatically detects possible errors in the QML code and UI element definitions.
When a user builds the safe UI by using Qt Safe Renderer toolchain, the layout tool detects possible errors in the UI safe elements QML code. The error message is given, and compilation fails if:
- Size information is missing.
- Safe elements are outside UI canvas boundaries.
- The source (image) file does not exist.
- A warning is given if the optional ‘objectname’ property is missing (needed only for the safe element move during the runtime). The Qt Safe Renderer toolchain error and warning messages are shown in the Qt Creator's issues tab, or the standard output if compilation is initiated from the command prompt.
When a user starts the Qt Safe Renderer runtime, the generated layout data is loaded and validated. Both the bitmaps and the layout data contain a cyclic redundancy check (CRC) that detects any changes to the data. If a discrepancy is found, an exception is thrown. The runtime also throws exceptions for other errors it encounters such as missing files or filesystem errors. The application developer needs to handle these exceptions. For more information about the exceptions, see Integrating Qt Safe Renderer. Based on the above, and other details in the safety manual, and the installation content (design and verification documentation and source code), the tool vendor has classified the Qt Safe Renderer as follows:
The tool impact class is TI2.
The tool error detection class is TD3.
Based on these classes the tool confidence level is TCL3. For more information, see Supported Development Environment.

Qt Safe Renderer Safety Manual Module Functionalities

Available under certain Qt licenses.Find out more.