Next up, Nicole is going to be talking about bringing functional safety to ESMOM.
OK, maybe just leave it here.
OK, hi.
I'm Nicole and Kate and now also Alexis already announced.
I'll walk you through what we've been up in the working group for functional safety
and what we came up for SPDX 3.1 for the first release candidate.
So yeah, for those that don't know me, who is this, I've been working as an engineer
in the automotive industry mainly and then a little bit of defense and all that stuff.
The things that you do when you're from South of Germany, I somehow got as a process loving
person into the topic of functional safety, then one day I'm at Kate and now first I'm
at Shane and then I'm at Kate and the rest of the story I'm involved in some of the
LF projects that are handling functional safety, like Elisa Saffer and yeah, it was
that my first contact was Shane and I also worked with OpenChain at the beginning.
If you want to contact me or the platforms I'm on, I have the handle Nick Poplar just
try to find me GitHub discord, give me a text, I hope I'll see it and answer you.
I think I don't need to explain what's SPDX to anybody in this room, it's a language
format to describe data, what we did now mainly for our first release for functional safety
is working with the model to come up with a profile based on the models and yeah, the base
model is core, it got much more complex now for 3.1 but the important things for our
functional safety profile is for one thing element, it's a basic class that already gives
us as a lot of information that we need to document things for functional safety like
who did it, who created something, when was it created, it gives an element on unique
ID, it gives us a name and you can already add in description so it's already a lot
of things that you can describe about a basic element also there is the notion of relationships
that means yeah between elements you can have relationships that they depend on each other
in some way or the other and the idea of profiles was not invented by us from the functional
safety domain, they've been already there for quite some while in SPDX and if you want
to know more about the profiles coming up scroll back to talks about what Karen wanted to
do and Kate then did to the slides there, there's a really fantastic overview of what's
coming for 3.1, so why did we think we need to go into this so there are several use
cases that we thought about at the beginning we need to generate a set of documents and
evidences to prove that we did everything for functional safety anyhow we need to document
the complete safety life cycle we need to keep this in a readable format and all these things
so few years ago Kate and me started a group that grew with really good people to work on
that so the use cases that we're currently thinking of is to exchange and hand down a functional
safety related information in the supply chain with a complete information that you would
have in a normal safety case normal safety case in the sense of a non-standardized whatever
data blob that you publish to hand out information about planning and functional safety concepts
for those who want to get in contact with you and just want to get an overview about what's
it about and also to hand out the obligations for an integrated what do I need to do and what
do I need to think about once I take this element this piece of software with this item whatever
you want to call it and integrate it into my system what are the things that I need to do to prove
that I've done everything for functional safety another use case is the use case within the project
to have traceability between your documentation for those that's been in this world you have a lot
of stuff flying around and then in the end knowing what it's related to what over the borders
and breaks within tools it's it's a moment impossible and one of my main topics I'm looking at
is the support of automated assessments if you want to automate that you first have to standardize it
so that's where this will help to so for the first use case with the information exchange so
there's a lot of information that you actually need to have there for proving that you did everything
for functional safety is on the one hand side you have the technical topics so you want to have
a system that is robust that has maybe several channels maybe even a systematic one system
channels where you use different physical things to send or physical values like a temperature
or pressure or speed velocity or whatever or that you have several algorithms working together
or that you have an algorithm for your calculations and some monitoring function so you want to have
a very robust system set up any how that will withstand any kind of adversities that your
encounter but then on the other hand side you also have the documentation about how you're doing
things or how you did things what was the plan what is the plan how do the config management how
I do what tools do I use do I trust my tools all that stuff of information is there and then the
end it will be compiled in a really big set of documents and they usually fly around
actually when you look into it there's always three kinds of documents that you have on the
one hand side you have this family of plans process guidelines guidelines how to do things
that specify what you want to do and how you want to do it you have your requirements and your
specifications your expectations what your system needs to do how your system is behaving
and you have the the set of tests verification review inspections analyzes test reports that are
then used for documenting that you have checked everything and so that's the first really hard
thing for those who don't like the V model so yeah we still think about the V model but we don't
think about it as a sequence model so for those safety people that never got out of the bubble
that watch maybe the stream please stop thinking about this as a sequence model you will never be
finished and in the end I've seen in more than 20 years in the industry that nobody really
follows is a sequence model they just make it up in the end so please consider this as a knowledge
and a dependency model you have a base of best practices guidelines and processes to define
how you work and you have a set of information what is expected regarding behavior structure
implementation and you have a set of what is expected regarding test coverage inspection
analyzes methods and these more or less exist in parallel and please not as a series of events
how they currently exist all the these bits of information they live in different formats
these formats live in different tools and once you want to know what is related to what you
start to manually grab things together and this is still my reality out there it's a safety
or says so I usually in the end get some kind of axle monster and even that's the best case
that's partially generated partially filled manually and in the best case it has some good
name in some cases it really is some kind of where you don't know is this really the final
thing is really the valid thing has this been generated just for me is an assessor or is this
really representing everything so this is why we started to think about automating and standardizing things
and yeah why not use what's already there so there's a huge list of relationships types available
there are the models available why not work with that and on top of that what then
then learned within all the work that we did there's also this notion already with s-bombs that
there are different types of s-bombs so things that I call a safety concept where you have a
technical concept in a way you want to implement it that's already something that you can describe
with a design s-bombs you can describe what you have in your sources with your source s-bombs
finally when you're shipping a release you have the build s-bombs and you even think about a car
a vehicle that's out there on the street that's now getting updates that's creating log files
that's communicating with the mobile phones of the users you even can collect this set of data
with this s-bom idea already yeah that's what I would just that different kinds of different
parts of the life cycle you can describe with different kinds of s-bombs and how about that about
documenting the state of your functional safety yeah so the next use case within the projects
breaking up this breaks it was in the tools is look at this as a traceability model within the
project and yeah you can sort these things already to types of s-bombs and you just can describe
the dependencies or your traceability between that with s-b-dx types relationships
we use this as a proof of concept already with a set of project to describe which kinds of
plans effect our requirements management how does this break down how just information flow between
requirements of the architecture to the source code how to things relate to obligations that
will be in the safety manual so this set of how do things belong together can be already described
there and Kate and me did an exercise already a while ago to show you that between the different
phases and in the life cycle of a project you can relate things to each other and yeah
as a project evolves and gets to each it's first releases and publishes an executable or source
code and then in the end yeah you have a bug you have a behavior that you did not want and you
have no idea what to look at so and that's where usually in a normal project the process starts
who do I talk to who do I call what has been done what was the build environment or how
did it test it or what were the actual guidelines that are used to build it and this is now where
you can leverage all these traces all these relationships to automate where could it could have been
the root cause of this so specification guidelines build environment what are the coding guidelines
what is the specification maybe I had completely had the complete set of the wrong plan for it
so I can really walk through that and really find them in the end what was the issue solve
solve the issue remove the root cause and then have a sustainable way to move forward
so yeah we all know you can't eat the big burger of a safety case with one bite so what we
started with was talking about yeah requirements so what do we expect regarding behavior and
structure verification so how do we review inspect and test and how do we document the outcome
of the tests and inspections and analysis whatever um as I said in beginning we have these three
types so that's what we followed on um to document all the uh work products that we want to have
and so we have we don't cover everything from a V model perspective V model as a knowledge model
a model please not as a sequence model we don't cover everything now with 3.1 but as we're moving
forward there will be more and if or how things are now look for release candidate 1 are that yeah
we first thing we talked about requirements and what do we expect from a requirement how our
requirements typically structured and the solution was we are using the base element as a starting
point so yeah element already has an ID we want a unique ID we want to trace the we want to identify
the requirement very clearly we want to to give it a name we want to describe it we want to know
who created it when it was created and how so this already comes a lot from um element what we want
to have additionally in a requirement is really yeah um how will I verify this so the integrity method
how um where does this belong to this is a requirement really for development for implementing
behavior this is a requirement for the integrator how do I integrate this in my final system
this is maybe a requirement for the operator so you you need to know that and also yeah for
sure capture the text of the requirement and also a rational why the requirement is in the way it is
and also so we created also here a new kind of relationship to see an hierarchy of requirements like you
have a functional description what you expect from the behavior a technical description how it is
actually implemented what kind of technology you use and maybe some details design how you plug
all this together and or maybe how our flow charts um within um your final application and you can
really again plug this together with this trace to detail level um the next thing is yeah having
requirements is fine and having an implementation is fine but yeah and in in functional safety we
want to really also have a verification that we did the thing we wanted to do and so it looks
pretty similar to what we came up with the requirement but a little bit different um we have these
batix things we take over from element and we have these things like yeah you need to have
preconditions what needs to be there what needs to be initialized whatever before you start your
verification and what are your expectations and and conditions that you said I did my verification
we also um added verification types to identify what has been done is the test is the review
a demonstration whatever and when you look into what's there for traceability it starts to look
a lot about the knowledge model we want to have so really can set up your hierarchy of requirements
you can set up your hierarchy um of verification methods and you can link them together um the last thing
we um did before the release candidate was um talking about yeah test test results evidences
and the important thing um that we saw in the end was there is a really endless um amount
and types of test logs, checklist types so it's really hard to put down your finger and
come up with a model to what is really generated during a verification is it a test log whatever
it is it's a bunch of data that is for sure of type element but definitely not you can't um break it
down through the what you can do or what you have to do is take this log and uh evaluate is this
what I wanted to have is this sufficient is this enough and then clearly identify why did you do
this decision where does it come from so um we seen this making this kind of decision forces us
to bring up a new kind of relationship because yeah we can say this test log belongs to this test
report where we say it's okay but it's to make this relationship um more formal so it works in
the functional safety well we need it to add a unique a universal idea that's why we have this new
relationship type based on relationship so the relationship has evidence so it's it's not a break
from the flow it's just that we um added a little bit more more content relationship so and yeah
it also fits quite well with it was in our knowledge model that for each verification you can
have the set of uh something some logs some checklist some whatever data stream is generated out
of my verification and I can relate this to my final evaluation my test report if I'm fine with
that or not um there are few things we have in the pipeline because yes usually when I talk about
this people will tell me yeah you know we do this also for quality management things are done
like this anyhow and the newest bus word they they throw at me is like don't you need a lot of these
things for CRA yes so we more and more now move into saying this we'll go into uh uh profile
that's more uh on the level of systems engineering with then special add-ons and flavors for
functional safety for proving you have a security process applied for whatever engineering
who you want to represent for your normal quality management so um yeah things can relate to each
other and also when you see we usually I see a lot of set of what we have a safety team and we have
a security team and then they all do their documentation and they do things double and the beauty
of this will be that we can relate these sibling topics to each other so that they only do it once
what we also need to talk about and what we started but what did not go into the first release
candidate is product line engineering how do I represent variance of functionality of or if
implementation to each other so how do I see I come from the automotive so how do I express variance
between uh battery electric vehicle and one with a combustion engine I will have the same requirements
regarding it needs to drive what I would have different requirements regarding talk gear rate how I
implement some driving strategy how do I do things how do I describe a task how does this get into a
process how do I give more information about agents so um when you look uh looking to what are
you asked when you create something does this is this person tool or organization really qualified
to do this how it has it been done what roles are there so these are things that we need to look
into there is already a notion of agents and SPDX so I don't think we will run in any issue it's just
we need to talk to each other from different verticals and different ideas to come up with a model
that works for everybody so so far what we see is yeah what we are doing really works for automating things
some people take what we have and put it into their tooling put it into their way of thinking
and think it's through if it works so it looks like it it will enable the standardization
automation of assessments and exchange of information the impact analyzes like I said was traceability
it will be too lucknostic you can collect data where our various tools and data types and it
fully supports this everything is code approach so from an assessor perspective I would call it
compliance is code so it's an ongoing discussion you're welcome to participate if you want to
know more ask Kate or me or ask the mailing list show up at our call it's on Friday evening
your pen time I know it's not very agent friendly but I think we can manage something in a different
time slot on top so that's it and I think I have a few minutes for questions right
thank you
Yeah, I'm just wondering how scale of life is?
You want to?
How scale of life is?
When I think of systementially, I think of what we have.
The system says, I want to build a boat.
I've got 10 of quite a lot.
The time I end the wheel is supply chain.
I've got 50s out in the tank.
And it's all in.
We couldn't solve commercial contracts for which it did happen.
Yeah.
So, answer that.
How do you get how do you make sure that we've been working with that
from this particular perspective, sort of?
Oh, I can't do that.
It's together.
Yeah.
So, Anthony here was asking the very very question, how will this scale?
Because we're going to start with a small project,
maybe building a boat, I might have 10 requirements at the beginning.
And once I have everything down, the supply chain and procurement
are might have a real blob of things.
Now, see, it's just another thing that relates to each other.
So, these requirements will come from different sources.
And they will come with their own blob of knowledge graph.
So, these, let's call it, let's call it a little bit more blah blah blah blah.
Yeah.
So, this.
Yeah.
Same to requirements for the project.
I had a paper on the doctor's.
Yeah.
You told that this morning, yeah.
So, basically, you don't know if you can keep that.
Work out what it finds just like a, and then work out all the evidence and a cost
of the time.
Yeah.
You know.
Yeah.
So, the thing is really, yeah.
You can, I think this system works even better when, as I said,
Anthony said, there is a real life project out there with 800 pages of requirements.
And yeah, you can, with this, it's even easier to filter and attach things to their
job fully, existing verification and evidence of the verification.
Helio?
Good job.
With the question, do you think that you do have traction and are, to replace the cell
and make the two people happy?
Yes.
So, Helio was asking if, I think, we have enough traction to replace the manual stuff
done for ISO 26, 26, and make automotive people happy.
Actually, yes.
Because my biggest pain point is I work in automotive since 1999.
So, I'm out there for quite some time.
First, as somebody out in manufacturing, going to the vehicle, going, then changing
side of the table as an assessor and now being back as a consultant.
So, the big pain point really is that you go out with your vehicle, you have your software
ready and then you go to Finland and you start adding your calibration data and really
knowing in the end, what list of calibration data belongs to this version of the vehicle
that's now on the conveyor belt.
This is something that I need to have there automated.
And once I go to Finland and I set up my set up of calibration data and put this back
into my database and somebody will just push a button and say, okay, this is the safety
as bomb for this vehicle, including exactly this calibration data that has been created
by this person with this tool on this day in Finland.
Hopefully.
But the automotive people, I talk to, so it's not just your corporation, I talk to others
and they are usually like, oh, this would be so great.
When I was a developer out there, it was really like, the test team came in and said, you
did not implement this.
I said, I hear now for the first time that I need to implement this.
Then I went to my software architect, I don't know about the software architect run for functional
level where do we get the information?
Oh, yeah, you know, there is this list from the previous release on this SharePoint
Drive.
You can start with this.
Thank you very much.