Yeah, okay.
So hello everybody for lunchtime talk.
We'll tell you a little bit about the SPDX safety profile that will come about 3.1, so
I'll give you a short introduction to it and then Stan will show you how we actually
apply this in the Zephyr project.
So generally what we are speaking about is we always have systems or systems of systems and
plugging this together and knowing what you have and knowing if you have all the evidences.
That's the issue that we are currently dealing with.
For those who are not familiar with functional safety, it's just a do no harm thing.
Your system should not kill you or shouldn't kill anybody, should not harm anybody.
For that, you need to know what you have, how things work,
that you have corrective actions for unexpected behavior,
that you can catch things, detect things, and that you have the evidences that you really do so.
Yeah, most people always then give me the backwards saying, hey, yeah,
safety is a system property, we cannot do this on element level.
Yeah, we can't, but we can make sure that our element brings everything on the table that you can trust,
that it behaves like you expected to behave.
So usually what are the tasks and how do we know what to do?
Yeah, there's a safety standard around that tell you what to do,
they will tell you what the deliveries or deliverables that you need to show.
They all come down to the same stuff, you need unique IDs of what you have,
you need to be traceable, what you wanted to have, what you did implement,
how you trusted it, all that to show that you're complete, to have all the evidences.
And let's say in software speak, it just means you need to define your dependencies within your project.
Yeah, functional safety projects come down to a lot of things, mainly documents.
So I don't want to read this to you, but it's a lot usually and it's quite a pain.
But these documents are in relation to each other.
So the Meme model, which is originally a process model,
more or less when you look at it from an informational knowledge point of view,
it's a dependency model.
And we need to keep these dependencies up through the whole life cycle of something and
through all the releases, through all variants, through all bug fixes, vulnerability fixes.
Yeah, variants are a big topic.
And yeah, what we can use here really are these S-bombs that we have in the software world now.
They are machine readable, they are exchangeable, and we can leverage that for our dependencies.
And yeah, lucky us, we can express these dependencies in the V-model always relationships in SPDX.
So how is the real world at the moment?
So we have more or less three types of documents in our safety documentation.
We have plans, processes, guidelines, how to do things.
We have the actual specification, what you want to have, how is your structure,
and you have all these verification and analysis evidences that you did things
the way you have been intended to do so.
Yeah, these documents are living all in their own little realms.
They live all in their little formats, their little tools, and they don't talk a lot, which is other.
So traceability usually breaks between the tools.
It's quite a pain to keep this up.
We have a very solid solution, mainly in the automotive world.
The nearly most loved engineering tool, we have exalists.
They usually also come with a very distinctive name that's very unique.
And yeah, that's how things are.
So why not put it in a little bit orderly fashion?
Use S-bombs, S-bond types, SPDX relationships to really structure a project
in a way where you really can use your relationships.
And that's what we are actually applying in the art and the SAFRA project.
SAFRA is a really brilliant little art house.
It comes with its own build system, with tests and the framework for all that you need.
We're currently adding all the systematic capability stuff like requirements, plans, the safety analysis,
and we are using StrictDoc, the tool of stand to do so, and yeah,
want to express this also with the SPDX relationships.
So for example, for requirements, this can look like this.
We have on the top level, we have the plans that are in a relationship to each other
that specify how things should be done on the specification documents level,
that specify that in the end what you need to implement,
and you have requirements, acceptance criteria,
meaning yeah, that's specifying your reviews, your tests,
all the analysis evidence that you need.
You can roll this out really through all the lifecycle of SAFRA,
so we're saying okay, we have the concept and planning phase,
we have the actual implementation phase,
we have the tests and the build, everything,
we can really put this all in SPDX relationships,
so that once we have an issue,
it's not like blind looking for the course that we had as we had before,
but we can really follow our relationships through to do analysis,
to do really maybe even automated analysis,
and we have everything in place to really identify why do we have the issue,
what do we need to do and what do we need to update in order to fix this issue.
So, thanks, Nicole, thanks everyone for having us here today.
Everyone is super fast presenting, I'll try to catch up.
So before we go to talk about the tool,
I actually want to mention a few issues about the requirements engineering in general,
this has nothing to do yet with SPDX,
so many of you probably know that the commercial requirements tool can be expensive,
and they can be sometimes ridiculously expensive,
and so one example question, how can you build a working group
that needs to actually collaborate across organizations and across tools
and across whatever, crossing all sorts of boundaries,
what if you need to exchange all of these requirements,
and very often also the worlds of requirements and software are not connected,
so there is an original, let's say, Excel document that is started somehow
with a bunch of requirements, but then developers take over,
and they somehow get excited during the development,
and then no one really knows what were the original requirements
that the system was implemented against.
And so the waterfall model actually is not designed to play well
with the open source software development,
and let's say the outcome of this is that very few open source projects
are actually developed according to formal requirements.
But everything is slowly changing,
so by now I counted over 12 tools of various degrees of maturity,
and StrikDoc actually, my tool is one of them,
and the key question that I am trying to answer for myself
and maybe for, let's say, the subset of the industry,
can we actually make requirements useful for open source software
so that developers are not annoyed, let's say, when working with requirements,
and that actually requirements become first class citizens in open source software.
And so I created this tool in 2019,
it's originating from the spacecraft avionics,
we had to exactly specify the onboard computer behavior,
and this is how we got started with just,
hey, what if we just do the text-based,
git-based requirements management, generate something,
and it turned out that actually there was a tool already called DoorStop,
and I started contributing to it,
and at some point I just realized that I'm moving a bit faster
than, let's say, getting some patches in DoorStop modifying the code,
and so I ended up doing something of my own.
We spent most of the time actually polishing the HTML documentation generator
in these years and somehow working out the traceability graph,
and the previous year was literally the year of UI programming,
so it was a lot of just making the UI support what is written in the text files.
The project goals is to make a tool that just allows you for free
and in a nice way to work with requirements.
All groups are considered, we pretty much achieved the goal
of being able to work with just PIP install in five minutes,
you can start creating and publishing your requirements,
and one core thing is that it should be very easy to get data in and out
so that no one should be locked into this tool way of doing things.
Then this is the text format that we came up with.
It's a combination of a bunch of formats,
but the main use case is that we need a format that supports both text,
writing documents, and metadata,
and so this hybrid is a practical compromise somehow,
how to achieve both.
I'm happy to be challenged on the specifics of this format,
but this is what it is for now.
By the way, the requirements are actually this statement thing,
so you always have this shale of statements,
and that's the core of what a requirements tool should do normally.
For Zephyrus, Pedex and StickDoc,
a big thanks to Roberto Bagnaro of Baxank,
he made a connection, so we introduced basically that this tool exists
to the Zephyr community, and that's how we started working together.
There was a small competition,
and the group after some time selected this tool,
and right now we are structuring the requirements
and writing the requirements in StickDoc.
I will show just in a second all this.
The interfaces of StickDoc with Zephyr are actually these text files
with the requirements with the source files of Zephyr,
the design documentation of Zephyr,
and also as of recently,
StickDoc can also produce an SPDX file with the requirements
that connects to whatever parent Zephyr SPDX to become somehow.
So now I'm really short on time,
so I try to just jump over the screens.
15 minutes.
15 minutes, okay.
So this is actually the UI that we will be,
we have been working on so hard.
The idea is that, let's say, in the IDE,
we have the text files, the storage and git,
so you can see this pretty much blocks of requirements.
They have statements, they have meta information,
and then our effort was to lift it up to the UI
so that all this becomes editable.
And so we got a bunch of features.
I just created one requirement, which is called a FOSDEM requirement
to show you how this works in Git.
So in Git, this looks pretty much like this.
So you'll see the IDE is already recognizing
that we're doing the Git-based change,
and this is how it can be committed.
Currently, we don't support auto-committing,
but the UI cannot commit the changes manually,
but we can push it using a second terminal,
just push these changes and create a commit
that will publish this text.
But what we try to do, sort of really hard,
that all this is possible to be created in the UI,
and you rarely, so the more and more rarely
you ever need to use console,
so this becomes more and more automated in the UI.
We got some other cool things.
So for example, there is now a diff feature,
so how can you actually do diffs on the requirements documents?
So when you not just want to do a Git diff,
but you actually want to explore what are the...
Sorry, let me just...
It's a bit funny speaking this way.
Sorry.
We are comparing the documentation graph,
and for each of the requirements nodes,
we specify actually what...
What...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
So...
Lend, somehow, this is a small demonstration.
Let's say we have dummy requirements specification
and has a child requirements specification,
and that child specification also links to the example.
For example, for the snippets, for the requirements,
it's possible to jump to the files
and trace how they actually link to the requirements
in the source files.
So it becomes a sort of a browser for
SPDX information with respect to requirements.
I'm not intending this to be an SPDX browser,
I just needed some way to visualize the requirements
as we are working through them with Zephyr.
And then I come back to the slides.
Let's see if we can do this.
Actually, maybe this way.
Yes, so a couple of slides, some back up.
I think we mostly turn it to the conclusions back to Nikon.
Oh, yeah.
Yeah, so the conclusion, let's say,
notes to that is that if we use this approach,
we really get finally a first way to do
the impact analysis in an orderly way.
Usually an impact analysis is, hey, who knows about this?
And you get the people in the room
and just depending on who knows what,
you might do an impact analysis.
And there might be this tool here, that tool there,
and you're a bunch of Excel lists that explain to you
what could be the right relationships between them.
So this will give us an idea of how things really are
in a project, in a certain release,
in a certain configuration, on a certain point of time.
When we use SPDX and S-bombs for this,
we can pack it, we can sign it.
So it's really, the integrity is kept completely.
Yeah.
We can formally demonstrate completeness.
So speaking, automated safety cases, automated assessments,
everything that we really want to automate
to not always have somebody manually checking
is everything is there.
So really to have checks, if you have gaps somewhere,
when you configure something, something might come up.
You have your relationships that break.
You have maybe your hashes that break
because you change something in there
and not the same as you would have expected them.
So it's, I'd say it's a really very transparent way
to see things and connect things in a safety project.
Yeah, with using StrictDoc,
we now found something that's pretty painless to use for that.
Also with respect to, yeah, nobody wants to write requirements,
nobody wants to use doors, obviously.
If you have just a tab open with your requirements document
and you can export it and you can even edit it
if you're not a coding person through the web browser.
So yeah, from the several projects perspective,
that was God sent.
And from the SPDX perspective,
I think we also have so many use cases now.
Okay.
Perfect.
Yeah, thank you.
Questions?
Yeah.
Yeah.
Really like that.
Most systems are systems, systems, systems.
So you have a very high level of requirement.
Yes.
Find out to multiple people
and they've got multiple possibilities.
Potentially some commonality as well.
How do you, you know,
consume this working on a small software project?
How does this scale to something that might be a,
mission critical system?
Yes.
The question is how does this approach
and the tools that we're using scale to larger projects.
This is what we have to explore together.
So we are starting, the tool itself started very small,
but then it was suddenly got the pressure from Zephyr
and it has to already address several requirements
coming from many directions.
And so as of now, it's somehow on the starting,
I would say.
So I mean, one of the main benefits of having like
dedicated requirements, you know, tools,
is that if that's one requirement,
you actually like notified, okay,
and this all these other requirements
that are somehow related to that requirement
might need to be updated.
Is there something that StrictOp can do?
There is no automated impact analysis.
It's on the roadmap,
but for now you can see the traceability graph.
And if you're interested about a specific requirement,
you can just, sorry, I didn't repeat the question.
The question was if there is an automated way
to highlight which requirements are affected
by a given requirement that gets modified.
So it's on the roadmap, the fancy way of doing it.
But for now you can already use kits,
you can use the change log,
and you can use also the traceability graph,
which I didn't show,
but it shows this deep traceability into,
let's say, how all the parent requirements
flow down into the child requirements.
Yeah.
Jos, there's a question.
Speak up, please.
There is a time.
I'm gonna make this my time.
Thank you.
Go ahead.
Sorry, I hope.
Can you use the mic?
No, I can't.
Then we don't lose information.
Here you go.
Yeah, I was just curious about the framework
that you've set up.
So it's really awesome.
So I'm curious with the requirements and specification,
is it like a predefined structure,
or is it just like a more abstract data type
that we can impose whatever structure we want?
It's both.
So first of all, you can do whatever you want
with the document structure
and the metadata structure requirements,
all these best practices.
You can follow whatever you want.
One thing that is happening is that
some of the public formats,
we are collecting in strict doc format,
and then you can use them directly for your traceability.
This is one thing.
The second thing is if projects like Zephyr
or whatever other projects would use this,
let's say seriously,
there will naturally be some best practice emerging
because we are preparing tools,
we are preparing the approaches,
and yeah, maybe you.
Yeah.
There's nothing to add, I think.
Exactly.
So it's.
If you want to, you can add a layer in between,
and that's awesome.
Yes, yes, it should be.
That's cool.
Thank you.
Here about how you practice in tool fields,
the requirements,
then you take your template to the site.
That was one question.
Is this stable?
If you manage to pull a file,
will you still know that it's a tool field,
and can you also link to the test to see in a tool field?
Yes.
The reason.
That's why it was.
Sorry.
Yeah.
Yes.
The question is how to automate,
how to automate,
let's say,
if a requirement has all the links,
and if all source files links together.
So for this,
exactly the search query engine was created.
You can query the graph,
and you can implement or script your own things,
or there are already default set of checks
that are implemented.
For example,
you can ask questions like,
are all parent requirements,
sorry,
are all root requirements connected to some child?
Or are all child requirements are connected to,
at least one parent,
and things like that?
So it's totally,
let's say, a flexible territory.
You can define checks that you want,
and even script it yourself by using the API.
Does it answer?
Do you have plans to build artificial intelligence to it?
Because an expert,
when I'm looking at requirements,
I can see bloats,
or some things that at the time,
I see it's there.
It seems like a very machine field for child.
Do you have plans?
There are different kinds of requirements flows.
Yeah, again, sorry,
I apologize for that.
So the question is,
if the tool can use AI
to automate the detection of flows,
and the answer is clearly yes,
but there are different kinds of flows
which are easy or not so easy to automate.
So for example,
the syntactic stuff is easy even to just lint.
You don't even need the AI.
Where this could really help is to improve the readability
of the requirements,
or let's say teach a tool
to follow some kind of guideline.
For example, the InCase requirements altering guides
provides recommendations.
They are even numbered.
You can literally take them to the tool.
It's on the roadmap,
but not yet implemented.
So the answer is totally possible,
but we're just not there yet.
Let's thank again, Nicole and start.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Really great to get some AI.
Thank you.