WEBVTT 00:00.000 --> 00:29.240 Next up, Nicole is going to be talking about bringing functional safety to ESMOM. 00:29.240 --> 00:33.240 OK, maybe just leave it here. 00:33.240 --> 00:35.560 OK, hi. 00:35.560 --> 00:40.000 I'm Nicole and Kate and now also Alexis already announced. 00:40.000 --> 00:45.240 I'll walk you through what we've been up in the working group for functional safety 00:45.240 --> 00:52.600 and what we came up for SPDX 3.1 for the first release candidate. 00:52.600 --> 00:59.720 So yeah, for those that don't know me, who is this, I've been working as an engineer 00:59.720 --> 01:03.760 in the automotive industry mainly and then a little bit of defense and all that stuff. 01:03.760 --> 01:11.880 The things that you do when you're from South of Germany, I somehow got as a process loving 01:11.880 --> 01:18.400 person into the topic of functional safety, then one day I'm at Kate and now first I'm 01:18.400 --> 01:25.000 at Shane and then I'm at Kate and the rest of the story I'm involved in some of the 01:25.000 --> 01:33.240 LF projects that are handling functional safety, like Elisa Saffer and yeah, it was 01:33.240 --> 01:37.840 that my first contact was Shane and I also worked with OpenChain at the beginning. 01:37.840 --> 01:44.520 If you want to contact me or the platforms I'm on, I have the handle Nick Poplar just 01:44.520 --> 01:53.520 try to find me GitHub discord, give me a text, I hope I'll see it and answer you. 01:53.520 --> 01:58.600 I think I don't need to explain what's SPDX to anybody in this room, it's a language 01:58.600 --> 02:05.600 format to describe data, what we did now mainly for our first release for functional safety 02:05.600 --> 02:13.120 is working with the model to come up with a profile based on the models and yeah, the base 02:13.120 --> 02:22.200 model is core, it got much more complex now for 3.1 but the important things for our 02:22.200 --> 02:28.640 functional safety profile is for one thing element, it's a basic class that already gives 02:28.640 --> 02:36.200 us as a lot of information that we need to document things for functional safety like 02:36.240 --> 02:44.600 who did it, who created something, when was it created, it gives an element on unique 02:44.600 --> 02:49.000 ID, it gives us a name and you can already add in description so it's already a lot 02:49.000 --> 02:56.680 of things that you can describe about a basic element also there is the notion of relationships 02:56.680 --> 03:02.720 that means yeah between elements you can have relationships that they depend on each other 03:02.720 --> 03:10.720 in some way or the other and the idea of profiles was not invented by us from the functional 03:10.720 --> 03:17.920 safety domain, they've been already there for quite some while in SPDX and if you want 03:17.920 --> 03:22.920 to know more about the profiles coming up scroll back to talks about what Karen wanted to 03:22.920 --> 03:27.240 do and Kate then did to the slides there, there's a really fantastic overview of what's 03:27.240 --> 03:37.160 coming for 3.1, so why did we think we need to go into this so there are several use 03:37.160 --> 03:42.960 cases that we thought about at the beginning we need to generate a set of documents and 03:42.960 --> 03:48.840 evidences to prove that we did everything for functional safety anyhow we need to document 03:48.840 --> 03:53.400 the complete safety life cycle we need to keep this in a readable format and all these things 03:53.400 --> 04:00.040 so few years ago Kate and me started a group that grew with really good people to work on 04:00.040 --> 04:09.400 that so the use cases that we're currently thinking of is to exchange and hand down a functional 04:09.400 --> 04:15.400 safety related information in the supply chain with a complete information that you would 04:15.400 --> 04:23.320 have in a normal safety case normal safety case in the sense of a non-standardized whatever 04:23.320 --> 04:32.360 data blob that you publish to hand out information about planning and functional safety concepts 04:32.360 --> 04:38.600 for those who want to get in contact with you and just want to get an overview about what's 04:38.600 --> 04:44.920 it about and also to hand out the obligations for an integrated what do I need to do and what 04:44.920 --> 04:51.080 do I need to think about once I take this element this piece of software with this item whatever 04:51.160 --> 04:56.680 you want to call it and integrate it into my system what are the things that I need to do to prove 04:56.680 --> 05:02.520 that I've done everything for functional safety another use case is the use case within the project 05:02.520 --> 05:09.960 to have traceability between your documentation for those that's been in this world you have a lot 05:09.960 --> 05:18.040 of stuff flying around and then in the end knowing what it's related to what over the borders 05:18.520 --> 05:25.880 and breaks within tools it's it's a moment impossible and one of my main topics I'm looking at 05:25.880 --> 05:33.480 is the support of automated assessments if you want to automate that you first have to standardize it 05:33.480 --> 05:41.880 so that's where this will help to so for the first use case with the information exchange so 05:41.880 --> 05:47.000 there's a lot of information that you actually need to have there for proving that you did everything 05:47.080 --> 05:51.720 for functional safety is on the one hand side you have the technical topics so you want to have 05:51.720 --> 05:59.640 a system that is robust that has maybe several channels maybe even a systematic one system 05:59.640 --> 06:08.920 channels where you use different physical things to send or physical values like a temperature 06:09.000 --> 06:19.160 or pressure or speed velocity or whatever or that you have several algorithms working together 06:19.160 --> 06:27.240 or that you have an algorithm for your calculations and some monitoring function so you want to have 06:27.240 --> 06:35.880 a very robust system set up any how that will withstand any kind of adversities that your 06:36.520 --> 06:41.160 encounter but then on the other hand side you also have the documentation about how you're doing 06:41.160 --> 06:48.200 things or how you did things what was the plan what is the plan how do the config management how 06:48.200 --> 06:55.000 I do what tools do I use do I trust my tools all that stuff of information is there and then the 06:55.000 --> 07:00.360 end it will be compiled in a really big set of documents and they usually fly around 07:00.440 --> 07:06.200 actually when you look into it there's always three kinds of documents that you have on the 07:06.200 --> 07:12.760 one hand side you have this family of plans process guidelines guidelines how to do things 07:13.800 --> 07:18.760 that specify what you want to do and how you want to do it you have your requirements and your 07:18.760 --> 07:24.680 specifications your expectations what your system needs to do how your system is behaving 07:24.760 --> 07:33.560 and you have the the set of tests verification review inspections analyzes test reports that are 07:33.560 --> 07:42.840 then used for documenting that you have checked everything and so that's the first really hard 07:42.840 --> 07:49.960 thing for those who don't like the V model so yeah we still think about the V model but we don't 07:49.960 --> 07:56.120 think about it as a sequence model so for those safety people that never got out of the bubble 07:56.120 --> 08:02.280 that watch maybe the stream please stop thinking about this as a sequence model you will never be 08:02.280 --> 08:09.160 finished and in the end I've seen in more than 20 years in the industry that nobody really 08:09.160 --> 08:14.840 follows is a sequence model they just make it up in the end so please consider this as a knowledge 08:14.840 --> 08:22.440 and a dependency model you have a base of best practices guidelines and processes to define 08:22.440 --> 08:29.640 how you work and you have a set of information what is expected regarding behavior structure 08:29.640 --> 08:36.360 implementation and you have a set of what is expected regarding test coverage inspection 08:36.440 --> 08:45.880 analyzes methods and these more or less exist in parallel and please not as a series of events 08:48.200 --> 08:53.240 how they currently exist all the these bits of information they live in different formats 08:53.240 --> 09:00.120 these formats live in different tools and once you want to know what is related to what you 09:00.120 --> 09:07.480 start to manually grab things together and this is still my reality out there it's a safety 09:07.480 --> 09:16.520 or says so I usually in the end get some kind of axle monster and even that's the best case 09:17.320 --> 09:25.000 that's partially generated partially filled manually and in the best case it has some good 09:25.880 --> 09:32.040 name in some cases it really is some kind of where you don't know is this really the final 09:32.040 --> 09:37.080 thing is really the valid thing has this been generated just for me is an assessor or is this 09:37.080 --> 09:44.440 really representing everything so this is why we started to think about automating and standardizing things 09:45.720 --> 09:52.520 and yeah why not use what's already there so there's a huge list of relationships types available 09:52.680 --> 09:58.600 there are the models available why not work with that and on top of that what then 09:58.600 --> 10:04.200 then learned within all the work that we did there's also this notion already with s-bombs that 10:04.200 --> 10:09.400 there are different types of s-bombs so things that I call a safety concept where you have a 10:09.400 --> 10:14.600 technical concept in a way you want to implement it that's already something that you can describe 10:14.600 --> 10:20.680 with a design s-bombs you can describe what you have in your sources with your source s-bombs 10:20.680 --> 10:28.120 finally when you're shipping a release you have the build s-bombs and you even think about a car 10:28.120 --> 10:35.960 a vehicle that's out there on the street that's now getting updates that's creating log files 10:37.320 --> 10:45.480 that's communicating with the mobile phones of the users you even can collect this set of data 10:45.480 --> 10:53.000 with this s-bom idea already yeah that's what I would just that different kinds of different 10:53.000 --> 10:59.160 parts of the life cycle you can describe with different kinds of s-bombs and how about that about 10:59.160 --> 11:08.600 documenting the state of your functional safety yeah so the next use case within the projects 11:08.600 --> 11:17.080 breaking up this breaks it was in the tools is look at this as a traceability model within the 11:17.080 --> 11:25.560 project and yeah you can sort these things already to types of s-bombs and you just can describe 11:25.560 --> 11:30.520 the dependencies or your traceability between that with s-b-dx types relationships 11:31.400 --> 11:39.160 we use this as a proof of concept already with a set of project to describe which kinds of 11:39.160 --> 11:48.920 plans effect our requirements management how does this break down how just information flow between 11:48.920 --> 11:57.080 requirements of the architecture to the source code how to things relate to obligations that 11:57.160 --> 12:04.280 will be in the safety manual so this set of how do things belong together can be already described 12:04.280 --> 12:12.520 there and Kate and me did an exercise already a while ago to show you that between the different 12:12.520 --> 12:19.960 phases and in the life cycle of a project you can relate things to each other and yeah 12:20.280 --> 12:28.920 as a project evolves and gets to each it's first releases and publishes an executable or source 12:28.920 --> 12:37.720 code and then in the end yeah you have a bug you have a behavior that you did not want and you 12:37.720 --> 12:42.600 have no idea what to look at so and that's where usually in a normal project the process starts 12:42.760 --> 12:49.720 who do I talk to who do I call what has been done what was the build environment or how 12:49.720 --> 12:56.920 did it test it or what were the actual guidelines that are used to build it and this is now where 12:56.920 --> 13:05.160 you can leverage all these traces all these relationships to automate where could it could have been 13:05.160 --> 13:11.160 the root cause of this so specification guidelines build environment what are the coding guidelines 13:11.160 --> 13:17.000 what is the specification maybe I had completely had the complete set of the wrong plan for it 13:17.000 --> 13:22.280 so I can really walk through that and really find them in the end what was the issue solve 13:22.280 --> 13:27.080 solve the issue remove the root cause and then have a sustainable way to move forward 13:29.080 --> 13:36.040 so yeah we all know you can't eat the big burger of a safety case with one bite so what we 13:36.040 --> 13:40.920 started with was talking about yeah requirements so what do we expect regarding behavior and 13:40.920 --> 13:49.080 structure verification so how do we review inspect and test and how do we document the outcome 13:49.080 --> 13:56.840 of the tests and inspections and analysis whatever um as I said in beginning we have these three 13:56.840 --> 14:05.080 types so that's what we followed on um to document all the uh work products that we want to have 14:06.440 --> 14:14.920 and so we have we don't cover everything from a V model perspective V model as a knowledge model 14:14.920 --> 14:21.480 a model please not as a sequence model we don't cover everything now with 3.1 but as we're moving 14:21.480 --> 14:30.360 forward there will be more and if or how things are now look for release candidate 1 are that yeah 14:30.360 --> 14:37.400 we first thing we talked about requirements and what do we expect from a requirement how our 14:37.400 --> 14:45.080 requirements typically structured and the solution was we are using the base element as a starting 14:45.240 --> 14:51.880 point so yeah element already has an ID we want a unique ID we want to trace the we want to identify 14:51.880 --> 14:58.120 the requirement very clearly we want to to give it a name we want to describe it we want to know 14:58.120 --> 15:06.040 who created it when it was created and how so this already comes a lot from um element what we want 15:06.040 --> 15:12.680 to have additionally in a requirement is really yeah um how will I verify this so the integrity method 15:12.840 --> 15:22.760 how um where does this belong to this is a requirement really for development for implementing 15:22.760 --> 15:28.120 behavior this is a requirement for the integrator how do I integrate this in my final system 15:28.120 --> 15:34.280 this is maybe a requirement for the operator so you you need to know that and also yeah for 15:34.280 --> 15:40.920 sure capture the text of the requirement and also a rational why the requirement is in the way it is 15:41.960 --> 15:48.840 and also so we created also here a new kind of relationship to see an hierarchy of requirements like you 15:48.840 --> 15:55.000 have a functional description what you expect from the behavior a technical description how it is 15:55.000 --> 16:00.920 actually implemented what kind of technology you use and maybe some details design how you plug 16:01.000 --> 16:08.200 all this together and or maybe how our flow charts um within um your final application and you can 16:08.200 --> 16:16.920 really again plug this together with this trace to detail level um the next thing is yeah having 16:16.920 --> 16:24.280 requirements is fine and having an implementation is fine but yeah and in in functional safety we 16:24.360 --> 16:31.960 want to really also have a verification that we did the thing we wanted to do and so it looks 16:33.000 --> 16:40.920 pretty similar to what we came up with the requirement but a little bit different um we have these 16:40.920 --> 16:45.720 batix things we take over from element and we have these things like yeah you need to have 16:45.720 --> 16:51.480 preconditions what needs to be there what needs to be initialized whatever before you start your 16:51.560 --> 16:57.240 verification and what are your expectations and and conditions that you said I did my verification 16:57.960 --> 17:04.680 we also um added verification types to identify what has been done is the test is the review 17:04.680 --> 17:14.680 a demonstration whatever and when you look into what's there for traceability it starts to look 17:14.680 --> 17:21.400 a lot about the knowledge model we want to have so really can set up your hierarchy of requirements 17:21.400 --> 17:29.640 you can set up your hierarchy um of verification methods and you can link them together um the last thing 17:29.640 --> 17:39.000 we um did before the release candidate was um talking about yeah test test results evidences 17:39.880 --> 17:48.920 and the important thing um that we saw in the end was there is a really endless um amount 17:48.920 --> 17:57.480 and types of test logs, checklist types so it's really hard to put down your finger and 17:57.480 --> 18:05.240 come up with a model to what is really generated during a verification is it a test log whatever 18:05.240 --> 18:14.360 it is it's a bunch of data that is for sure of type element but definitely not you can't um break it 18:14.440 --> 18:20.840 down through the what you can do or what you have to do is take this log and uh evaluate is this 18:20.840 --> 18:27.560 what I wanted to have is this sufficient is this enough and then clearly identify why did you do 18:27.560 --> 18:35.240 this decision where does it come from so um we seen this making this kind of decision forces us 18:35.240 --> 18:41.880 to bring up a new kind of relationship because yeah we can say this test log belongs to this test 18:41.960 --> 18:49.960 report where we say it's okay but it's to make this relationship um more formal so it works in 18:49.960 --> 18:55.720 the functional safety well we need it to add a unique a universal idea that's why we have this new 18:55.720 --> 19:02.120 relationship type based on relationship so the relationship has evidence so it's it's not a break 19:02.120 --> 19:10.120 from the flow it's just that we um added a little bit more more content relationship so and yeah 19:10.920 --> 19:17.000 it also fits quite well with it was in our knowledge model that for each verification you can 19:17.000 --> 19:25.560 have the set of uh something some logs some checklist some whatever data stream is generated out 19:25.560 --> 19:34.040 of my verification and I can relate this to my final evaluation my test report if I'm fine with 19:34.040 --> 19:42.200 that or not um there are few things we have in the pipeline because yes usually when I talk about 19:42.200 --> 19:48.200 this people will tell me yeah you know we do this also for quality management things are done 19:48.200 --> 19:54.680 like this anyhow and the newest bus word they they throw at me is like don't you need a lot of these 19:54.680 --> 20:04.200 things for CRA yes so we more and more now move into saying this we'll go into uh uh profile 20:04.200 --> 20:11.160 that's more uh on the level of systems engineering with then special add-ons and flavors for 20:11.160 --> 20:17.640 functional safety for proving you have a security process applied for whatever engineering 20:17.720 --> 20:24.920 who you want to represent for your normal quality management so um yeah things can relate to each 20:24.920 --> 20:30.760 other and also when you see we usually I see a lot of set of what we have a safety team and we have 20:30.760 --> 20:36.200 a security team and then they all do their documentation and they do things double and the beauty 20:36.200 --> 20:41.960 of this will be that we can relate these sibling topics to each other so that they only do it once 20:42.360 --> 20:49.240 what we also need to talk about and what we started but what did not go into the first release 20:49.240 --> 20:55.880 candidate is product line engineering how do I represent variance of functionality of or if 20:55.880 --> 21:03.640 implementation to each other so how do I see I come from the automotive so how do I express variance 21:03.640 --> 21:10.440 between uh battery electric vehicle and one with a combustion engine I will have the same requirements 21:10.520 --> 21:19.320 regarding it needs to drive what I would have different requirements regarding talk gear rate how I 21:20.520 --> 21:27.640 implement some driving strategy how do I do things how do I describe a task how does this get into a 21:27.640 --> 21:36.600 process how do I give more information about agents so um when you look uh looking to what are 21:36.600 --> 21:42.840 you asked when you create something does this is this person tool or organization really qualified 21:42.840 --> 21:50.360 to do this how it has it been done what roles are there so these are things that we need to look 21:50.360 --> 21:56.760 into there is already a notion of agents and SPDX so I don't think we will run in any issue it's just 21:56.760 --> 22:02.840 we need to talk to each other from different verticals and different ideas to come up with a model 22:02.920 --> 22:13.080 that works for everybody so so far what we see is yeah what we are doing really works for automating things 22:15.160 --> 22:22.600 some people take what we have and put it into their tooling put it into their way of thinking 22:22.600 --> 22:29.800 and think it's through if it works so it looks like it it will enable the standardization 22:29.880 --> 22:37.320 automation of assessments and exchange of information the impact analyzes like I said was traceability 22:38.440 --> 22:47.160 it will be too lucknostic you can collect data where our various tools and data types and it 22:47.160 --> 22:54.520 fully supports this everything is code approach so from an assessor perspective I would call it 22:54.520 --> 23:02.760 compliance is code so it's an ongoing discussion you're welcome to participate if you want to 23:02.760 --> 23:09.320 know more ask Kate or me or ask the mailing list show up at our call it's on Friday evening 23:09.320 --> 23:17.880 your pen time I know it's not very agent friendly but I think we can manage something in a different 23:17.880 --> 23:22.520 time slot on top so that's it and I think I have a few minutes for questions right 23:22.760 --> 23:26.920 thank you 23:26.920 --> 23:39.920 Yeah, I'm just wondering how scale of life is? 23:39.920 --> 23:40.920 You want to? 23:40.920 --> 23:41.920 How scale of life is? 23:41.920 --> 23:44.920 When I think of systementially, I think of what we have. 23:44.920 --> 23:47.920 The system says, I want to build a boat. 23:47.920 --> 23:49.920 I've got 10 of quite a lot. 23:49.920 --> 23:51.920 The time I end the wheel is supply chain. 23:51.920 --> 23:54.920 I've got 50s out in the tank. 23:54.920 --> 23:55.920 And it's all in. 23:55.920 --> 23:58.920 We couldn't solve commercial contracts for which it did happen. 23:58.920 --> 23:59.920 Yeah. 23:59.920 --> 24:00.920 So, answer that. 24:00.920 --> 24:04.920 How do you get how do you make sure that we've been working with that 24:04.920 --> 24:07.920 from this particular perspective, sort of? 24:07.920 --> 24:10.920 Oh, I can't do that. 24:10.920 --> 24:11.920 It's together. 24:11.920 --> 24:12.920 Yeah. 24:12.920 --> 24:17.920 So, Anthony here was asking the very very question, how will this scale? 24:17.920 --> 24:20.920 Because we're going to start with a small project, 24:20.920 --> 24:23.920 maybe building a boat, I might have 10 requirements at the beginning. 24:23.920 --> 24:27.920 And once I have everything down, the supply chain and procurement 24:27.920 --> 24:33.920 are might have a real blob of things. 24:33.920 --> 24:39.920 Now, see, it's just another thing that relates to each other. 24:39.920 --> 24:43.920 So, these requirements will come from different sources. 24:43.920 --> 24:47.920 And they will come with their own blob of knowledge graph. 24:47.920 --> 24:57.920 So, these, let's call it, let's call it a little bit more blah blah blah blah. 24:57.920 --> 24:58.920 Yeah. 24:58.920 --> 24:59.920 So, this. 24:59.920 --> 25:00.920 So, this. 25:00.920 --> 25:01.920 Yeah. 25:01.920 --> 25:03.920 Same to requirements for the project. 25:03.920 --> 25:05.920 I had a paper on the doctor's. 25:05.920 --> 25:06.920 Yeah. 25:06.920 --> 25:07.920 You told that this morning, yeah. 25:07.920 --> 25:10.920 So, basically, you don't know if you can keep that. 25:10.920 --> 25:15.920 Work out what it finds just like a, and then work out all the evidence and a cost 25:15.920 --> 25:16.920 of the time. 25:16.920 --> 25:17.920 Yeah. 25:17.920 --> 25:18.920 Yeah. 25:18.920 --> 25:19.920 You know. 25:19.920 --> 25:20.920 Yeah. 25:20.920 --> 25:22.920 So, the thing is really, yeah. 25:22.920 --> 25:26.920 You can, I think this system works even better when, as I said, 25:26.920 --> 25:32.920 Anthony said, there is a real life project out there with 800 pages of requirements. 25:32.920 --> 25:40.920 And yeah, you can, with this, it's even easier to filter and attach things to their 25:40.920 --> 25:46.920 job fully, existing verification and evidence of the verification. 25:46.920 --> 25:47.920 Helio? 25:47.920 --> 25:48.920 Good job. 25:48.920 --> 25:49.920 Good job. 25:49.920 --> 25:54.920 With the question, do you think that you do have traction and are, to replace the cell 25:54.920 --> 25:56.920 and make the two people happy? 25:56.920 --> 25:57.920 Yes. 25:57.920 --> 26:05.920 So, Helio was asking if, I think, we have enough traction to replace the manual stuff 26:05.920 --> 26:09.920 done for ISO 26, 26, and make automotive people happy. 26:09.920 --> 26:10.920 Actually, yes. 26:10.920 --> 26:17.920 Because my biggest pain point is I work in automotive since 1999. 26:17.920 --> 26:20.920 So, I'm out there for quite some time. 26:20.920 --> 26:27.920 First, as somebody out in manufacturing, going to the vehicle, going, then changing 26:27.920 --> 26:30.920 side of the table as an assessor and now being back as a consultant. 26:30.920 --> 26:37.920 So, the big pain point really is that you go out with your vehicle, you have your software 26:37.920 --> 26:44.920 ready and then you go to Finland and you start adding your calibration data and really 26:44.920 --> 26:50.920 knowing in the end, what list of calibration data belongs to this version of the vehicle 26:50.920 --> 26:53.920 that's now on the conveyor belt. 26:53.920 --> 26:56.920 This is something that I need to have there automated. 26:56.920 --> 27:03.920 And once I go to Finland and I set up my set up of calibration data and put this back 27:03.920 --> 27:11.920 into my database and somebody will just push a button and say, okay, this is the safety 27:11.920 --> 27:16.920 as bomb for this vehicle, including exactly this calibration data that has been created 27:16.920 --> 27:21.920 by this person with this tool on this day in Finland. 27:21.920 --> 27:23.920 Hopefully. 27:23.920 --> 27:30.920 But the automotive people, I talk to, so it's not just your corporation, I talk to others 27:30.920 --> 27:34.920 and they are usually like, oh, this would be so great. 27:34.920 --> 27:39.920 When I was a developer out there, it was really like, the test team came in and said, you 27:39.920 --> 27:40.920 did not implement this. 27:40.920 --> 27:43.920 I said, I hear now for the first time that I need to implement this. 27:43.920 --> 27:49.920 Then I went to my software architect, I don't know about the software architect run for functional 27:49.920 --> 27:51.920 level where do we get the information? 27:51.920 --> 27:56.920 Oh, yeah, you know, there is this list from the previous release on this SharePoint 27:56.920 --> 27:57.920 Drive. 27:57.920 --> 28:03.920 You can start with this. 28:03.920 --> 28:08.920 Thank you very much.