When safety meets open source: Building trust in the software-defined road ahead

In this talk, the speaker discusses the critical importance of functional safety in the automotive industry, emphasizing the need for systems to respond correctly to failures. They introduce functional safety standards, particularly ISO 26262, and explain the processes for identifying and mitigating risks associated with safety in automotive systems. The speaker also explores the relationship between functional safety and software development, illustrating how disciplined processes and thorough testing contribute to overall safety. They highlight challenges presented by emerging technologies, particularly in highly automated driving systems, and emphasize the potential for open source solutions to enhance safety through collaborative peer review and transparent processes. The session wraps up by suggesting that achieving functional safety is more about the system's reliability than simply acquiring certification.

Thank you and welcome to OCX 2026 and welcome to the OCA track again. Uh my name is Donna Ve. I've been working with the Eclipse Foundation since 2023. Uh but before that I've spent well practically my entire career in the automotive industry. Uh I don't seem to be able to get away from this industry for some reason. Um, and yeah, I've pretty much gone through all the

software roles that you can imagine within a project. And eventually I came to processes and to quality because I felt the need to bring everything together. The interfaces didn't feel like they were functioning properly between the teams. So that that is how I looked more into optimization into continuous improvement and also that's why I'm here with the Eclipse Foundation trying to bring more light towards the open

source when it comes to standards and even more to safety for automotive. And with that said, after this um too long introduction, I'd say I'd like to ask for three volunteers from the audience. Nothing too dangerous or too spectacular. Carlton, thank you. Uh gentlemen in red. Thank you. I would Yes, please. Maybe we can have a third volunteer as well. Come on. Third is a lucky charm.

Thank you, Theo. [applause] So, I'd like you to state your first name and then to roll this wonderful dice that you can also maybe tell the public and it has so many facets to it. >> All right. My name is Carlton and it looks like this is a 20sided die >> and I rolled lucky number six. >> Okay, please keep that in mind. >> Right. Should I

also roll it? >> Yes, please. >> Right. My name is Ailia, by the way. And that's uh 12. >> Wow, that's a double. Thank you. Not that that would matter. [laughter] And I'm Tilo. And um let's see what I get. You probably need to help me to read that. >> Um what is this? >> It's a 10. >> It's a 10. Yes. >> Wonderful. Well, thank you

all three of you very much. I'm going to take that back to dice. And please remember those numbers because I'm going to ask you about them towards the end of our presentation here. [laughter] Thank you so much. And not to keep you in suspense and and moving on. Um here's briefly the agenda of the talk that I'm going to give today. These are the main topics that

we'll slowly be going through um as we go through the presentation. As a first one, I' I'd like for us to set some foundations around functional safety. What it is, why is it good? and so on and so forth. So starting from the definition that functional safety is the part of the systems overall safety that relies on equipment operating correctly as a response to the inputs that

it takes. Any problem with the statement? We all understand it, right? We all agree with not so convinced. Well, at least this is what the the standard itself says. And when I say the standard, I mean pretty much all functional safety standards that are derived from the generic one the 61508. Now to try to understand this a little bit better. Um safety is actually a claim you

know when when going back to the system overall safety when when we look at that we want to make sure that the system has precise and defined behavior whenever it encounters a failure. So at the end of the day the success that could be drawn out of that would be ensuring that the system actually knows what it has to do when it encounters a failure. So if

if you want to make um a parallel for example between uh C programming as as a as a programming language and safety the the two of them are very similar. The C programming has certain behaviors that are not defined but they are very specifically um described. It would be similar for safety. A safe uh system would have all of its behaviors defined. It doesn't matter the type

of failure that you encounter. The system has to be able to detect that and behave in a very well-defined manner as a response to that failure. Now, why do we think safety is good and is important? Well, we we all drive cars or majority of us. Um, even just from that perspective, you don't want to be involved in a issue of safety with your own car while

you're in traffic, right? Let's say you're on the highway doing 60 miles an hour cuz you just entered and suddenly something happens. I don't know, the the airbag, the the driver's airbag just pops into your face. That's a total no. You don't want that to happen to you, right? So that's why it's important. Now reliability typically asks a different question than the actual functional safety. So it

it's more about am I safe to use it and for it not to break? Am I sure enough that it that system will not break? Well, for safety, the the the change is eventually it will and that's not such a big problem. The big problem is I need to be sure what will be the behavior if it actually breaks and that behavior as I said needs to

be properly defined. How is the whole thing helping people? Well, it it mainly guards us against misbehavior because as I said, if the the behavior is well defined and properly implemented based on the potential failures that we could see in the system, then obviously we know how it behaves. A misbehavior would be that we encounter a failure. We know how we want the system to behave and

yet the system is not capable of exercising that behavior. We we could encounter mainly two types of failures at least in our line of work which would be hardware failures. Um that could be random failures, things like a sensor uh has gone uh beyond its expiration uh usage date or because of that the ranges in which it functions properly or completely haywire. uh but there are also

systematic failures which uh determine a lot of how the system overall should behave and the systematic errors are usually related to designs and to software. Um I underline both of them because very often we see especially in the automotive industry that bad hardware design has a really huge impact on the actual software. So we we suddenly have to do all sorts of tricks within the software to

make up for a bad design in hardware. Such things need to be looked at very carefully because they can come with really big implications especially if they are not properly documented. Now in order for us to to know um the to establish better said this behavior of the system in case of such failures, we we need to appeal to safety mechanisms. And such safety mechanisms would be

on one hand making sure you have a secondary path. As an example, um well today all vehicles have two headlights. Why do you think it got there? The initial idea was to have one light. I need to be able to drive in the dark. So, one light should have been enough. But because potentially the light bulb in that one headlight could have been broken like really easily

or maybe have a short circuit in the in the electrical circuit of the vehicle, it the the the light bulb could have gone off as well. That's why they came up with a secondary path, meaning a second light bulb. So it doesn't have to be something overengineered, over complicated. Just giving the system a secondary route that it can take to even avoid a potential failure. And that

that really helps a lot because um by putting in place such um secondary paths, we we also figured out that we need to monitor the system. We need to figure out how it behaves. We need to let it self diagnose and those are actually the points through which we can ensure the the secondary safety mechanism that is usually applied. Now having such safety mechanisms in place permits

the system once it encounters a failure to go back to a safe state. I don't know let let me think of an example. Um let let's use the IVI part for now. Let's say we are doing navigation. We are supposed to get uh from here to the hotel to Marriott and um at some point in the traffic uh instead of directing us towards right uh the navigation

is directing us wrongly towards left. We notice that because we take the the left and and figure out that we're not getting where we're supposed to. So what what would be best to do to continue on that route until the navigation keeps recalculating and keeps rerouting us and so on? Or would it be best maybe to just stop and restart the navigation? Maybe the typical control delete

that does the the the trick. But the point is once we do the stop or we change the parameters of that navigation we are helping the system to go back to a safe state of operation and that's the main thing for functional Now we talked about what safety is in general but um we should be framing it also into standards so that we understand why exactly safety

is important for our industry and in general. Well for the the automotive industry of course you probably all of you know that ISO 26262 is the main standard when it comes to functional safety. However, this standard was actually uh derived from the general one, the 61508. And as you can see, there's loads of other standards, and I've only mentioned a few of them here that have been

derived, all of them, from the generic one, the IEC 61508. I'll make a few references further on to Um, if you have questions around it, uh, it's probably better to ask them now so we can clarify them before we enter those topics. Okay, hearing none. Moving on. So, um, looking into the actual safety standards, what we what we notice, especially looking in our automotive industry, um, we

notice that there is a path towards safety, right? And how do we achieve that path inside of a project? Well, we start discussing what exactly is it what we want to create. Then we start laying out at least the top level requirements. Then we're going to start decomposing those requirements into smaller ones potentially hardware uh design software and so on and so forth. But eventually what we're

going to have to do is we're going to have to analyze the design or even architecture that we have in mind and try to identify potential problems, potential failures. We're looking for hazards. That's the main thing there. And a hazard especially in in in our case would mean like having uh somebody's life threatened ha having somebody's um health threatened because of that issue or even having a

property under threat. The simple fact that a vehicle catches fire on a highway while it's still driving, that's a really big issue. We don't want that to happen. So the the whole point of doing this exercise within the project, applying the functional safety principles within the project is, as I said, starting from identifying the hazards, analyzing those to determine if there are really a risk and then

once those risks are identified, we start to to look for ways to to mitigate them. So we've established that there are real risks. We've established which of them can be mitigated, which cannot be mitigated and also in what to what extent they can be mitigated because we'll never be able to mitigate all the risks. And this is where another topic comes into the picture and we'll we'll

touch that a little bit later as well called liability. So people in our industry in particular have thought okay I want to build a vehicle. The expectation at least from my customers and potential end users is that this vehicle is safe. Now according to the standard I got to go through those steps and I got to analyze all the risks that I've identified and try to mitigate

them. Based on those risks, I will know how much I'll be able to mitigate and how much I will need to cover through other means. And the reason for which I say cover is because usually the other means would be insuranceances and these are put in place especially to support that liability factor of the whole picture. now in safety we we obviously we have a lot of

rigor but also this rigor is is split in a few levels. Let's say uh going from A to D. Um these would be the the safety integrity levels. For A you have the less rigor for D you have the highest rigor. I haven't mentioned QM because well that would also be a a qualification but QM that means quality managed meaning from a safety perspective there's nothing in

addition for you to do than your typical software development testing integration and so on practices nothing very safety functional safety specific to be defined in there and looking at those risks. The the most important aspects to retain about those risks so that we can further on analyze and establish what we can mitigate and what further on needs to be covered by an insurance would be these these

three elements these three factors the severity the exposure and the controllability. So obviously as we talked the severity would be related to how dangerous that situation would be. Is my life gonna be under threat? Is my health gonna be under threat? I don't know. Maybe I have all windows open. I catch an airdraft and my head hurts all day. Yeah, that's a health issue which I caused

by myself. So, it's not really under this subject. I'm trying to explain. We need to to to look at each of these cases one by one. Understand what the technicality behind them is in order to determine what the actual risk it poses. The exposure well it depends how frequently it happens. How frequently do we encounter that particular dangerous situation? if it's I don't know I' I've recently

seen an issue with um a gentleman that had to take his car to the garage because every time he was turning the the steering wheel to the left the honk started to the the the car was starting to honk and it was really funny. That's not necessarily a safety issue for that guy in particular, but it could become a safety issue for the people around him. So

for the actual traffic again need to be careful how we look at these risks and then last but not least it's the controllability. So what is our ability to control that Can I as a driver intervene so that I can make that failure disappear? It's a valid question. Can u somebody else around the vehicle or within the vehicle intervene to make the situation better to to bring

it back And again once analyzing all these risks and of course all these three factors we start to create this risk assessment matrix based on which we'll determine what we can and should take care of should mitigate and what we cannot and needs to be covered through those other going a little bit further into the actual engineering life cycle and methodologies and uh maybe some practical examples

of what this means in the real world. Well, from an engineering perspective, we've we've looked at the V cycle and by God, I think all of us are sick and tired of it already. But the point is this V model gives us the best way I would say to ensure that we start from requirements and go through all of the activities one by one sort of like

in a sequence. Now the the traditional way of doing this is to do it strictly in a sequence with no overlaps. But in the the last years I'd say 10 15 years or even more maybe while looking at the agile methodology people have tried to implement that the two of them together and I would say it's quite a good approach and it functions quite well as long

as it's well established well defined and people understand what exactly it is we want to achieve through that. So bringing agile in this picture doesn't necessarily mean that we don't follow the same um sequence. It just means that maybe I can start with my system design or my architecture design before I have a 100% completion on the requirements. It's a thought to to take into account and

that actually gets to be propagated further down. We're never going to have uh full MVP just going through this V cycle once even if just for the sake of uh needing to make fixes for bugs. As we all know there is no software with no bugs. there's just software that hasn't been tested enough. Those bugs will eventually appear. But again, they also depend on the requirements here.

Those requirements also establish in what environment our final product needs to function. Whether it's a vehicle like in our industry's case, whether it's I don't know even a a watch that monitors your heart rate that also has a safety function in there. Going further, uh you you probably heard about SOT or or better said 21448. This one is a safety for the intended functionality it it spre

its head um through all of the other standards once we started looking at the feature especially in the ADAS area. Uh the point with those is we want to make sure that um systems do not get confused by the information that they receive. from outside. So from the the surrounding environment in the most recent years, we are very much linking that to AI. But it's not just

AI. I mean AI at the end of the day is yet another product of the human minds. It it didn't just pop out the air, right? We are the ones that created it. So it's still going to act. it's still going to behave the way we specified to it to behave. So don't consider that being just an AI related thing, right? It it might be that you've

you've done the specification, but while you were doing the implementation, you got carried away with, oh, this is really cool. I've got yet another idea. I'm going to improve this even more. And then that's where your disconnect happens between the specification and the code. That's where the issues can pop. So having some specification, not necessarily 100% before starting to write your code has some sense because it

it needs to give you some direction to what you do. Now when we look at at safety case requirements uh they they can vary and they can be of all sorts of types. They can be technical requirements. They can be standard related requirements. They can be hell I mean they could even be um broken down into um HR related requirements. I need to have a functional safety

engineer to work on my project. That's an HR requirement. It's not going to be the project manager hiring that guy or your customer hiring him for you. Similarly, there could be I don't know u an additional requirement to follow I don't know what u extra regulations for a given country. In case you missed that, uh, usually it's the the each country's government that establishes what regulations they

want to apply on their roads to keep them safe. Nobody really asks any OEM, bring me your certificate on functional safety so that I can open the door and let your vehicle go out there on our streets, on our publicly roads. It's more about this mitigation of the risks. So the government wants to ensure that whomever produces a safety a functional safety related product whether it's a

vehicle I don't know um a train u a medical device knows what they are doing in the means that they've done absolutely everything that they could to make it into a safe product and in case there are some risks that couldn't have been mitigated. They want to make sure that the respective producer can be made liable, meaning they have a high enough insurance to pay for the

damages that they potentially could create. And and for for the actual safety case, we're as I said, we're not looking just as at at um technical requirements. We're making sure that we have a process in place. You can't do safety uh development with an ad hoc process. You can't just decide from one moment to the other. Oh, I'm I'm just going to skip testing altogether. Um like

the the lower levels of testing and I'm just going to go straight to validation. You have to have a well-defined wellthought process that also incorporates all these elements that make claims towards your future product. These um elements that come from the the set um um standards. So we're looking at processes, we're looking at validation, but one of the things that is uh well for all of us

hopefully and not just from a safety perspective really important but also something that the assessors auditors are always keen to ask for is a traceability. When we say traceability we mainly mean birectional traceability. So back and forth from your initial requirements right from here to your vehicle because of the implementation and then to your testing side of things because eventually you'll also have acceptance meaning that your

customer will have to test your product based on their um well-defined boundaries of the system. So traceability why why is this one is so important for us but again hopefully not just from a functional safety perspective as engineers we learned that we've solve things faster if we know where things are broken. So that's what traceability does for us. If something breaks down, having this full traceability birectional

traceability in place helps us to faster detect the issue and come up with solutions for fixing Um, one other thing that I want to to to talk about a little bit while we're on the standards themselves, it's not just the certification that is important. And obviously the certification comes in after actually having an audit after having an assessment but it's um it's making sure that again as

I said we have a process that is well defined and is established. It's first of all the process that needs to be assessed to see is this process really taking these guys developing this project in the right direction or is is it taking them in a completely different or random direction. That's a first element that the assessors need to make sure of course after we ourselves have

made sure of that too because that that was the initial intention but then after seeing that process we also want to make sure that the process is properly applied in the project. We can't just claim oh we have a process over here here 50 pages who wants to read it. It doesn't go like that. We really need to apply that like on a on a daily basis

on a task base. It needs to become ingrained into the way we work. And last but not least, they will also be looking at the code. And when I say code, I don't mean just the code that gets to be executed on our vehicles. I mean code also part of the test scripts, for example. I mean code also scripts that potentially generate extra documentation for you. So

they'll be looking at literally all the artifacts of your and they will come up with an answer after they put everything in balance, after they make sure that you've specified all of the possible behaviors of your system and also going to a safe mode of the system after encountering a failure. That's when they'll come back and say it's a yay or it's an A. They won't give

you too many details if it's an assessment for certification. If it's an audit, that's their duty to provide you with all the feedback possible to help you improve what you've already done. And a little bit of a practical context. Uh I'm pretty sure you all are familiar with all of these examples. Uh first one would be the ABS uh module in our vehicles. As you know that

is very important because if your brake doesn't function properly, we are screwed. Uh there's the electric power steering. That's also very important because it has to deal with the with the motors and they need to disconnect the power in case they they don't work properly. Um but we we see things like this in other industries as well, not not too far away as um you know the

elevator that you probably took this morning coming downstairs from your room in the hotel. If one of those elevators malfunctions, more horrible things than just being blocked in it for 20 minutes could happen. It could just drop. And depending on the level where you start from and it starts dropping, it might become an an actual issue. I mean, it could it could result in actual injuries or

even death. But then there's also industrial cobots which are those um collaborative robots that that use light curtains um to cut cut off the power if a human is is found in a in a working area where they're not supposed to be. So there's there's a plenty of examples that we can look at. Maybe you've seen the latest um uh Hoovers, the ones that are automatic, really

round shaped, tiny, they just walk around the house as they would be in their own world. Well, even those have some safety in there. If, for example, you have a toddler in the house and and one of those vacuum cleaners steps on the baby's food, what are you going to do? we need to make sure that it's safe for the baby. Right? And that's just one example

in that direction. So even household equipment can become dangerous if it's not properly designed and specified. Now because we are at an automotive track, we'd like to go back to the SDV part of things. So let's talk a little bit about the the challenges uh the safety challenges in the in the SDV era. So we we talked very little about the navigation. So the IVI uh module

but that one actually is part of a broader component within the vehicles these days. that component being ADAS and the the reason for which that component is so important is because while we're thinking about introducing more and more artificial intelligence all around us and in in our daily work, our daily usage of products and so on. Of course, we'd like to put that stuff into the vehicles

as well. Obviously, after we test it and we make sure it's safe because we're talking about functional safety here, right? But the the point is it becomes more and more important to ensure that topics like functional safety and how exactly to achieve functional safety from a technical perspective and not so much from the stamp on the paper perspective is very important because there will be more and

more vehicles out there having more and more electronics in them which means potentially even AI I soon. And as end users, we want to be able to at least understand what we are making use of and how to look at those products, how to identify potential failures that maybe have not been specified, how to ensure that we are using them in the proper manner as they were

specified to be used. I don't know it might be familiar at at some point about 15 maybe 20 years ago there was this case in um US I believe um an individual bought an RV and um the RV in its book it said that it has a sort of a co-pilot function but the guy didn't want to spend too much time reading the manual who wants to

read the manual and from co-pilot. He understand literally, oh, I can just tell it what to do and it will do for me. Well, surprise surprise, the guy set the the the cruise speed on the vehicle and thought that was it. So, he went to the back of the RV to make himself a coffee. And guess what? He crashed in a rock because nobody was watching the

steering wheel, right? So we ourselves as end users also need to educate ourselves to understand what we are using and how we are supposed to use those products. So again coming to the ADAS um there are all sorts of functionalities or features as we've heard them in the past years that are incorporated in this uh bigger component things like AB like lane assist like cruise control like

ACC all of these things have to be able to um handle failures ers. So obviously as we were discussing before diagnostics is a must in this area. There cannot be any ADAS component without proper diagnostics dedicated for it. Otherwise we'll not be achieving safety in that direction. It's just as easy as But is that enough? Isn't it maybe also about a little bit of discipline like we

were discussing before? Yeah, I'm writing down some documentation, but then um I get caught up in what I'm doing and it's so exciting and I like it and I haven't been coding in years and I'm I'm really excited about doing this and I have really good ideas. So, I'm just going with the flow and at the end of the day, I'll be, I don't know, 50% off

from my initial spec. Should I leave it like that or should I go back and update my initial spec or maybe even look at the the code that I've written and and pause a little bit and and think about it. Is this really needed? Is this really what I wanted to make? So always making these correlations and maintaining that discipline of doing these actions is is quite

important because discipline is also about processes establishing them first of all defining and establishing them making sure we're actually applying them but consistently not just on Fridays because it's a shorter day. Um and and it's also about um again rigorous validation when we say testing just thinking about uh the the IT police standards when it comes to software development and and testing there there are multiple layers

and or multiple levels however you want to see them for testing. Just the fact that I did the validation is not enough because I might have um a problem on the hardware side. I might have another problem on the software side and guess what coincidentally the two of them annol each other and I'm not going to see anything in the validation. That's why it's really important to

start really from the lowlevel things and make our way up to the top without skipping any steps in that testing phase. I know everybody wants testing to be instant, potentially fully automatable. It's not always like that. There are some things that we might need to test manually. There are some things that we might to just test them visually like they do in the plants for example. So

just keeping in mind that each test each type of test each level of tests has its own purpose very well definfined purpose and that's why we need to keep this discipline around them. It's important not just for functional safety but software development in general. And last but not least, there are design phase decisions like we were saying before. Okay, I got carried away with my coding cuz

I'm so in love with it. I haven't done it in years and wow, this is great that I can do it now, but is is the direction the right one? Shouldn't I be going back and update my spec or is it really what I've done? Is it really that important towards my spec towards achieving that product? Now talking about I have to close. Um unfortunately I didn't

take enough time to go through the presentation with you. What I would like obviously the slides will be made available for everyone. What I would like to go through though are some thoughts and ideas around open source and safety within open source. And there's mainly two uh ideas that I would like to underline. So you are probably familiar or maybe not with Linus' law. Uh Lionus the

creator of Linux. Um this law says that um leveraging uh peer review for a faster bug detection and vulnerability patching is better than for closed systems. So that's one thing to really keep in mind because it's really about open source. And the second one is there's a cultural mismatch. Uh meaning that traditional safety is usually relying on proprietary or locked down code. And this is actually clashing

with the idea of having a transparent um approach, the one that open source has. Now the way to bring these two together is to start to see that in fact what's important is to have a safe or as safe as possible system rather than having that stamp on a piece of paper. And this is what makes um things like our approach for functional safety way better I

would say in my opinion because we have a big pool of reviewers testers coders those secondary pairs of eyes are quite plenty in the open open source world in the corporate world this doesn't happen that much not everybody will have time to review your code or your design or your architecture and so on so So that's on one hand. On the other hand, mark this down in

your in your head and go back to this slide and identify those things on our Eclipse Foundation website. So we have a number of processes like Eclipse development process, the Eclipse functional safety process. Um we have IP and security policies. We also have a very small SDV process. All of these taken together are practically replacing at least for open source all that heavy corporate style of processes

that exist inside of corporations. And why? Because in in the open source, the main thing is about collaborating and bringing everything out in the open, having everything transparent. And I'm really sorry, but I'm going to have to end here because we have the next speaker coming in. My apologies. >> Thank you, Jenna. >> [music]