 Felly, mae'r gwneud yn fwy hwyl, so mae'n chweilio i'n cael ei swyddfa amser ac yn ymerddur gan y ddweud. Mae'r ddwy ffa tewch yn ymwybod i'n chweilio i'r cyfasydd ymddangos cyfysgddiaeth, mae'r ddweud i'r ddweud i'r ddweud i'r llwylliant, a'r ddweud i'r cystafllwyr yn ymdweud o'ch cyfysgffredig. I'm going to try and explain why that is, and also some work that Code Think is doing to try to fix it, particularly for Linux-based software, but also more generally for open source. So the work that we're doing is not just about taking one Linux operating system and trying to certify that, it's about how we would do that systematically. So here it goes. So I'm going to talk a bit about safety, what people think of as safety. Then I'm going to talk about certification, which is somewhat different from that. And then I'm going to talk about our method, which we're calling RAFIA, because it's nice and catchy, and hopefully people will remember it. Then some of the things we've learned, and then where we're going from here. So people talk about safety critical systems or safety relevant systems. That's broadly systems that could cause harm if they did something wrong, or are expressly trying to prevent harm happening. These days loads of those systems require software. I don't know if you've realised, but pretty much all of the safety critical systems in your car these days have been driven by software since pretty much the 80s, right? So drive by why it was happening from the 80s onwards. These days, every time you press the brake pedal, there's software telling the braking, whether it's a disc or whatever it is, to actually do the braking. So we've been relying on software to achieve safety for a very long time. But these days we're trying to make safety demands of much more complex systems. So it's one thing to do a microcontroller serving a braking system. It's quite another to munch all of this software, including a whole load of AI machine learning models into a big multi-core processor, and then hope that that's safe. So we're on a journey, aren't we? As I said, most of these systems, most of these solutions that claim to be safe are proprietary, and there are good reasons so far why open source has not been properly considered, I would say. So when we get to an organisation trying to make safety claims, they can say, oh we think we're safe, but then someone's going to look from outside and say, how do you think you're safe? Why do you think you're safe? And that will boil down to have you complied with standards, and there are a whole plethora of standards. The kind of parent standard of them all is this ISO 6158. I'm sure that most of you here haven't read it because it costs 2,000 euros or something to buy a copy for your personal use. So I'll be very surprised. ISO 26262 is cheaper, I think it's only about a grand, but you can see already why this little interest in open source people, why on earth would we pay? To access that stuff, which was written by guys some decades ago now. But I'm not saying the standards are completely useless, they're not. They have lots of interesting ideas in them and lots of well-learned lessons from big systems and complex systems in multiple industries. But in practice, to read the standards, digest them and figure out how you're going to adapt all of your stuff to satisfy them, it's a big undertaking. It tends to be done by commercial organisations and you end up with VxWorks, QNX integrity. So Green Hills and QNX are still very active, Wunder River is still very active. And they kind of have a domination of the safety critical operating systems market broadly. And you ask why isn't Linux or Zephyr even at the moment being used in safety and the real answer ultimately, when people say it changes too fast or it's too big or whatever, but what they'll really boil down to if you push them hard is well, it's not certified, we can't use that. Now ISO 26262 is a standard that particularly rates to automotive and for those who don't know, code think is relatively active in automotive, about half our work is with automotive OEMs or the people that make cars and sell them with the T1s who supply systems to those companies. So this standard determines whether something is safe for use in an automotive system. And it not only specifies things about software, it specifies things about how you would manage software, how you would engineer it, so it's a whole load of stuff about processes. And again, open source, I categorically assert that most of the open source projects in the world have little to no interest in complying with the kind of processes that were invented by those guys contributing to an ISO standard some decades ago. Really, a lot of the processes that they specified were waterfall, they predated Git, they predated CICD, right? So it's just a shitload of paperwork, which frankly no one these days has much interest in. But still, as I say, there are some valuable things to glean from those standards. It's just it's very hard to make open source aligned with them. Think about certification. Certification is not safety. Certification is someone independent, someone qualified, someone who understands the standard, comes in, looks at your process, the way you're working, your software, and gives you an assessment that says, oh yes, we agree with your assertion that this is safe. But frankly, we could get a certificate for a know-up for some software that did nothing, provided the process was right and the management was right and the coding standard was followed. In practice in automotive, and Arm did a research project into this, and I'm going to quote Chris Temple from Arm who last year said that they looked at an actual automotive project and found that there were 100 different certified safety components. Each of those components makes its own assumptions of use, which is pretty much saying, oh, and you've got to do this stuff safely because we're not doing that. So imagine bringing 100 of these things together and someone has got to wrestle with all of those assumptions and try to make a safe thing out of the result. It tends not to be as easy as it seems from just putting together 100 things that are certified safe. I'm not going to name names today. Normally I do name names and I swear more than I'm going to swear today but I can see that the camera is on so I'm going to try to avoid it. I could, if we were so inclined, certify a microkernel, couldn't we? And then we could say that it does these things absolutely safely guaranteed, but then we could exclude all of the drivers, couldn't we? And then we could have a viable business which could actually dominate an industry. That is the state of play today, kind of ridiculous, but that is the position. Now, ISO 262 demands that you have requirements, architecture, traceability between the requirements, code and code analysis. So right at the end, as we've been on our journey, we discover that ideally ISO 262 would like a description for every single file that contains C code showing what it does and how it's intended to work. Imagine the gargantuan task that would face us trying to retrofit all of that stuff to Linux, just the kernel, never mind the whole operating system. So it's a lot of hard work. Now, in practice, there is at least one example where an organisation has done that. There's a company called Wittenstein, I think. They took FreeRTOS, which I'm not sure how many lines of code it is, but it's not very many. And they went through a process of, in effect, reverse-engineering or retrofitting all of this documentation, and they achieved something which they call SafeRTOS. There was a vulnerability in FreeRTOS' network stack. I did ask Wittenstein in public whether SafeRTOS had already established and fixed that vulnerability, but no one replied, so I don't know. Maybe they did, maybe they didn't. So, where people have tried to certify Linux, they've mostly failed. The few successors have taken a very specific version of Linux and hardened it, chopped a whole load of stuff out or turned stuff off, and then they specifically say you can only use this subset of the functionality. So, it's kind of a crippled but guaranteed version of Linux Lite. Where people tried to do the whole thing, the scale of the task has overwhelmed multiple teams. There's some work, I think Red Hat and others are in the process of working on this PAS, which is an addendum, in effect, or a revision to try to bring new practices, but that's a long way away from becoming accepted. So, at the moment we're stuck with in Automotive ISO 2662 is how we would mark our homework. And, as I said, it was written so long before and it really does not take into account, even the 2018 version still does not take into account things like Git and CI CD, I'm afraid. So, from our point of view as software engineers, we can categorically say that we would take our modern techniques over your old paperwork any day of the week, but I've given up trying to argue with people about standards in public because they don't like me. So, just to get this point across, I've shown these diagrams before, I'm going to do it again. So, when originally the thinking that led to safety standards and safety certification was happening, this was the kind of picture, so we would have some certified tools making some certified software. More than 20 years ago we ended up with this kind of situation where there's a shitload, sorry I've sworn, a shitload of software which is not certified in the environment and also another humongous load of software which is not certified in the target. And now we're into that plus all of this virtualisation, hypervisor nonsense and machine learning. So, good luck on claiming that your whole thing is safe, right? So, from Coddick's point of view, that whole certification stuff is kind of a sideshow. We are software engineers, we're helping customers to deliver real product and we know that it's important so we're trying to do the right thing from a software engineering point of view. Apparently this idea of the Romans or the ancient bridge builders being required to sleep under their bridges is apocryphal. So, it didn't really happen but it's a good concept. So, we internally in Coddick do talk about, we're not aiming for certification, certification is a byproduct, we want to actually believe from a software engineering point of view that we have a safe solution. And that actually has allowed us to, first of all, avoid the traps that the standard might lead people into but also it's given us a strength of purpose and a belief which allows us to push back when the standard is demanding stuff that we think clearly it's not necessary. And to be fair, the standards do allow for, if you've got a better way of doing something then document it and explain why and that can be considered. So, that's in effect the path that we're on. Okay, so, Raphia, as I said, hopefully a catchy name, people will remember it. It's specifically an approach for dealing with huge software, software that's connected and therefore because it's connected it's going to be subject to potentially security implications and we might need to update it in the field quite frequently. It's specifically taking into account that a lot of the stuff that we're going to use is open source as well as custom software and it takes into account that the kind of projects we see, the software is never finished so it's going to be developed on an ongoing basis and that means we would need to make the safety argument on an ongoing basis. We need no point in certifying something once and then, you know, three months later everything gets updated and our safety argument is defeated. That would be a shame since it's still going into a car. And the other thing we have to handle is multiple suppliers so open source plus vendors of this, that and the other. We know for sure that traditional safety engineering approaches don't get to this scale. We were asked about this by Bosch in 2016 and we have literally been walking slowly on this journey ever since trying to understand how we would help Bosch and others to make safety promises around this scale of software. As of this talk, I think it's the first time I can actually say that and I'll show you why, we believe we'll get an ISO 262 cert for a Linux based operating system. So just to give you a broad understanding of what RAFIA is, it's more things than just risk analysis, fault injection and automation which is how I originally coined the term but the others as you can see we can't pronounce. So it's a combination of risk analysis and we achieve that via STPA. I'm not going to bore you with STPA at this point that there are lots of presentations online about STPA. It's a methodology established by MIT. There are some problems with it for software. It's not really designed for software specifically so we had to do a lot of work around how to make STPA work for us in our specifics scenario. We combine that with testing to verify that the risks we identify don't occur. We then use fault injection to prove that our tests work and that we can cause the risks that we've identified to happen and then we can use the results of that to see what the implications are, what mitigations might need to be taken against the potential that the software misbehaves because ultimately we're not aiming for bug-free software. That ship sailed decades ago. By the way, on the code coverage stuff. Tall nonsense, I'm afraid. You can have 100% coverage and clearly still not be testing anything. Just because you put a test in to say this code path happens does not mean it does the right thing when it happens. We see many projects crippled by hitting that coverage metric so people end up writing as much test code as the target code but no one's testing the test code, so who knows. In order to satisfy the standard, whatever approach you take, you've got to generate evidence to support your assertions so that becomes then a big part of the work. We establish a reason why we think we can be safe and then we need to demonstrate that we're complying with our assertions of how we work. Great thing is we've got CICD so we can automate most of that. STPR said I won't bore you so I won't... I'll just leave this. The slides will be published afterwards obviously and as I said there's plenty of resources around for STPA and at the point that we get to where we're going this year we expect to make hours detailed explanations of how we use STPA and how RAFIA works open source and public as well. Broadly it's a structured approach where you start by defining what you care about and then you work through a modelling exercise to get to what are the key outputs of this which are unsafe control actions, things that if they happen then harm insurers or hazards are triggered and then that leads to analysis which we can use to form the basis of automated testing. That's a crucial thing. In practice automated testing means we need to be able to verify the behaviour of software at all expected states during startup, during shutdown, under stress as well as normal operation. This leads to a load of automated stress testing in effect and also we need to break those tests on a regular basis to prove that the tests are really doing what we say they do. I have to tell this story. Back in 2011 or 2012 it was we were working on an automotive project and every day there was a test results email got sent around to test results, test results, test results. After about six weeks one of our guys opened up the email was interested to see and it was just a spreadsheet. Clicks on the spreadsheet and there's only one cell filled in and the cell says Valgrind not found. We need to know that the tests actually do what we think they're doing and that the results are what we think they are. We use fault injections as a way of checking our homework effectively and I've talked previously about how trivial it is to do fault injection. Any software you give me, if you give me the source code and say it definitely does this, I am absolutely sure that I or one of my brighter colleagues can break it just by changing one line of code. We can definitely make it not fulfil the promises. So we can use that principle to check our tests and also to generate broken versions of the software to explore whether our mitigations later in the process work. And we think that's innovative and our certifying authority has confirmed as far as they are aware no one has taken that systematic approach to software scale in this safety context before. So that's I think the key trick that we're using to maybe break the log jam. I've talked about that so I'll skip. How am I doing for time? So compliance, now historically compliance means you get someone reviewing your work and they will ask for your requirements specifications, your design architecture, your test results, all of this stuff and then there'll be an ongoing engagement to review and assess. And that's frankly where we are still at today. Working with Exeter, who we're very comfortable with now, we spent some years with them on figuring out the wrinkles of this process. We did achieve an ACLD tool certification for our tooling and some of the core integration approach in 2021. And one of the good things about that proof point was that we managed to do that without even bothering about whether the software was open source or not. In effect it's GitLab and a combination of techniques that we learned from and have applied since the reproducible builds project. The fact that it's open source is just not relevant. We managed to demonstrate that the result is what matters and we could use the results to verify. We could also use the results of that discipline to confirm whether anything in our tooling changing was going to actually affect our output. So reproducibility gives us a clear checkpoint to say if we want to change anything, do we still get the same results as we used to? So that's been a great trick. So the compliance process now, we're working towards continuous compliance and I know other organisations have made claims about that. That's going to reach wide changes on both sides of this equation. Exeter is, we would assert, approximately at the state of the art of safety and cyber security certification. They are still heavily manual and relying on interviews and reviewing manual documents. They're not yet at the point where they offer an API which we push all this stuff into. But I would suggest within a few years that's where everyone would want to be. We'd want to be having a standard way of presenting evidence and getting assessment mostly automated so that the experts can focus on understanding whether the argument really holds up and doing spot checks to work out whether the things are lying or not. I've made it sound simple, haven't I? That's quite simple. So that's a reasonable picture of the kind of approach we're taking. As you can see, there's a whole load of stuff that ends up in Git. I'm not going to go through all of the steps. All I would say is that it's normal CICD but plus risk analysis for safety and then some extra steps around fault injection and automated testing for mitigations, as I've said. Everyone get a picture of that? Good. Then we recognise that iteration is bound to happen. We can't get anything right first time and I still come across, certainly on mailing lists, people saying, oh yes, we deliver software right first time. Fantastic. I just never met you so I'm not sure what you're saying is true. I've been doing software since the early 80s and I've never worked on a project where it was done right first time. I'm surrounded by people who are great at coding but most of the things we've done, we've ended up doing multiple times and learning from what we did. So iteration is inbuilt. We have to expect that. We go through this process repeatedly. I've been known to be a strong detractor of Scrum because I do think a lot of that stuff was just bullshit again. It's fantastic having a five to nine person process for your five to nine person team but when you took it to Nokia with 5,000 people and then screwed them up by making their Scrum, what is it, product owners, Scrum masters, be in 11 stand-up meetings every day because they're managing a Scrum of Scrums of Scrums of Scrums. It's just nonsense so can we get real? Can I have an X-File given the rent? No I'm not. I've always been a supplier but I know lots of people from Nokia so I made a huge software services sale to Nokia in 1999. I'm an old guy. So yes I know where the bodies are buried there and in lots of other companies I'm afraid. Anyway so iteration, I digress don't I? Iteration is unavoidable and we need to reapply this process on an ongoing basis. We are working at two week sprints and that seems to be giving us good results. I think one week would not give us enough time to learn the lessons from each time. We're still wrestling with how we get to sufficiency and I won't be able to talk about that today. We have some other parallel strands to try to get us to a quantitative review of what our actual risks are because it may not be obvious from all of this but what this really boils down to is risk management. No amount of certification or safety process or anything else guarantees that there won't be a problem and if you think about automotive all automotive OEMs have to contend with their cars are involved in accidents every year and some of the people involved in those accidents claim that the car is at fault as opposed to the driver and they almost certainly have a case so there will be these lawsuits people harmed by cars and the question is how to manage the risk of that overall. We're not guaranteeing that the software is never going to be at fault the question is how often is it going to be at fault how much is it going to cost per incident so this is all about risk management in the end and sufficiency really boils down to figuring out how to minimise the risk to a level that it's acceptable or it's defensible and defensible and acceptable will vary from jurisdiction to jurisdiction it's a function of what the law is stating in a given country. Okay so just briefly this is some stuff from our current ongoing project we're calling it Zesan by the time we kind of start engaging with customers Zesan is not the name that we'll be using but it's our code name and that's a lake in Kazakhstan I had to ask so at the top right you can see the controls structure diagram from STPA we use that as the basis for the modelling and then the modelling leads us to some structured YAML and it defines in effect all of the safety requirements and we work down from there so everything that we're doing ends up in YAML and then we can parse that and use it to trigger automated tests and generate all of the compliance documentation and everything else same thing for the test analysis and fault injection so we use the YAML to keep track of all of the tests and also to do the traceability so we can parse this and generate the matrix that people would require to see whether we've actually complied with what we said we were going to do we do a combination of pre-merge testing and post-merge testing and this again is practice that we've had to learn and evolve in reality with our customers has everyone here heard of trunk-based development? hold up your hands if you have very few, excellent the reason I'm saying it's excellent is because that's a very widespread paradigm for cloud-based and IT type systems the idea is that you have to land your changes every day into mainline so you don't have long branches unfortunately we've seen a couple of customers that have tried to bring that to embedded in car software and because testing for some of this stuff takes way longer than a day if you keep landing in mainline then you have something which is never working because it's always broken you get the results two days down and say no no sorry your change didn't work so trunk-based development is no good for this so you have to combine some pre-merge stuff which is not going to be complete with some post-merge stuff and just keep on landing stuff every day in mainline is not a safe way of working oh no I won't talk about this so the actual use case we're using and actually I should have mentioned this earlier one of the other things that we're doing is a way of constraining the work we do we're not trying to constrain the versions of Linux or the number of APIs that we can use but we are saying we need to know what the use case is we're not going to aim for generic safety you can do whatever you like with Linux and it'll all be fine we're saying give us a real case where you need Linux to do something so we chose this rear-facing camera application so in fact anyone that drives a car knows these days instead of just having a mirror which clearly doesn't have any software so it's unlikely to break due to a bug we're going to have a camera and then we're going to have it on the screen in front of us and we're going to use the video feed as a surrogate for the camera so that application is safety relevant and we've done the risk-alances for that and we've ended up with an architecture and tests and fault injections and mitigations around that specific topic and this thing at the bottom one of the things is we need to be sure that the camera feed gets to the display and that the lag between the camera feed and the display is small enough so if you get a frozen screen or a frozen frame that's exactly the problem that could lead to someone being hit because if you're showing an empty drive and then a kid runs across the back of the car then you had your one job and you screwed it up so we found some open-source software which generates a real-time clock as a bitmap and we're using that this gives us also a verification of what's getting under this display as readable because we can actually confirm that the clock signal is still interpretable as a clock signal and we're using that as part of our soak testing and our overall test framework to verify that what we send in through the camera input is arriving at the display output at the right time without excessive lag then we're combining that with gathering of the information gathering the data over an extended period of time and I don't think you can see the guts of these pictures but it's broadly plotting latency and plotting failures over time and then looking for trends and working out what is triggering the exceptions so we've already gone through again with iterations we established that a lot of our early problems were not down to the target system it was down to our test environment things that we thought were working and looked like they were working most of the time but you run it over some days and you start realizing you get these occasional spikes and when we drill in nothing to do with the target it's all about the system testing environment so we fix those over time and those graphs get better where we from the tests identify situations where the actual software is not behaving as required for the safety case then we either have bugs or limitations which need to be managed either by fixing the software which we expect will be quite rare because we've chosen well established open source or it may require changes to components we might find we're using the wrong approach I think some people still have a religious ongoing war about system D versus everything else you know I can tell you we've not found any reason to say that system D is not fit for this purpose we're sticking with system D in some cases it may not be possible to fix the defects we may need other mitigations certainly one piece of software on one system and the system crashes then you will need a mitigation that's outside that system so everyone needs to understand that ok, here's some lessons let me just check on time ok, so first of all STPA when I first heard about this I thought wow this is great this is going to literally save us because I was kind of at the point we'd done some discussion with lots of people in public around how you would make this kind of promise and I was starting to think this is too big there is no way of dealing with safety and then STPA brought to my attention and it's a top down approach which means I don't have to look at all of the lines of code and it gives me a way of reasoning about the risk from the top level and the claim was it's going to be a lot less work than traditional approaches fantastic, I'm all for that we started we did a public investigation with MIT in a project called AV STPA you can find that on GitLab and it kind of worked we did the first level STPA and we identified some real hazards but we kind of ran out of steam because the guys argued well we've done this one level but that's not enough, we're going to need to do level 2 and level 2 will be that much work and then there were some people saying it we might even have to do level 3 which would be to the end of Prague so so we stopped because we weren't sure how far we needed to go but we did actually manage to cause the work the project that this was aligned to to stop so we did actually potentially save some people from harm because there was a plan to take some vehicles put this Apollo autonomous vehicle software into vehicles and run them around Vegas at CES and we and MIT categorically demonstrated in two different ways that that was a stupid thing to do so it didn't happen we then did another project the first attempt of what is now the Zesan initiative and the STPA particularly bogged us down the question was how do we know what our scope is how do we know that we're applying STPA how do we know that our analysis is correct how much analysis is enough and how do we know we're even analysing the right things software engineers as I'm sure most of you know either directly or through working with them we tend to worry about making sure we know what we're doing cause corner cases can kill us trying to interpret this very wordy description of STPA and be sure that we've got it right hard for the frontiers third attempt frankly it came down to distilling the STPA and saying procedurally we're going to do this we're going to do this we're going to do this and this and this and only that so rather than boiling the ocean it was let's just do STPA once one level and see what results we get and I noticed that the team got halfway through that and then said we're going to have to do level 2 I said have you finished level 1 yet no then finish level 1 so eventually the team stuck with it over multiple iterations and we get to a full level 1 analysis which is a huge value cause now we have a thorough assessment of the risks and some lost scenarios which we can generate tests for so our current thinking is we don't need to keep doing level 2 level 3 because we can use different methods against that from the bottom up and that seems to be working so we already get a lot of value from the automated tests and the fault injection to probe whether our analysis is holding up we can map all of the results that we find back and see whether is anything exposing something we missed in our analysis and so far the results are good and the final lesson I would suggest for this morning is that tying up all of the paperwork is still a huge amount of work saying CICD is going to solve it magically mostly it does but you've got to do all of the work of plugging all of these mappings together once we've done that the first time it will clearly be a lot less for subsequent certifications so we do think we gain the benefit of the ongoing process speed up and here's where we are now I'm just checking for time have I got 5 minutes is that right yes so we work with Exeter for those who don't know Exeter is we would assert a very well established certifying authority they provide consultancy on safety as well they're all around the world we work with them in the US and in Germany particularly and they've been doing that for 20 or 25 years so they're very well established particularly in the industry that we care about we've been working on this specific iteration for 18 months I would say it's a team of around about 10 people in total which is large for code think but when we discuss that and say how far we've got with our customers their jaws drop at times we've been building on the tools that we certified a couple of years ago and we're confident that we're on a path now to achieving this and this year we've started literally just in last weeks we've received commitment to go ahead with a proof of concept with one of our first customers so things are so far looking good and I checked with Exeter that they were happy for me to share this they did our first safety assessment in April this year this is what they said to our customer so they've done the preliminary functional safety assessment they've done written they've had written responses to their questions and they've analysed them they think that the system level analysis is very solid and they were keen to point out that in general they find the people aren't doing that because the way the standards work people are driven to certify this component and once you've got enough ticks in those boxes then you guys just make it work now because it's safe which is flawed so the fact that we're calling it out and showing a way to deal with it is where I think there's some real innovation and some chance for better sanity and more progress and they said fault injection needs some clarification the reason for that is just that the standard places very strict guidance on what a fault injection is and we're using fault injection for way more than that so we're using fault injection to probe as many different things as we can so in effect they're just saying that using those words we need to call it out and explain what we mean by that and the key thing is they believe and they believe when they did the assessment that we are on a route to certification and they're hoping that we can achieve that in time for their symposium in October this year so we're very excited about that and I will finish by saying I don't have a slide for this that our intention is that all of RAFIA will be open source with we could have done all of this in the open from the start but why would we first of all we'll just get a lot of people saying oh that's crap and second there's a reason why most people don't publish their STPA analyses I asked MIT we were talking about autonomous vehicles I said they said they've done this about five or six times I said oh great can you share your STPA because I expect they'll all be the same because we're on the same planet same laws in the different countries same weather, same vehicles so you would end up with the same result oh yes but no one will allow us to publish why not, well because it exposes risk it exposes them to liability so we were breaking ground to do the AV STPA analysis in public because we did it open source from the get go but we're a tiny company I really don't need world and dog in large operating systems companies hurling crapparders at the moment so by the time we open we'll be able to defend by saying we've used this to certify two things now and we want the open source community organisations to take an interest sorry to take an interest in this categorically I don't see how an open source project on its own would normally want to do certification because it's just exposing a whole lot of risk that nobody would need it's got to be done by companies that have a commercial interest in managing the risk so we're certainly wanting to encourage companies to take up this process and get to safer solutions with open source but I'm not expecting a flurry of oh, you know Yocto is certified because I'm pretty sure can correct me if I'm wrong Linux foundation won't want to be on the hook for making those promises it's got to be the organisations making product that carry the can for making those promises so that was it, thank you Paul, I have a question as you're using mainly the STPA and you have been in discussion with Exida does the STP or is the STPA sufficient because typically the questions come on have you done a forgery analysis have you done an FMEA and that's what I typically hear in automotive so these are the masses, STPA is new can it replace a traditional FMEA forgery analysis Well, our position is that yes it clearly can because we don't need to do those alternatives that doesn't mean that there might be no value in running those methods as well so one of the things we've established is having someone else look at the problem from a different perspective may always give us some new value so we're not saying don't do forgery analysis or BOTI or whatever it is but we don't believe we need it to make the promises that we're making Okay, thanks Any more questions? One here Are you familiar with you talk about how do you stop testing how do you know when you stop testing the only thing I know from what objective is something that I've run into with telephone companies I know AT&T and Nokia have used these where they have they assume a constant testing rate and then from that they predict basically a defect backlog curve which rises as they do testing and then tapers off as things are actually fixed which is it has its limitations certainly doesn't work well for small organisations just because the statistics aren't there Are there other objective ways that can, the only other thing I've seen companies use is they just say we will have no more than one serious bug and three not so serious bugs is there anything else that we can use? I mentioned that we've got a couple of other paths because this is just risk management to a certain extent is what I've been describing today we have a research project underway trying to identify appropriate metrics for open source projects in general and particularly the open source projects that we are hoping to make safety claims about so that will look at large scale statistics and the great thing about open source there is the data is available so we can with scripts gather bug rates and if we can establish the kind of trends you've mentioned then that will be great obviously there's false positives there or false negatives because there's loads of bugs that are not relevant to the hardware we've chosen or the specific version the other path that we're on we've engaged with an organisation that specialises in quantitative risk management so this is a company called Hubbard Decision Research they're relatively small but they're very well established they've been doing this for decades and literally the brief we've set them is can you help us figure out how we would measure the risk for this kind of situation and also how you could measure the value what risk reduction we get from these measures so we're identifying all of the measures we're taking and then we're trying to put dollar values against those versus the risks so I would say that's not a solved problem but we're on paths to assess that yeah, thanks for the question any more questions there is one question online it's not about coverage is it no let's see are you targeting to certify against any aviation standards such as DO178C DO330 yeah so our approach at the moment is to focus on automotive because we have a number of customers in that industry that are really interested but absolutely the hope is that we can broaden from there so the trick is to establish a method that we can show works in one place and then build out so it's not we're not thinking about that today but with a trailing wind maybe next year or the year after and certainly we'd welcome interest from people in those industries great, thank you I'll say one more here just a sec run yep great I'm in one of those industries we don't use DO178 because that's specifically for human rated vehicles and ours is unpiloted but when you talk about code injection one of the mantras that happens a lot services development area is test as you fly and fly as you test the tricky thing there is to do fault injection you do have to make an exception and we do make exceptions, you just have to to do good testing but any thoughts on making that as painless as possible it's a totally valid point obviously because from our point of view we want to have broken versions of the software and we want to slip them into people's testing to check whether they're really testing but we can't do that if it's going to actually cause a risk to humans so we have to weather up, so no I don't think we've got any magic bullet there but we are worrying about exactly that that topic we would want fault injection as far as possible down that and we certainly would want it in our use case in vehicles on a test track without wet when we can simulate the reality of the real environment it should be possible to use fault injection all that way once you're flying I think it's it's harder okay great thank you for the questions okay thanks a lot folks