 So hello everybody everybody with pants in here everybody with pants at all without pants at home So that seems to be the joke today Welcome everybody to the session where I'll give you a brief introduction to the topic of functional safety This is not intended to be a complete functional safety training. It will not Work as 20 years of functional safety experience with also I do not have It's really for those who want to have the first impression about what's functional safety get an overview and decide Maybe if they want to go deeper into the field or if they just want to avoid it at all So what I will be talking about today. I give a brief introduction to me I'll give you the introduction to functional safety. What do you need to do during development to achieve functional safety? What to do after you first release how to keep up with your safety and then hopefully as answer some of your questions so somebody coming Come in So who is so I'm part of electometers. We are small tech consultancy company Focusing a lot about functional safety software quality. Let's say anything related to software risk security license compliance We are working as independent consultants independent assessors and we provide trainings and workshops, so It's as a founder. So and about me I've been working in production maintenance automotive easy development Many automotive since 1999 Actually, all my projects had to do something with functional safety. So it somehow was something I couldn't avoid obviously and Then about ten years ago I started really to focus on functional safety and to work as a safety assessor and safety expert and mainly in the automotive field currently I'm supporting my customers with functional safety security and the compliant use of open source Projects, I'm also involved here in a few of the Linux Foundation projects I'm part of open chain. I'm in the Elisa medical group and I'm the functional safety manager of the safer project What else? I'm an outdoorsy person. I like life music and Very important. I really I'm really not good with faces and with names So if if I don't greet you on on on the hallway, I'm not ignoring you Just give me a shout out that we know each other. I might just not recognize your face, especially with a face mask on at the moment So What's functional safety? So let's say when I come into projects for the first time a lot of people have exactly these four statements for me Someday it's just part of the daily bulls bingo I should just you know if I say safety and security often enough that they everybody's happy Something It's something I need a certificate for if I don't have a if I have a certificate everything is fine if I don't have a certificate Nothing is fine Some fine functional safety the first time in some RFQ they get from the customers. They have no idea what they should do If this is really important if it changes things they do and For some it's just another but we're like yeah safety security. That's what we do these days, isn't it? at Well, we actually it's nothing of that It's something completely different. So what's really functional safety functional safety? It's Defined as the freedom of unacceptable brisk of physical injury or also of damage to health of people of Goods either directly or indirectly as a result of damage of property or to the environment So functional safety is the part of safety that depends on a system or equipment operating correctly in response to its inputs and Mainly when you have a functional safety system, it's about detecting potentially dangerous conditions Resulting either than in the activation of a protective or corrective device or measure To prevent exactly this hazardous event to happen or mitigating mitigation measures to Yeah, mitigate the effect of the hazard So and functional safety really like to talk a lot about safety risk and harm Safety always being the freedom of unacceptable risk. So really it's not the complete freedom of risk. Everything is a risk Hi Kate Risk usually then always in the way of functional safety defines it is always a combination of the probability of a harm done and the severity of a harm and With harm we in functional safety always mean the injury or the death of one or more persons severe impact on the environment damage of goods and so on and Yeah, I can't say it often enough. It's always to minimize the risk to an acceptable level and usually The definition it's not so easy, but it's easy to understand. It's the risk that is accepted by society so this this can change and Yeah, it's really about accepting and minimizing risk, you know when we step out there we can be hit by a truck When we step out there and we look left and we look right and we take care we minimize our risk to get hit by a truck That's so easy Then I'm not sure and in the English speaking world I'm German and we only have one word that's for safety and security and Let's say generally my perception is people who have to do with safety and security for the first time For them. It's just the same And actually it's there they are siblings with let's say at the moment safety being the less attractive sibling of the two But safety is something different than security while safety Really means prevention and detection and management of random falls and the reduction of Systematic falls by application of processes and methods Security means really the prevention detection and management of malicious attacks so overall we can say there is no need for security if your safety already fails and You get killed by your device before a hacker would even start so Mainly I think most people are interested how to reach and how to achieve functional safety during development so how Do you want it? Do you how can you really? Identify the safety criticality of your product in the beginning How do you start then was development? What do you need to consider and how do you verify your results and? The most important thing here really is consider your safety criticality really from the start If if you don't consider it from the start it will be really really hard to Re-engineer safety into your product Make really sure from the beginning on that you know the physical and functional scope of your product and Analyze what are the worst things that can happen when your system has a malfunction? So what really what are the important points you need to consider right from the beginning? Really know your system and know your use cases know your intended functionality the system boundaries What's your scope? What are the interfaces to the connected systems? What's expected there? What are the use cases? What do you really need to consider in a safety critical way? also know the environment What are the environmental factors your system needs to withstand what what is the load? What are the resources that your system has? to work on and know your intended user know the Will it be a product expert will more be a B2B product will be a consumer product What can it really happen? It really also depends on the user on the qualification of the user and of the use cases at Let's say in safety speak that mainly means yeah Create your item definition or your definition of units of observation your equipment under control definition So I think most people have already heard there's a lot of safety standards and they all call this a different name But in the end it always comes down to know the scope of your system know the interfaces know the use cases know the intended audience So how to start? I've been thinking a lot about What will be a right example? So I'm coming from the automotive domain. I Don't want to be too specific to the automotive. So let's build a house First thing to consider what kind of house do we want to build? So then where do we want to build it? What are the climate conditions or what's the environment? What do we need to consider? What are the interfaces of the house? What the functionality of a house at all? so it just say Very easily we want to build a very small cottage like house two bedrooms max Really simple approach. So we won't have a lot of contractors. We really want to build a small simple house We want to place this house somewhere in a mid-european climate freezing winters warm summers heavy storms But no severe storms no severe with us. So we're not in Siberia. We're not in In some desert. We just have yeah, it can be warm. It can be really cold But it will not blow the roof off The house also comes with interfaces so it will be connected to the water mains gas mains electricity and we will also have a glass father cable and So the intended functionality of our house is pretty simple We want the house to keep us dry during rain warmer winter Protectors against wind have a place of the per for the personal hygiene and a cooker cooking facility and It should offer some privacy and room for our stuff Then I said, okay Know what can happen to your house or to your system? so We need to really start to define the scenarios What can our so doing our has and risk analyzes starting with the scenarios our house or our system can be in so the house It stands there during daytime during nighttime It it stands there during different temperatures so we can put these already in classes And I think it's pretty obvious freezing is one of the classes Let's say a pleasant ambient temperature something between freezing and your normal room temperature. So 20 Celsius 65 Fahrenheit something like that Something that's a little bit unpleasant more than 20 gets degrees Celsius and 40 and maybe above 40 Our house can be exposed to fog to light rain heavy rain light snowfall heavy snowfall and hail so our scenarios then would be the combination of our Situations the house can be in like yeah daytime it and the temperature class is freezing and we have no wind or Daytime it's freezing we have light rain and no wind so more or less a black ice situation Additionally then we would come in and saying okay define the possible malfunctions behavior Like what happens in the situation when we have no provision of fresh water or when we have no provision of heating when we have no rain protection or Maybe when the glass father cable is cut or our router just isn't working properly in the end It then comes down and on the third parameter. It's How controllable is the situation for you in that moment? So we will always have the for the criticality a combination of exposure severity and controllability So when we think back About our scenario saying okay It's daytime. It's freezing The water main is off. We don't have fresh water We can't control it, but it might not be so severe as long as it's for not too long If we have the same situation and the heating is off It looks a little bit different if we have the same situation and our network connection is gone It's very unpleasant. Yes, but it will not affect let's say the The functionality of the house in a way than if the roof is missing or if the heating is missing so Coming back to let's say our classic functional safety standards. They will always give you some kind of way to rate this either in a more generic way or the Domain-specific standards, they will come up with domain-specific scenarios domains domain-specific exposure rates Ideas how to rate the harm how to rate the controllability Just put up here the examples coming from ISO 2626 to which is the automotive standard and mainly work with and based on these tables you then Rate the criticality of your safety goals. So what's a safety goal? So the safety goal is then the situation you really want to avoid or The hazardous event you want to event you want to prevent so you want to prevent a situation Either night or day when it's freezing and your heating will die And you might want to do this with a very high integrity You even maybe even want to you say you want to avoid a loss of your glass fiber Cable signals Because you need to work if you don't work if you cannot work if it's gone you cannot work You cannot pay for electricity. So you have the same problem which might not be so severe than having immediate trust into your house In your house, but maybe you even give it a criticality give it a low one In the safety world we have a lot of critical names for criticality Depending on the standard so the mother of all safety standards the IEC 61548 it calls it still it says still one is the lowest still four is the highest Still stands for safety integrity level The automotive world wanted to do things completely different, but the same so they had the automotive safety integrity level But they didn't rate it from one to four. They said, okay, it's a to be in The IEC 13 8 to 4 which is a machinery standard say they say they want a performance level and Similarly in the agricultural standard they want the agricultural performance level. So in the end it always comes down to a Level that will give you a Value for how how really severe and how important is it to achieve the safety goal or to Enable the safety function to work The standards give your tables again standards love tables Rating which Exposure rate with which Controllability and severity will result in which a level of safety integrity So typical examples for safety goals is for example for an EPS and electrics power steering is That any kind of self steering should be avoided. So self steering means when you move the steering wheel You have this steering support. It's not hydraulic anymore. It's electric or electronic and It should really support you and not move into the other direction because that would mean you could crash somewhere So say, okay It's really hard to control this maybe so we put this an asl. D because you can crash you can die You can't control it. Maybe For an airbag system the average for example that the safety goal is one of the safety goals is the airbag must not deploy if it's not in a crash and You also can crash in the situation where this happens You're usually are The situation not being in a crash is usually very high. So the exposure is very high You nearly have no chance to control the situation so it might also result in an asl D For communicating a safety critical signals on the bus it might be lower depending on the on What criticality of the receiving system expect could be for example an asl B For our house for example as a more generic Example means a Loss of water supply in the kitchen and bathroom must be avoided with a high criticality penetration of rain snow or any other kind of moisture must be avoided also with a high criticality and We said okay loss of signal processing of the signals on the glass fiber line must be avoided with a low criticality so That's a really nice theory if you start from scratch and if you have a complete system where you really know the harm But what should you do when you can't identify the harm? So usually when you're far away from the end application you're a Small software library. You're the operating system. You're the hypervisor you whatever but you don't you're really important But you have no idea what the application is really done if it's a power steering if it's an airbag system You have no idea so what can you do in this situation So Yeah, there there's a standard set phrasing for this means Safety element out of context actually that just means a safety element that currently does not know its context so it always comes with a context and you will need to cater for this context and Actually, I prefer more the phrasing Safety element than with an assumed context The best practice is here is really try to get as much information as possible about the applications that use you or You that use your component and what are the expectations? Do they have a high criticality? Do they have a medium criticality? What parts of your library of your system are used? Then That might result in more or less effort, but that's really always a starting point Then we really make qualified assumptions about the dreaded events of your system so really What are the claims? What do you really want to do in a very reliable and very good way and What should not or must not? fail in your library in the system and Then really based on what you learned about the application that use your system based on What are the situations or the system states that you want to avoid? Really make your safety claims saying okay My library can do this in a safety critical way because it is it can detect this and that and it gives you that error state and It does this with this and that integrity level And so the next thing then really that comes into the mind. What's the safe state a? Safe state then is defined as a state where no harm can be caused by your component anymore Usually it's a state that you encounter that you enter when encountering a problem. So defining really if you detect a problem or Even maybe it's some external system signals your problem You might want to go into a safe state meaning for example completely shutting off completing shutting off your communication Sending maybe not an error signal Removing if you're in a big system was there several motors really remove maybe the talk or apply a mechanical break Reboot maybe the important thing really is think about your safe state Also on component level. What do you do if you encounter a problem and then also? How do you make sure that you stay in the safe state that you just don't forget about it boot up again and then crash? so Then yeah, that's a lot of thinking in the beginning and yeah for me It's what that's one of the most important things because that's where the value in the end comes from But that's just the beginning so once you know what are your safety goals your safety claims What are the situations you want to avoid you really want to start with safety? development developing your system Then usually you define safety requirement that describe within the functionalities You really need to achieve your safety goals that you really need to implement to achieve your safe state You will come up usually With a preliminary architecture You have an architecture in your mind that you want to follow to achieve to achieve your functional safety or also to your normal functionality and This all together the requirements the safety goals your preliminary architecture that results in the safety concept and Think here an open source. We know this concept rather well They all inherit the safety goals safety criticality so for me also safety credit Criticality it's kind of copy left. You won't get rid of it once you have it. You won't get rid of it so usually you do this in a quite a systematic way you take your safety goals and you really go blah blah blah one one by the other defining your safety requirements and Assigning or inheriting your safety criticality level so from do this for one safety Goal to this for do this for the other safety goal you will find in reality that some requirements will in the end work towards more than one safety goal so For our house that for example could mean That okay, we said the house should keep us warm so the house must have a heating system this heating system requirement inherits the high criticality it needs to be traced to its Original safety goals we call this just safety goal heating and a good requirement always have a state So it can be proposed. It can be just a draft can be under review. It can be It it can it can be rejected and it can be approved more or less So For the heating another mechanism for example would be to detect if the heating is off or if the Temperatures are frozen a Requirement could be okay. The heating must switch itself on the moment. It's getting too cold in the house So Really go through your safety goals and define what do you need to? achieve the function of safety so in the end for let's say for our electrical power steering this could mean Because we don't we said we don't want to have a steering in the wrong direction or self-steering You need to detect something to detect the torque of your power steering and Your in the reality you always have Failed a reaction time in a draft state. You might not have everything completely Defined so when you have a draft, it's completely legal to have a TBD still there So go from there go iteratively define what you need an Important point Even from the beginning or especially at the beginning when you come up with your safety requirements and especially when you come up with your safety architecture Avoid dependent failures Defendant failure could be for example the power line can be everything that either Results in a common cause failure which is the failure of two systems With the same root cause or a cascading failure when the fault of one Component of your item causes the fault of the other one so for example I think the easiest example here is our house For example, we said okay, we need a redundant approach for our heating We will have a central heating that's running on the gas that we have on the gas mains and we have in case this Fails we have electrical heaters in some of the rooms First point is okay. Yeah, if the central heat ring is not running if it's failing Switch on the electrical heaters and you're fine So what happens when your power is off? The control of your central heating will fail so even you say okay You don't need electricity to burn gas, but you need electricity to run the control of Your heating so the central heating is off and Your electrical heaters in the rooms off so you have a Common root cause for both your heating systems to fail Yeah, and yeah, unfortunately, there's a cascading failure once you have a Freezing temperatures in combination with this your water pipes Will freeze they will burst and then you have no heating and no water and I know somebody who knows So when you're actually then really creating your safety content concept and your system design You will really see yeah, you have a pretty stable safety concept in Preliminary architecture in the beginning, but once you really go into the technical details defining What do we really want to use what kind of sensors do you want to use what kind of algorithms? You will go into into a more iterative approach where you say, okay This is a technical solution. I want to have I Analyze if my architecture if my solution really fulfills the safety Goals that I have if I can keep up my safety requirements my monitoring my diagnostics and Then come up in the end of the analysis and maybe iterating over your cons over over your technical requirements to a system design and system level or if you just have a library software level requirements so I Said we in safety love to talk about risk and risk reduction So actually in functional safety. We have two measures to reduce the risk that comes with our system on The one hand side we have the claim to have a robust design to have reliable components in our Architecture and to have an architecture. That's actually Suitable for what we intend to do and on the other hand side We say okay, and we really want to develop this in a way that we really have this in the end So aspect number one the robust design Means really create a robust system architecture the architect if the architecture is not robust enough You can apply the most beautiful process on it. You can spend millions on testing. It will still be crap So crap in is crap out No matter how beautiful the processes When we talk about Reusing components hardware components and also software components use reliable components use components you trust use components, you know and Maybe components where you also have a formal proof or that they are useful and that they are reliable in your safety application Avoid common and cascading faults. That's really yeah in your design in your architecture analyze if there are any and Yeah, analyze the suitability of your design will really your will your monitoring work will your diagnostic work Will your safety measures work? Will you have cascading failures? Are you really sure so really analyze the hack out of your system before you proceed? so Here some yeah history lessons something that I also presented two years ago together with Phil Philip Safety architectures so there are a lot of approaches to safety architectures Here just most basic ideas back in history with most the simplest System we can think of it has an input It has a has some processing and it has an output. So here we say okay. We want to launch a rocket We have us our one out of one architecture, which means we just have one path For all the processing we don't have any monitoring and we won't have any chance To see if anything goes wrong in our processing chain We have no chance to see is our input signal right if no chance to see is our algorithm, right? And we cannot even read back. What are we doing in the end? And no matter how much process we put in there? How much much testing this will not be safe There's a little bit better approach would be to have a Two-channel system where we say okay. We have two processing lines both lines needs to come to the conclusion Yeah, it's safe. It's what we do want to do launch the rocket It has some beauty in this approach. The problem is in the end The the availability of the system here. It's oh, you know, I'm a safety person I say okay if the rocket does not launch we might have we might lose a lot of money, but it's safe So another approach will be yeah one of these Okay, one of these are enough it's going back and Yeah, first approach on a On a more let's say sophisticated solution would be a two out of three system where two Pathes and needs to agree that it's safe to launch the rocket I'm coming from the automotive world. This starts to be expensive. They don't like it So the other aspect then is the process so really make sure That what you develop is what what you wanted to develop. So in the end that you have a safe system That means you need solid planning of all your activities You need to have an established or defined process You need to have suitable methods to really implement what you want to do and you need to have measures to verify and to test Why do you need this process? Yeah to ensure that you get what you wanted. It's simple as that you want a house You don't want to have a wall missing in the end and your neighbors looking into your living room You want to have the roof covering? The complete house and you want to have a house actually with windows and with doors to keep your privacy You also know it's not only you contributing in this Project, so you want to make sure everybody is working in the same way. There's a common understanding and By that you ensure also traceability maintainability and verifiability of what you do Actually the process that comes with a safety project. I don't want to call it a V model But in the end it always comes down to this chain. You need to Define a requirement You need to put this in an in an architecture or you need to create an architecture You need to analyze if this is really what you wanted you need to implement it You need to test it. You need to verify it and then start again in the end. It will be iterations about little v's then yeah Walking through this V or your little iterations you will start with requirements management Requirements need to be in naturally unambiguous and complete You need to define your requirements using a suitable description language could be natural language could be more structured language Could be some graphical presentation models, whatever is suitable for your use cases You need to make sure they are verified and complete Otherwise you might end up with just a half a roof if you don't describe it unambiguously that you want to have a full roof and The best practice here to really ensure this is When you write your requirements always add your acceptance criteria So you can it's already a model in your mind saying, okay I want this how to verify that I really got this Then architecture, I think we all know an architecture of an house in the Realms of software that means define your data types define your interfaces internally and externally Define the static and the dynamic aspects of your architecture make sure in your architecture that functionality in data is encapsulated as much as possible and that it's structured in a way that you enable modifications and maintenance I Think implementation is the thing we all know most about Users you to programming language my program language. I speak is C 90. We can discuss how suitable that is Yeah Make sure you avoid the pitfalls of your programming language. Yeah C 90 There are a lot of guidelines how to avoid the pitfalls Yeah Have your variables as local as possible. I don't use magic numbers. No hidden data flow Don't do an unconditional jumps. Yeah Let's say for the seasoned coder. There's nothing new on that make make a robust and stable code and In the end. Yeah You need to verify and test that you really got this what you wanted There are several test methods that you need to consider. Yeah, you won't and you need to have requirements based test You need to test your interfaces. Maybe the interoperability with your environment the robustness how does your System react to unexpected inputs to higher loads whatever fault injection tests really make sure that your safety mechanisms work and What's really? Fancy and done very often in model-based development is really back-to-back tests running the model against the compiled code When you then do your tests and your verification you rate this by test coverage really making sure yet you walk through all Your loops you walk through all your decision points you cover all the functionality you Don't have code. That's not tested. Maybe that would mean this is code That's not specified because if you have requirements base test and you also Walk through all the loops or the decision points that you have and there's some code You cannot reach it's either unreachable code by design You need to analyze this or it's something that came in whatever In whatever way and you might consider removing this or Adding this to your specification analyzing if this has any impact Best practices here are really yet automate as much as possible Check for the basics like Compilability coding guidelines and so on before you allow a check-in and fix your problems as up because they will grow and Much time to wheel The Foundation of everything here is a functional safety management As a foundation of a house Yeah, it's the basis and foundation of everything and everything would fall apart if you don't have this Um Each kind of standard safety standard quality standard they come with a functional safety management and supporting processes They all have some kind of functional safety planning meaning yeah, you create and create and maintain a Functional safety plan plan from the beginning what you want to do how you want to do it Who needs to do it and when do you want to do it? Need to plan your skill management roles and responsibilities plan your verification methods also resources you so we won't get a surprise in the end Yeah, as I said before already you need to plan your requirements management Important point where I've seen that it comes to some confusion is the configuration management So configuration management in the sense of safety standards does not mean Having configurations like yeah something That happens during a compile time it means really versioning branching what do you need to Use to keep your information in will you use git or SVN or some Propriety solution. How do you want to use it? A documentation management so in which format and how do you want to keep all the information you create during your development? Change management, how can changes be proposed who decides on a change? How is the change implemented and verified? Important and very let's say non-loved topic is a toolchain management Tool is the same as a for me as a person it needs to be reliable It needs to be trustable you need to be sure that it does what you wanted to do That it won't introduce a problem into your product or for a testing tool for example that it won't mask a problem that you might have and If you pull in or use Components from a third party from outside really make sure how do you want to quality if they are in the safety path? How do you want to qualify it? Can you qualify it? What are your expectations to? external components then yeah Last point here is really keeping up the safety after your first release Having a safe change management in place so really planning from the beginning What do you want to do or what do you need to do to keep up your safety? When you implement a change because you will implement a change on the one hand side you have maybe some security bugs or you Hopefully have a lot of new features. You want to implement you have requests from users who want new features You come up with new features And you need to do this in a way so your functional safety all your efforts that you put in already are not compromised So really for each change that or change requests that comes in yeah Analyze what would be the impact of the change to the safety of your system? What will be affected? Maybe if you implement this change what components do you need to add to change? Will you have an architectural impact? Yeah, for this you see you're a detailed product architecture is key so that you really can see in an analyzes Do you have a safety impact and how would it impact my safety? document everything That's related to this change to the things actually changed How you changed it when it did it change and verify these changes Usually that means also running all your old test cases as I said automate as much as possible to avoid regressions and In the end it comes down to ensuring that all development all changes that are done To your product in with your change request are verified and tested and are implemented in a way that you did Implement define and test your original product. So that's my short Flight over what should you know from as functional safety basics? I didn't talk about a lot of things because a functional safety training usually is For five days then that's considered then a functional safety basic training I really wanted to give you a first overview. What's up with functional safety? So I didn't talk about safety verification methods. What's an inspection? Why do I need a checklist? What's a faking inspection formal verification and so on I? Didn't go in detail about safety analysis methods FME a FTA STPA I Didn't talk about production maintenance and decommissioning. I didn't talk about safety audits and assessments Certification then so on I didn't talk about confirmation measures Specifics of certain safety standards. I didn't talk about hardware MTT FD PMHF Fit rates this is a I could go on with this for several days. So just be happy. That's just one and a half hours that we have here So say what I want to tell you safety. So it's not magic, but it's a complex topic So go through it step by step Ask questions if you have them The worst thing that can happen that you have an unsafe product because you didn't dare to ask So just thank you everybody for being here. Thank you everybody for being online Yeah, any more questions So Just so your question is are there already measures like your graceful degradation and open source software that we could detect maybe by Analyzes or scanning or what? Yeah, yeah, let's say actually Safety and open source. It's something that's still in the let's say Kate just stop me if I talk nonsense, but it's something that's still in the starting phase so there are several projects that have functional safety in mind and That come up step by step with the measures they need from safety claim to maybe Qualifying existing parts of the software Identifying exactly what you said what you need or what you might need Is other already maybe from the quality side or from the stability side? degradation measures detection measures, but there is no let's say no one Exact same approach at the moment. So it's really something where you manually Need to ask the project or need to analyze the functionality of the code Is there something in there that you can use for this and Then somehow trying also to get let's say the systematic integrity into it To make sure that it's exactly doing what you expect it to do But unfortunately, there is no one fits all solution at the moment Yeah, I think yeah, at least someone might be the hook-in point for you because yeah Naturally, it's very hard when near and it's I think that's the architectural group That's really working on what are the safety measures that we can identify, right? Okay Yeah, so the virtual meetings usually are in a friendly time for the US Kind of friendly Okay Yeah, I do have in Munich my Elisa called at 6 p.m. So Yeah, what we can facilitate take the times in between so it has a good and a bad welcome Any more questions? So if anything comes up You can find me via email You can find me on github and Twitter you can text me on linked and Stefan would Contacted me today in the morning. So usually I check these Just if you have any more questions don't hesitate If I can answer it, I'll give you answer if I can't I also will tell you that I can't Okay Then thanks so much for being here