When there is a need to use Qt as part of a system requiring functional safety certification, it is typically best to analyze if the safety critical functionality can be separated. This approach allows the safety critical functionality to be implemented without the need to certify the complete software stack of the system.
In my earlier blog post I explained the fundamentals of functional safety as well as introduced some of the industry specific standards for functional safety. If you missed that, I recommend to read it first. In this second blog I will explain what certification of Qt would mean in practice and present two architectures for creating a functional safety certification for a Qt based system.
What about Certification of Qt for Functional Safety?
Qt has been used in various systems requiring certification, and a bit over a year ago we decided to investigate if and how Qt itself could be certified for functional safety. The analysis was mainly conducted against IEC 61508, which sets the baseline for industry specific standards on functional safety, and automotive ISO 26262. Two separate pre-studies were conducted by The Qt Company together with VTT Expert Services, who is a certification authority for various standards, including IEC 61508. Based on these pre-studies and analysis of IEC 61508 and ISO 26262 it was concluded that it is in essence possible to certify core parts of the Qt framework for functional safety. However, balancing the effort, cost and needed functional changes related to the certification effort, we believe that aiming to get safety certification of the Qt framework is not sensible or meaningful in technical nor business wise. Our aim is to make it easier than before to use Qt in certified systems, and to work with our customers to achieve the certificates they need.
It is possible to use Qt as an integral part of a system certified for functional safety, without changes to the Qt framework. When the safety critical functionality of the certified system is adequately separated, it is not necessary to certify other parts of the system software. Thus it is possible to create a certified system with Qt without certifying the Qt libraries. In the next chapters, I will cover how to achieve the needed functional safety with a system containing Qt and present two alternative system architectures for this purpose.
Using Qt in Safety Critical Systems
If a product, for example an embedded system, contains both certified and non-certified components, it is crucial to adequately separate these. If the safety critical software can’t be reliably separated from the other software, the whole system should be certified for functional safety. In practice it is typically much better choose a system architecture that separates safety critical functionality from the other functionality. Such separation is beneficial especially in cases when the system contains a complex UI and application functionality.
Leveraging a Real Time Operating System
One approach is to leverage a certified real-time operating system for separation of the certified and non-certified software. This is well feasible as Qt supports several real time operating systems that have a proven way to separate the safety critical and other functionality. This approach is especially good in applications where the unique capabilities of the used real time operating system are a good fit for the application’s needs, i.e. the needed functionality of the application is feasible with the chosen real-time operating system.
Figure 1. Using a certified RTOS to separate safety critical functionality.
With this architecture the real-time operating system provides the capability to separate safety critical and other processes. The overall system architecture leverages just one operating system kernel managing both safety critical and other processes. Typically, the real-time operating system can also provide a guarantee that certain functions get run when needed, a feature often beneficial in creation of systems that need certification. As the operating system fully separates the functionality which is not safety critical, certification is needed only for the safety critical parts. Many real time operating systems offer a certified or pre-certified kernel and toolchain, thus using these saves time and effort in system level certification.
Leveraging a Hypervisor
Another system architecture for separation of the non-certified components from the certified, safety critical, parts of the embedded system is to use a hypervisor. In this approach a hypervisor is leveraged to run two or more different operating systems. For example, one for safety critical functionality and one or more for the other parts of the system. Typically, a so called Type 1 or bare-metal hypervisor is a good approach for embedded systems that need to run a separate operating system for certified and non-certified functionality.
Figure 2. Using a certified hypervisor to separate safety critical functionality.
Certified functionality can run on a simple real time operating system that has sufficient capabilities to provide the needed safety functions. Non-certified functionality can run for example on embedded Linux, which offers the possibility to utilize all the capabilities of Qt. As the real time operating system does not need to run Qt or any other complex components, it can be simpler and more lightweight than in the architecture that leverages a real time operating system for separation (and to run Qt).
Having the certified parts as streamlined as possible benefits a lot, as it is easier to implement the requirements of safety critical software and there is no need to certify functionality that is not safety critical. Additionally, using a regular embedded Linux for the functionality that is not safety critical typically makes it easier to implement complex functionality, which can result in significant cost savings for the overall system.
Achieving Certified Graphics
In a Qt based system it is common that the UI functionality is provided by Qt. If there is no safety critical UI functionality, the approach for graphics is very straightforward: Qt can handle everything related to the display without impact to any of the safety critical functionality.
However, if the safety critical functionality includes some UI related items, for example a warning light or a message, it needs to be handled by the safety critical part of the system. This means that the architecture has to allow sharing of the screen between safety critical and regular UI components in a way that guarantees operation of the safety critical functionality.
One approach to achieve such co-existence in the display is to leverage hardware layers of the system to guarantee that the safety critical UI component is drawn to the topmost layer. With this approach the safety critical UI is visible despite of a possible failure condition in the other functionality, as any possible failure in other functionality does not overwrite it. Another possibility would be to handle all of the UI composition in the safety critical part of the system. Having composition completely done within the certified functionality slightly complicates the overall graphics architecture, but is a possibility.
If there is dynamic content mandating hardware acceleration required also for the safety critical functionality, usage of an OpenGL SC certified GPU software needs to be considered. Such approach makes the system design more complex, so it is always easier if the UI requirements of the safety critical functionality are limited. Selection of the architecture for safety critical user interface components depends on the capabilities of the used hardware and operating system, as well as the application use case.
If you are interested in discussing more on the creation of functional safety certified systems with Qt, please contact us.