You
It's
Hello.
It's working.
You can you can hear me?
You can hear me.
Just speak.
Please call that guy.
Oh, it's all the following.
Okay.
Thank you so much.
Okay.
Sorry.
Say it.
Go from J.
And Puzzle.
Puzzle in the School of the Knowledgeies.
Okay.
Hello, everyone.
Today's session is about bezel.
It is an open source software to
three software requirements,
create a possibility matrix.
And it also supports the export of work item in a
design as bomb.
So that is the goal of this session is to
present this tool that can be used to
design and to maintain some work items,
especially in critical software application.
And how we can use this tool to export those
work items in SPDX model three.
That can be consumed by other piece of
the tool chain in critical application.
So my name is Luigi.
I work at red dot and I'm a bullet engineer.
And yeah, the agenda is about like an
introduction of this tool.
Then I will show an example of a
responsibility in a software development
lifecycle with the focus on automotive.
That is a V model.
And then we will see how we can use bezel in
that context of the V model.
And how we can use bezel to export
an SPDX model three.
And then few words around it's testing infrastructure
and test results as ability that can be
of some interest for the audience.
So the tool has been developed at red dot
as part of our approach to functionality
ISO 262 compliance certification.
And its name comes from one of the
integrity level that the standard is describing
that is a AZB.
That was our target for automotive.
And it was presented to a
laser project of Linux Foundation.
That is the acronym of enabling Linux in
safety application.
In 2023, and then we upstream
this tool under the ELISA GitHub.
So actually you can found the tool at the website
that is available on this
quite good.
So the goal of this tool, as I said,
is to be able to create
work items, not only software requirements,
we will see later to create
those requirements to the specification
and to the source code.
So that is a description of how the tool works.
So essentially, in basically you can specify
software components with different
version and you can collect in libraries.
Once you specify software components,
you can define your reference document.
That is the base of your accessibility.
So it can be yours of the specification.
Yours is code, a safety manual, whatever
document makes sense for your project to
develop your disability on top of it.
And once we have that document,
define it, you can start
you can start to create your work items.
The same time you create work items,
you are defining the traceability.
Because you can specify a section of
the reference document that are
quite common naming as pdx,
snippet.
And you can attach on top of those snippets
of your work items.
So here, the description of which
work item you can specify in
the relationship that you can create
inside the tool.
So we can have multiple level of
software requirements,
nested in any way.
And then we can create a test specification.
Test case is justification and
documents.
And we can also link test results to test case
is because basic comes with its own
test infrastructure.
But it is also able to trace test cases
that are executed on external testing
infrastructure.
A quick overview of the work items.
So essentially for software requirements,
you can create an hierarchical mapping.
So you can have multiple level of
software requirements.
Test specification are essentially the
description of how to test
software functionality.
It comes with some information around
the pre-condition, maneuver,
and the expected behavior of your test.
That is really disconnected by the implementation
that is supposed to be described
by the test case.
So that is referred to the implementation.
It can be also usually as
embedded as a remote file.
But it can be also some local
file in your instance.
And then we have a custom work item that
is justification.
We added this work item to provide
the completeness of analysis.
So there are software specification that
not refer to multiple things that are
really general purpose.
So to provide that in
further access or a document that
described that your analysis is
really complete, you can leverage
this work item to say.
For example, this section is related to
another software component.
We will take care of that in
other analysis.
And then document is a general
purpose work item that can be
of two types, file and text.
In case of text, you can specify
as an impact of the file.
So imagine that you can refer the implementation
of an API inside the file to
your software specification.
So you can specify it really.
In bite range, where is this
API?
And doing that,
basically also provide an
automatic validation of the link.
So each time you open the mapping,
it will check the link is valid.
So if the file change up
three more or whatever you have your
source code or file,
now you will be notified because
it will be like an invalid link.
And the document can be
mapped to the reference document
with any kind of relationship type
defined by SPDX model three.
And actually, we can have only
a flat level of document mapped
to the specification,
but the idea is to have an
hierarchical mapping.
So we can describe
scenario like we have just
as an example.
We can trace the training data set of
an M model to the AI model and
to the specification.
So just a possible application.
And then we have a test run.
So of test result as you
want to name it.
To the one, we can also link
the test run configuration.
And we have test run configuration
because usually test cases
are things that can be
configurable.
So the behavior of a test case
can change with some parameters.
So just imagine,
I don't know,
LTP, a suite.
You can specify multiple parameters
and you can really run
change the behavior of the same test case.
So that is the support,
the test run configuration in a
Yammer file that can be
predefined,
can be very usable.
And it can be also
used to map to external test
infrastructure.
So in,
in fact,
we have two kind of mapping
as you saw before.
There are
more items that are
directly mapped to the reference document.
And that is the first point
is a direct mapping.
For those,
we define not the mapping
in terms of section and offset
to the reference document
that is translated
later in a byte range in
SPDX.
And any relationship
is also provide
an information about
the completeness percentage.
So you can specify
if a work item is enough
itself to map
that part of your specification.
Because the goal of this tool
at the end is to clarify gaps
and that can
is done in two ways.
With these variables
and with the section
that doesn't have any mapping.
So if you have a public instance of this tool
so for any new contributors
should be quite easy to understand
the opportunity to collaborate
and in case of indirect mapping.
So if you have a nest
at work item,
we are calculating
the completeness percentage
in a waterfall
in a waterfall way.
So there is another section
around a broken mapping
because you know,
anything in software development
is in continuous evolution.
So our software specification
is going to change.
Now we can have some broken mapping
about the tool itself
can help you automatically fix those things.
Another thing that I wanted to share
about it is about the version control.
So this tool
helps you to keep track of any changes
on the work item
and on the mapping that you are defining.
So you will see
each component about
the version that is a combination of two numbers.
The first one refer to the information
of the work item,
the second one refer to the information
that we have into the relationship.
So if the completeness change
or the section the mapping change,
you will see a change in the second number.
And you can navigate the history
and that can be also exported as part of the
SPDXS bomb.
Other few key points
before moving into the
core of the topic.
So this tool comes with
web user interface
and with an HTTP
API.
So each section that you perform on the web user interface
can be done
automatically workflow
with the RSTPI.
It comes with a container file
you can deploy it just running
a batch file
thanks to last collaboration
that we had with a new project
last weeks.
And it is also a
multiple mapping view
so you can have multiple teams working in parallel
on different topics.
So someone can work on requirements,
someone work on test specification,
someone can implement test cases
and stuff like that.
OK.
So I'm moving to the core of the topic.
Let's see,
the important of having the accessibility
in safety critical application.
So that is just the definition
from Wikipedia.
Anyone, I'm sure that anyone
know the benefit of having accessibility
just let me remark few things.
What is a safety critical system
essentially is a system
whose failure or malfunction may result
in one of those
outcomes like that
or serious injury of people
loss of several damage
to a keep-minded property
and environmental harm.
So we are dealing with that kind of
application.
And all the standards
around those applications.
No, I mentioned just few
for automotive,
aeronautics.
There are many.
Anyone is requiring
accessibility.
And can be used
to establish and demonstrate
control over the process
and to simplify the impact analysis.
So you know which requirement
is affected by some problem
that can also go back to the source code
and understand where the problem is
what can happen.
And it was a bit,
you can also help you
while I had to get upset
and to estimate an important
because you should know
what remains to be done.
And that's the
my personal representation of the
V model.
So let's see
which artifacts.
So a bit quick overview of
the software development
lifecycle, then we will see
which artifacts we usually create
and how we can trace those artifacts.
So we have a verification branch
and a validation branch.
And the life of the project
is in the horizontal line.
So we start from a project
requirement definition
and the project should be
for the market at the end of
acceptance testing.
That is the ideal workflow.
And so that is the design phase
when we specify project requirements
that then can be explored in
the system requirements.
The architectural design
is generating other kind of requirements
to the software requirements.
That are usually also
in the low-level requirements.
And from that time we can start
building and design of our test cases.
And then there is the verification
the verification phase
on the right side of the branch.
Now where we have unit testing
that are related to the
software model design
and continuing to accept
testing.
So let's see the artifacts
that we can generate.
So in that phase we can generate
a sense of requirement.
And here we have
source code and test cases.
And in the middle we have
test specification,
we generate test specification.
And in the test phase we generate
test reports,
bugs,
change requests,
bug fixes,
like metric request,
so piece of code.
That is a possible
possibility that we can put
in place with those work items.
So we can have
requirements that are generated
by the top-level work items.
And that can be
not ever but can be refer to the
source code.
Then we have test specification
that refer to the requirements.
And test cases that refer to
test specification.
Test reports that
links to the test cases
and bug change requests
fixes that link back to the test reports
but can also link to the source code
and to build version.
So that is a possible
possibility with the view model.
Let's see what we can put in place
with using this tool.
So essentially if we use a project
that is an example for
using a project requirements.
But we can do the same
analysis for using
another kind of requirement.
So if we use a project requirement
as a reference document,
we can trace to that system requirements.
So it's a software architecture
requirements and
low-level requirements.
And we can define
also the possibility of test specification.
So that is the design phase.
So everything that comes in the design phase
can be covered by
the traceability that this tool
is able to provide.
That's why we are interested in
specific create
a design as bomb.
And we can also link
other kind of documents
to our reference document
to our specification and
justifications.
But as I said before,
this tool comes with a
test infrastructure.
So you can also link
test cases.
So you can link
test cases to test specification.
And test reports to test cases.
So you can run the test from
within Basile.
And your report inside the tool.
So the bomb that we are generating
is around all those work items.
So let's see.
How we are exporting those
those work items in SPDX
model tree.
So essentially we have a library
and software component that is
the API is like a file
inside the DS bomb in SPDX.
And it's connected to the reference document
with this described relationship.
And each snippet of the reference document
is related to the reference document
to the relationship contains.
So that is the default BI,
or not.
So as an open source tool,
anyone can change it
based on their needs.
And then we have software requirements
that can be nested.
So we have the first
the top level one that is connected
to the snippet of the reference document
with a requirement for relationship.
And each one comes with a complete
and special stage that in SPDX is
a kind of Boolean at the moment.
Information where you have a
special stage,
because it's a better way to describe gaps
and clarify,
clarify contribution opportunities.
But let's see.
And then we can have nested
level of software requirements
that can be related to the parent one
with the generates relationship type.
We have also export test specification
and those are trace
of using the test relationship
that can be referred to requirements
or to a snippet of the specification.
And we have test cases.
So there is a test case relationship
that we are using to connect test cases
to test specification or requirements
or directly to this snippet.
So there are projects for the one
is not mandatory to create requirements
or not required to trace test specifications.
So these two are
help you to specify
the workflow that better fit your projects.
And then we have
justification and documents that are
described by the in the SDBOM
with the describes for justification.
Relationship and document can be used
or can select any relationship
from the SDX model 3 definitions.
And also comes with a percentage of
completeness.
Yeah.
Thank you.
And then we have test run that are connected
with evidence for two attes case.
Let me two words around how we are exporting
actually the data.
So essentially we have each work item
which has its own custom information.
So we are exporting the data
in the attribution text information
that has pdx model 3 is providing
at least in the.
And we are collecting.
We are creating a stringified version of
the of the row of our table inside this field.
So anyone can consume all the information
of the work items.
Because some information
overlap with the standard information of
spdx.
So we found useful to have the information
nested that way.
So that I'm open to any input
because that's an open question for me
to have best able to communicate with
other tool that actually are exporting
in spdx.
So let's see how it looks like.
You have your, this is the web page of the application.
You have a software component inside the library.
And you just connect click the exposed to
spdx link and you have your JSON file
in the web page.
And we also support the input.
We start with software requirements to have
a proof of concept to understand
how to extend that later to other work items.
But yeah, actually,
there are some challenges.
How to understand which kind of work items we have
because everyone is specified as a file.
So we are using summary to specify the type.
And we read as we are exporting,
we read from the attribution text,
all the information.
So user can upload that JSON file
and see the list of requirements.
Select the one that's one two important.
Just can import from spdx.
JSON requirement inside the tool.
Two words around test infrastructure
that can be of some interest.
This application comes with a test infrastructure
that allows people to run any kind of test
suite of written in any language.
Again, it's a different kind of test environment.
It can be container virtual machine and physical
order.
How we solve that problem because
that read that we have a project that is
named the TMT test management tool.
That solve both those questions.
Essentially, it is using a YAML file
to create an abstraction of test cases and test plan.
And with that level of abstraction,
we can run any kind of test suite
so that problem is solved.
But this tool also provide a provision system
that can provision container.
The default for basil is a federal container.
So when you spin up an instance of basil,
you can immediately run test on a federal container.
That is the trend automatically in the tool.
But you can also connect the vssh to virtual machine
and to better machine.
TMT is using another project that is FMF
that is the acronym of flexible metadata file.
That is another interesting thing that can help
you to combine together multiple configuration files.
The leveraging hierarchy.
So you can have files inside folder
and you can inherit the configuration from the other files.
So that can be of some interest.
In the last version,
we are enabled the possibility to extend our test suite.
We can trigger the execution or just navigate the result.
TMT is the embedded test infrastructure.
We can also trigger and trace test on GitLab CI GitHub action.
And we can trace existing test run in the CANA CI.
And we can trigger test in the testing format
that is another project from red dot,
that is testing system as a service.
So you can request testing format to have a token
and trigger your test on a data infrastructure.
And that is a quick bit through the map of what we plan to do.
So how we want to extend our work
in terms of SPDX and around this tool.
So if you have any questions,
we are on time.
I have tried to go.
Any questions for us?
Please go.
And I can see where you are trying to do,
which is a lot of it,
a lot of it is about traceability.
So is this,
if I have existing tool,
commercial tool, probably,
with requirements placed,
how easy to be able to transform it
into this place to use battle,
so I can then get traceability doing that.
Safety system is a long time,
so you recognize.
Yeah.
So how can I have enough for SPDX?
Yeah.
Thanks for the rest.
So the question was,
how we can migrate from a vendor tool to basil?
So the thing is that a basil comes with an HTTP API.
So you can create a simple,
if you have,
you can export your data from your vendor tool,
be something or be something.
So I have a 10 years experience in automobiles.
So probably we used the same tools in the past.
Yeah.
I mean, you can export an Excel file,
whatever the format you can export.
And then you can leverage the HTTP API
to inject all your data inside the tool
with a Python script.
I had that demo for the fire project,
where they have already software requirements in file.
And with one under the code line of the Python,
you can replicate the same structure.
They also have multiple level of requirements.
So I was able to be this code line to have the same
traceability in embedded.
There is another use case where you can have
your requirements in file in your GitHub.
There are projects that are working that way.
And you can still use the tool,
now mapping to those files.
And you will be notified on any changes of the file.
So you can reflect automatically the changes in your requirements in embedded.
So that's one way to work.
Thank you very much, ladies.
Thank you.