Certified Functional Safety with Qt Safe Renderer {On-demand webinar}
By Qt Group
Summary
Topics Covered
- Pre-Certified Components Don't Exempt the System
- Higher-Certified Components Work for Lower Needs
- Iterate on Safety UI Without Recertification
- Two Graphics Layers Protect the Safety UI
- Heartbeat Signals Drive Main UI Recovery
Full Transcript
hi everyone thank you for joining us for our webinar certified functional safety with QT surrender my name is Erica and I'm going to be your host today for the
zoom platform itself just to do a couple housecleaning items before we go to the meat of our presentation here first of all we are recording this webinar we will be making it available to
participants within the next couple of business days also if you have any questions we do encourage you to ask them you can ask them in the Q&A box at the bottom of your screen you should see
a box with the Q in it to be able to click on that we will be answering all questions at the end of the presentation so with that I'd like to hand that over to our speaker to the day for the day to
go turn in and let to that you take it for you thanks Erica so hello everyone my name is - Catherine I'll be talking about how to get certified functional a
bit skewed safe render the presentation will be about 30 minutes so a bit more and then there will be possibility of
asking around some questions at the end if if there are any coming from the audience you can write the questions during the talk at whatever time and I
will then look at them towards the end of the end of the presentation so first
we will be discussing just briefly on bodies functional safety and what kind of a stunned us there are then we look into a few different ways and architectures how to create a certified
system with cute and then we dive into the cute safe render version wondered Oh which is currently available and then the upcoming safe and there are one but
one then summarize and have some some time for questions at the end so what is functional safety the goal for a safety
is to protect people from getting hurt it is always based on active systems to detect and prevent problems so if you
have some passive system like let's say if you make a change so you might have a base to not put the fingers in that typically isn't considered
functional safety rather it is a bit more advanced systems that are then there to see and possibly unsafe
condition and then take actions to to prevent them the picture that is shown you can see that the accident has
happened but and there's been quite a lot of damage to the vehicle but the driver which is there seems to be
relatively in good shape probably feeling a bit sad about totaling the car
but otherwise seems pretty good consider condition considering how bad tomato is
so there has been in this case some multiple different systems properly
operational and successfully preventing the person from getting hurt the
functional safety is measured by safety integrity level in automotive or automotive safety next level which is
determined based on the how likely your system is to cause an injury or death so in this presentation I don't go into the
into the mathematics of it and how to determine but rather we can approach typically from the viewpoint
that in different kinds of systems there is a level where you wanna go and then
the solutions that you take need to be done according to the level that you want to reach different industries have
different standards the main standard for functional safety kind of a mother of all standards is to I see six point five oh eight in some industries that can be applied directly
and in some other industries or in some industries there is a derivative of the standard in use some provide just small
additions or clarifications over the six one five or eight and some are rewriting it but the same principles apply so
let's then take a look into what it takes to create a certified system with cues so first of all the complete system
needs to be certified so it is good to use pre certified tools and components because that helps in certifying the whole system but it doesn't even if the
system is completely peeled from pre-certified parts it still doesn't mean that the whole step wouldn't need to be certified it just makes the
certification easier another important aspect is the separation so when making a system typically always there are some
functionality does that is safe to critical and some that is not and if the system architecture can be done in such way that the safe to turn parts can be
separated from the other parts it means that the certification activities can take a deeper look into the safety reports and for the other parts it is
adequate that they just do not interfere or cause harm for performing the safety function and do with this approach it's
completely possible to use the full cute in the system without any changes to cute libraries in the non safe critical part and then for say two critical paths
if that consists a user interface you can use the cute safe render if the safety kernel part does not contain a user interfaces there might not be any need to do with the safe render itself
the separation is adequate I will look into a couple of examples and architectures how this is done typically in conjunction with with when cute is used the system does contain a user
interface therefore safe renderer is often very much needed so let's take the first
look into a simple architecture where we have a real time operating system that is certified to provide the separation between a safe to cradle and non safe to
critical processes in this example we are using regular cute libraries running on top of the real-time operating system and create for creating the main UI of
the of the device for example with cute quick would be be tense as well it doesn't matter and then we have on the safe typical side we have the cute safe
render and tend to save you I created with that and the real-time operating system is doing adequate separation for
the processes therefore no other criteria is needed in the higher levels of safety this approach cannot be used
but in many cases the required level of safety is adequately low for being able to use real-time operating system for
separating the safety critical and the other functionality and as I mentioned the previous slide of course it could be that there is no acceptance st physical
UI that's all needed the safe your functionality could be something other than you are related all the safe treatment of UI can be created with for example simple warning light or similar
in that case the safe renderer is not needed but in many cases it is beneficial to have a bit more user interface created for the central
functionality and then using the safe renderer is very valuable if we take another architecture with a bit more
complicated device we have a hypervisor so called type 1 hypervisor providing the bare metal hip a vision and
separation for operating systems on the safety critical functionality side we have again a real-time operating system certified for functional safety and on top of that we have the good safe
renderer and say you can of course be the police are the logic as well to get the events and to react to the safety functions and then
in the other function on this side we have a non-certified operating system for example linux and then again cute and the menu I created with this so
pretty similar architecture as before but instead of having two operating system to provide the separation we have a hypervisor to do that and obviously the hypervisor there needs to be
certified either using a predefined hypervisor or when creating the system then making sure that said that the hypervisor can't be certified for safety
on the system level then with more complex example where we have again a hypervisor
but we have also multiple domains of the UI and this is in a way a combination of the first two approaches so we on top of
the hypervisor we have the operating system that is not safety critical for example Linux on top of that we have a
user interface a done with cute and then on on the same physical side we have the real-time operating system which again
has another instance of cute and another UI of the system created which is non safe technical and then we have the
safety critical you I created with kill safe render and the benefit of this is that we can still use the same SOC same
hardware no need to duplicate the hardware between two different systems because the adequate separation is created by the hypervisor at the
real-time operating system it's completely possible to do the separation also in hardware so basically we in this
instead of hypervisor we have completely separated CPU they can't be on the same silicon some silicones provide for
example of microcontroller similar to run the safety ground functionality and then more powerful CPU
to run the other functionality so in this we have the real-time operating system safety certified and the kid safe
render and safety why running in one processor and the other functionality for example in hoops running cute and
the main UI on a different processor that was a quick look into a couple of different architectures let's next dive
into the cute safe renderer and see how that can be used to create a safe - critical UI so first the cute safe
render has been certified we got to certification through in May for the version 1.0 according to four different
standards for functional safety which are listed both of course in the certificate itself as well as on the
left-hand side so on automotive we have we are certified to a cilldi which is the highest level and then on the sixth
one 508 it's the second highest so basically steel tree on rail where we aren't ill for which is pretty high
again the highest for the railway safety and there often is a question that what if I only need for example a Silby what
can I still use the safe renderer even though it's certified higher and the answer is just yes of course so we have been we have certified the safe render
as high as it was possible to certify in typical cases when user interface is needed you don't need to go to a CD is
in a or b for the motive fully fine same often for the general industry standard so still one or two often are completely
fine so it doesn't cause you any any issues but in the other way around if cute surrender was not certified as high as
you want it to then you would have need to take would take additional steps in certifying the complete system often
when you build a system you might need to have for example like if you want to read say a seal be that of course means that you should pick the real-time
operating system for example that meets the a Silby requirements and graphics and unsimilar and then the safe render in consumption this kind of system
operates according to the ACB requirements resistant set and provided by the other components in the system so what does the cue safe render contain
what does it do its contents to certified components it has development tooling that integrates to a visual
designer of UI and it contains a rendering component for the central UI that runs in the target system it provides in the Crescent to the
real-time operating system for example QNX 7211 and also safety variant of kianak 7 obviously so safety 2.0 which we are certifying with the one that one
dream is and it runs off multiple different Hardware a couple of examples there but basically you can run on whatever hardware is supported by those
rater operating systems that we run on and as I mentioned it's certified according to multiple different standards on the pictures on the top one
you can see an example of the cute fig designer tool that you can use to design the UI both the safety turn
functionality and other functionality and then on the picture below you can see the complete system running on an iMac 6 Art Fair
convenience for creating the central UI is the most important thing that we wanted to achieve with the safe render in addition of course being safe safe
and feeling the criteria because often the safety critical software is quite difficult to use it might be cumbersome to change and we want it to being a
tooling company we wanted to change that therefore we created the setup in such a way that you can create the same physical UI as easily as you do other
you are with youth using UML good quick as the language to describe it using obvious well-designed tools to create a safety critical UI as well as the other
you are and then tooling that separates during the final build the safe traditional parts from the other parts and then prepares them for being
rendered with the safe render we have also added a convenient library for different ISO icons for warning symbols
you can obviously use also other symbols this is just a standardized set of multiple icons that can't be rendered
with the safe render as I mentioned you can design fully in qml there are a
couple of examples of of safe qml types that you can write into your quote or design with visual designer and then the
tooling will not notice this and take this out from the kml part and create corresponding safety physical parts so
we are not running qml in the safety certified parts but we are using UML as the tool with which the safety vehicle you are is created alongside the other
UI and then on the rendering part it is done using a mr. C compliant renderer component here is a picture explaining
the same thing so on the top you can see during the development you can do it just a normal build for this everything is SQL also to
safety-critical parts you can prototype you can iterate and then when you do built for the target the tooling will split the safety critical unknown and
the other components and the safety chrome parts will be created and put to the safe renderer to render for example
the Dell test whereas the other UI parts are rendered by normal cute and this has two added benefit when you want to
change not if but when there comes a need that hey actually make those icons a bit picker and move them to top instead of bottom so you can just do the
change in the tool like you do for also the older non safe components and again do a build and you're safe renderer can
render this without any changes to the same critical code fully generated so you don't need to touch at all you don't
need to recertify at all any code that you have written for the system safe
little UI in the version 1.4 render speech maps as well as text paste take into the pitman bitmaps and i will be talking about that one a bit later where
we increase a bit more advanced support for text the render is created with mr.
C++ 2008 fully compliant with that specification we have done extensive testing and a lot of documentation so as
part of the kill safe renderer you get full safety manuals you get all the testing documents all the certification assets that you can
give to the certification Authority when you certify your system and similarly you get those for the other parts like three Ultima products and so forth and
with that the certification of your complete system is much easier dexter of cute surrender is shown here
as an example so the safe render has no dependency to main UI the real-time operating system separates it fully from
the menu i it can listen to the heartbeat from the main UI which often is is valuable because with that way it
can detect possible problems in the main UI and if you can also control the menu but the main UI doesn't control the safe
render because then it could cause problems if the if it would do the
controlling wrong so it does send heartbeat which allows to say render to react so and also in this picture we are
explaining the how to is drawn to different layers but let's look a bit into the next slide where the layering is maybe a bit more visually represented
because that's often it's a question that what if the other UI goes just completely crazy and and draws all were there safe typical UI how to prevent
that so this is done typically by create by drawing the graphics in two different layers and most modern hardware supports two layers graphics and all the
certified tips that was mentioned they all provide this capability so we basically give the hardware topmost
Hardware layer for the safe render to render therefore no matter what is drawn
into the other layer it doesn't over draw so this way it can be made sure
that the shade physical paths are always visible typical operation of the kid
safe render it's done now here's a sequence diagram explaining to the operation it's typically done in such a way that the communication of the main
UI and safe renderer are minimal there's no dependency so when the safe
renderer gets event from the safety critical part of the system for example an interrupt or whatever level you might have some protocol implementation that
listens to failure states and then when it has the event it will start drawing so the safe render is as it names
success just a render in addition you will need to create the code that commands the renderer to render into a
safety critical side so that can't be pretty simple if you if you have only simple needs for the rendering and if you have to pull different false dates multiple
different pit pops then of course the complexity of the situational crowd grows and there's no limit in assets how much does a friend or a can render it depends on the on the system needs so
it's very flexible in in that sense in here we can see an example how the main UI recovery works so basically the main
UI since the heartbeat and butcher is listening to the heart beats when if there is no heartbeat within a given
time frame then it can start the main UI recovery process as the xscape here it will be able to ask the menu our to
restart and it can also display message and error message or similar to react so
that the user knows that the main UI has has been lost with the one that one version of the sales render that we are
currently developing you can do a bit more but first on the availability so our current understanding is that we
will be able to provide the version 1.1 with the same levels of say certification that is available for the 100 during the first quarter of next
year so we are currently in the testing phase and we during November November we expect to be able to send all the certification assets to the certification agency and then depending
on their schedules and depending on how many rounds we need there will be then some iterations and after that the certificate is expected to be granted to
us somewhere during the first quarter of next year three most important features that the safe renderer 1.1 adds are two
dynamic text render which extends the safe text functionality of one at all so that we can provide dynamic text the
text content and color can be changed this of course allows also to so numbers like to speed for example or dose its it
another important is that it supports large icons so in the 1.0 we had the limitations of the icon size so that it was mostly for the Telltale's but now we
can provide lots I comes for example to draw the background which makes it easier to create the safety-critical UI especially in the failure state and then
we also provide the possibility of overlapping icons so that multiple tell texts can be toggled in the same
position unlike in the one at o in the picture on the top right hand side is an example of a safety UI that can be created with the one at one so the
Lord's icon support allows to draw the background which is good in the sense that even though for example in this in
this case we have lost the needles of the cases the user still sees the outline of the instrument cluster making
it more easily to understand that the system is still operating but it has gone into an error State we use the text
functionally to draw to recovering message and that can also of course display multiple steps of the message and we use the dynamic text capabilities to display the speed equally we could
display for example the gear information and other things that are considered important to give to the user even in the failure state of the system and of
course the Telltale's just like before but now also possible to overlap and create multiple icons to the same location industry
moving to the summary part of the presentation so the option objective of
the functional safety is to avoid unacceptable risk or injury to people so
it has active systems that try to detect the state that can be harmful and then act accordingly to avoid or minimize the
harm that is done to the people there's multiple different standards the industries that your you are working on and the regulator's set the standard and
demand what you your system needs to be filled so you typically don't need to when you create the system you don't need to fulfil multiple standards but
from the cute viewpoint because we work and create solutions for so many different industries we have chosen to certify the same vendor according to
four different industry standards to get the wide coverage of different needs for the functional safety the functions are always the complete final product is
certified you can use the Q safe render to create the safety critical UI and it's beneficial to use pre certified components such as the real-time operations hypervisor
if you don't it's not necessarily means that you cannot certify the system it just means that you need to do quite a lot more paperwork so in practice those
are often used cute as the technology is well suited for three different systems in such way that you do the separation
between the safety other functionality and this allows you to use cute without any changes in the other functionality
pod and then the safe renderer for the safety robots and then obviously as I mentioned we have to
wondered Oh available now you can take it for spin contact our sales ask it for evaluation try it out and one that one is under development and coming quite
soon with those couple of added features that I described and the resistance for further needs is available from through
our service organises so this was a walkthrough of the cute safe render and creating safety critical systems with
cute I described the one that Overson and also a bit what is coming in the next version during the first quarter of
next year now we have a quite good time for some questions if you have any just type it type and I'll be happy to to answer at the moment I cannot see any
questions asked so there's nothing to answer yet but I
will be happy to honor if any one of you want to type those okay if not then I want to thank you for
the interest and joining the webinar oh we have a question yes the question is are there any other safety certified
relative approaches the options in the pipeline so currently we are working we provide out of the box
support for integrity and cure necks and the connect source for safety but of course we are always happy to hear about
other needs and if you have an operating system that is certified it is probably rather easy to run the safe render on
that operating system for the other parts of the cute it is a bit more
tricky so if you would use some of the other real-time operating systems that do not already contain the possibility of running youth you probably would take
the architecture that you would run cute for example on linux and then only the cute safe render would be run on top of the other relative operating system so
the motion question for example towards safe artists so should be pretty straightforward we haven't tried it but as long as the
real-time operating system that you have can run misra C++ code which typically they can then it should be able to run
to safe renderer there might be some testing involved so we have provided the full testing on those platforms that we are supporting so you would probably
need to then need to prove on the system level that you have tested adequately that all the corner cases are filled and
and so forth other than that I see no problem in using whichever certified great an operating system I mean basically cute safe render could
even run without an operating system just running on directly on controller then it's just the challenge in this case is that you often need to
have some process to create events between Sui render and then the comb when you do that you often benefit on
having an operating system so but as a technology to save render wood would of course run very nicely basically on on anything it's it's relatively simple
simple render so I hope this answered the question so not out of the box but should be pretty straightforward and not
not a big effort overall to certify the safe renderer in other real-time operating system than those that we support out of the box and your
certification agency would probably be happy to see the test results that we have gotten and the test cases that we have run on the other OS and then you can yourself run the
tests on the other on your own real-time operating system and when it results are the same I wouldn't see any issue in in
getting the system certified ok so and that was all the questions that we had thank you and the recording will be
stored as Erica said in a couple of days you should be able to get that and of course also this will be later provided as an on-demand for those who weren't
registered or listening can still comment and watch the recording later on thank you and bye bye
Loading video analysis...