 Hey everybody. So yeah, that's the update from Kate and me regarding what we are planning to do for functional safety. So, generally speaking, when we're looking for functional safety, we're performing safety analyzers on a system level and when we look into today's systems, it's not a monolithic one-time development that you once planned, develop and ship. It's a bundle of modules that are put together, that are modified, that are pre-existing, and actually, yes, some come from the open source domain. So, we have, yeah, several layers, microcontroller, the hypervisor layer, maybe different operating systems, different applications, the tool chain associated with it. So, there's a lot of stuff to think about what is actually within your system. So, I think how many people are familiar with functional safety in here? Oh, more than I thought. So, when you speak about safety as a difference to security, it's the freedom of unacceptable risk of physical injury or damage to the environment or health or whatever. And the functional safety part is that part that describes that the system operates correctly or operates as defined. Also, maybe in anomalous situations or if something internally breaks or how to avoid things to break internally at all. And so, it's mainly talking about, yeah, avoidance measures or detection measures and safe states that you will have once you detect something that's not normal. So, generally, in functional safety, we are aiming for, on the one hand side, having system architecture that in itself is safe, that it's sturdy enough to perform safely in any condition that you can think of. And on the other hand side, we need to provide the evidence that we not only planned to have a safe system, but actually that we have implemented and shipped and tested a safe system. So, generally speaking, doing functional safety always results in a lot of documentation that you provide along with your system that you ship or with your software that you ship. So, yeah, I know safety is a system property, so you can't say this software module of the complete system is safe, so my system is safe. So, safety is not plug and play of safety certified components, it's a system property. But, yeah, with all the components that you plug together, it's not only that they have to support your safety concept, they in themselves need to provide a documentation that they have been implemented as intended, that they have the properties that they claim to have. So, generally speaking, yeah, that the software you're pulling into your system can perform or capable of performing as intended. So, the evidence that you usually ship with your product, they are usually defined safety standards, safety standards usually focusing, yeah, that everything has a unique ID, that you have traceability between your components that you can have a complete set of stuff that you have the evidences that you have everything. And when we, let's say, translate this into, yeah, our software language, it's about defining your dependencies inside of your product and keep these dependencies up to date. So, as creating a system these days, as I said, it's not a one-time process, it's updating things, it's also fixing issues, fixing security issues. So, also, we need to have requirements and means to prove once we have done a change, once we have done a fix that we are done again with all our documentation that we can prove that we have done everything as intended and then we have shipped a proper product again down our supply chain. So, also here we can use the S-bombs as already also used by security, providing machine readable information for assessing if a system has a safety capability for being used in another system. So, these days, what the stuff safety standards are looking for like unique IDs and dependencies of the component, that's something that you can find these days already in the S-bombs, but what you currently can find is the documentation, user manuals, requirements, product architecture, test coverage, all that stuff is something that, on the one hand, we can already describe with SPDX requirements pretty well, but that hasn't been done yet. So, when we look into a functional safety project, so FUSA is for functional safety, the internal dependency model we are still thinking of, in most cases, a V-model that you have higher level requirements, you break them down into an architecture and a design that you use for your implementation and then you integrate stuff step by step and you test stuff step by step and everything is done based on a foundation of plans, of guidelines, of validation verification measures so that you have this V on a proper base. So, why are we starting to think about using SPDX? So, when we look into what stuff needs to be done for functional safety and we are all engineers and yeah, we like to have fantastic systems and most cases we also like to maintain them. Do we like to apply a process? Yeah, it might help, it might bother us, but yeah, it's okay. But ensuring all documentation, evidences are there that we describe everything, that we pull everything together, that's usually, that's a pain because we have everything in our heads already, we have everything implemented already, it's running, it's a big no-no, it's a big pain. So, this is really the thing where SPDX can help a lot. So, actually FUSA projects and FUSA documentation, that it generally always looks the same. We have documents that are plans, guidelines, process descriptions, we have requirements like, yeah, functional requirements, non-functional requirements, architecture design, and we have all this verification stuff, evidences, safety analyzes, whatever. And actually the current data structure and functional safety projects, most of the cases, we have these silos of documentation in our life cycle. Plans are still mostly PDFs or in a kind of Wiki or in a QMS system. We have requirements somewhere in another life cycle management system. There's the code, thank God, usually in some kind of repository these days and that's the only thing where at least in my opinion or in our opinion, everything is already really within proper configuration management and proper traceable. And then you already also have the verification evidences that that might also live in their own system. So, once you want to do an update or you want to do a configuration of your system, traceability usually breaks somewhere, you need to have a manual process, spreadsheets are your biggest friend. So, that's really something where the machine readability ends and the pain starts. So, when we look at the life cycle of a product and when we think about the S-bombs and the S-bomb types, actually we can create or generate S-bombs about functional safety evidences and documentation when we have the data available. So, really starting from the design S-bomb when we plan a system maybe for the first time when we have all these stuff saying, yeah, this is the fundament, that's the foundation of how we plan, how we structure, that's our safety concept. We do all the implantations, all the requirements, we have all the source code that we can push into a source S-bomb. So, actually we can follow this whole life cycle with SPDX and safety in mind pretty neatly. So, yeah. So, every kind of documentation or evidence that we create with functional safety actually fits very well in the already defined S-bomb type model. So, really from designing and planning to building to the configurations that you might deploy here or might deploy there and that you have maybe collected runtime data, logging data that goes then also during the lifetime into a runtime S-bomb. So, actually let's say when I come from the automotive world there's a lot of problems that I see in actual projects where you have config data, where you have runtime data and where do you put it? How do you package it? Where do you find it? So, that might be our solution. So, when we look into the current 2.3 dependency relationships that already work pretty neatly to create our dependency model 3.1 will be even better. So, generally when we look into the structure of a generic project we can say, okay, yeah. Plans, guidelines and the safety concept that's a pretty stable thing that can go into a design S-bomb that really describes what do we have? What do we want? Then all the stuff regarding detailed requirements, regarding architecture, test descriptions, source code that you use later to build something can go to the source S-bomb and then, yeah, with all the build definitions, your build tools, you can have your build S-bomb and that's more or less how when you deploy and run things goes down the same chain as the standard S-bomb lifecycle. So, we are currently piloting this concept on the CEPHER project. So, for those who are not familiar with CEPHER, it's a small RTOS free operating system. If it was started already with safety and security in mind, so there's a lot of structure already there. Permissively licensed, so it's open source. And yeah, so what we currently have with CEPHER is, yeah, it's the RTOS. There's a build system available that test cases and test frames work, so everything that you really want to have and from the safety viewpoint, we are currently creating the functional safety evidences, the management plans, analyzes, traceability or requirements, all that stuff that we need for safety in addition. So, when we currently look into the project itself, yeah, we need to, or we have a safety development plan, we have safety claims, we have high level software requirement specifications that really can form the design S-bomb that's really describing how we want the sources to look, sources in that sense really mean coding guidelines like it's how to create code. On the other hand side, the detailed component requirements or what should the code do? And then on both levels, also the evidences that you have tested this, that you have maybe reviews or static analyzes that you complied with the coding guidelines and on the other hand side, you have a component or unit tests that show you that the software behaves as intended in the component. And we can take this one step further and say, okay, once we have built everything, we still can deploy or can create these relationships to see where does stuff come from, where are the dependencies, where is the information source. The real beauty really starts on this once you have an issue because yeah, there's a famous impact analyzes in functional safety where you start looking about what is affected, what is the root cause, what do I need to do and usually that's something involving a lot of experienced engineers that are sitting together and discussing, oh my God, what do we need to do? And then pulling stuff together that they need to change, that they need to update. And actually the more complex a project is when we think about layers of components and modules that form a complete system, the more let's say variables you have that can go wrong or maybe even it's not deterministic the outcome that you can maybe not even really see and I complete with my impact analyzes. And actually yeah, when we have all these nice relationships set up and we can really see, okay, my executable behaves weirdly. And let's see, yeah, what could this problem be? It could come from the sources but it also can come from my build chain. Maybe my tool chain is some kind, is weird in some kind, so. And you can really trace this really back automatically where it could stuff have gone wrong. Some requirements back to high level requirements maybe so that you can really follow the complete chain of problems and then follow the chain back when you implement the changes back to the issue that you might have. So and then hopefully pressing one button one day and generating the complete new set of evidences your new safety as bombs in every level that you need. So importance topic is requirements traceability for not only safety but I'd also say equality and everything where you want to see what will I get when I use this. And things can go wrong. Oops. So you will really be able to see the requirement has it been implemented where is what components are affected by this requirement. Where are the tests for this requirement? Where are the test reports of this requirement? And you might have, yeah, have or you will, you know, might have, you will have issue there because that's how things are. Or you will have a CVE here one day. And there you can really then also use this to trace back where the reason for this might be. And the reason really might be that your requirement has been insufficient that you might want to create or need another requirement for this. And then set up again new traceability for this requirement. And for the new requirement also a new test that you also plug in into the framework of relationships. So it really enables you to always have a view of an actual real time view of what is in your system and what are the dependencies within your project. Not only to the outside stuff that you might pull in but also within your project. So the main, yeah, the main benefits that we will have with this profile is really that we have the complete model of dependencies. It's not, we have something here, something there and something in a book and some information you will get on the water cooler or in the coffee kitchen. And really you will be able to have deterministic impact analysis methods. There are a lot of methods around but you can really use this as input of doing an FMEA or an Ishikawa analysis or whatever you want to do. But you have really defined sources and dependencies to do this. And yeah, it's really, I think the reproducibility of everything, you will always have the same impact analysis. You will always have the same set of evidences for what you have done. And it's a very formal way then to provide the completeness evidence. It's not like in the end of a project or at the end before you release something somebody sits down with a spreadsheet and says, okay, do I have this? Do I have that? Do I have these stuff? It's just you can generate this, you can have it and as long as the tooling works you can make sure you can be sure that you have everything. And when we think about this infamous V dependency model actually you can really sort everything in S-bombs as we have them today. You can hook things up with relationships inside of this dependency model so that you can really have everything from plans to stuff, how you do things, from requirements to implementation to test. So it would be great if you could join us. We are meeting each Friday, so European time it's Friday at five, Central European time and yeah, in the mornings in the U.S. Okay. And yeah, any questions please contact Kate or me or yeah, just see us on Friday.