LongCut logo

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...

Loading video analysis...