Okay. There's next talk. Please be silent.
Okay. This will get an interesting thing. Normally I'm used to move my arms a lot while
I'm talking, so I try to get the microphone always close to my body now. I will give you
some information about the ELISA project. ELISA stands for Enabling Linux and Safety
Applications. And maybe a quick question up front. Who is aware of safety critical software?
So shortly raise the hand. Hi. That's good. Maybe 25, 30%. I hope you will also learn
something new then. So maybe before we start fully, I just give you a short view on which
project context I'm working. So as you can see, my project is mainly focusing on embedded
IoT Linux at Bosch. And what you try to do is utilizing a lot of open source projects,
see how they fit into a landscape, and can be of value for very, very different device
classes because normally you don't believe it, but in all of these kind of products you
will find Linux in there or also embedded real-time OS and so on. So that's all about
this part, shortly about myself. Who am I? I'm a technical business development manager.
I'm focusing on embedded open source, mainly doing this for the Bosch. And in parallel,
that's also why I'm speaking here. I'm the technical steering committee chair and working
group lead for the Linux foundation. I bring a past history of 15 years plus. I guess I
started with Ubuntu 6.10 more or less to set it up on old PCs, sharing it to exchange students
so like a distributed hub of PCs. And here since 10 years, I'm more or less in the automotive
space with Linux. We had our first product with 2.6 kernel out. And I guess now we can
start on the real things. So if we talk about Linux in safety critical systems, we first
need to get an understanding what the system really means. And a critical system, maybe
first you say assessing whether the system is safe requires understanding sufficiently.
And you can see here's nothing about Linux in there because the system always goes beyond
the scope of a pure operating system, beyond maybe a single component. And in this one,
you have a system context in which Linux plays a role. And you need to understand the system
context and how this is used. Because if you don't get the understanding how Linux operates,
you cannot see in which components you're interested. And which features you may need
or which not. And then you can evaluate what kind of these features are really relevant
for safety. And while you're doing so, you're most likely identify gaps that exist and you
will definitely need more and more work to get this done. So if you look into the Linux
ecosystem, which we have already, there's a good chance or a good reason also to take
Linux because there is a large variety of devices. The ecosystem is strong. You have
good tools around this. An incredible amount of hardware support. It runs on many, many
devices. And also very important, you have a broad set of experts in there. If you see
what's sometimes taking as the benefit of a certified safety critical OS, often it comes
with hard real-time requirements and capabilities. We know that the preempt or t-patches are
in good shape in the kernel. But, well, hard real-time maybe goes even further down the
road. And then there is a development process. And if you see these two sites, if you come
and want to address very complex products like in the automotive field or maybe you
can even call your robot vacuum cleaner a more complex product. And then you come from
two perspectives. On the one side, you could go with a traditional small component-driven
artist and you have to handle all the complexity. So you need to have more hardware involved.
You have more multi-core support. Suddenly, not everything works out there. Or you go
the other way around and you come with a Linux where you all have these kind of things, but
you need to improve and see what do we do about the development process? What do you
do about the real-time capabilities and so on? So anyway, when you build a more complex
product, you need to find a way to tackle these kind of challenges and also bring the
difference closer to each other. While we were looking at Linux, I'll take the part
in the beginning. It's a little bit like a disclaimer and a little bit more text. In
this collaboration of Elisa, we said we cannot engineer your system to be safe. We're talking
about functional safety, not about cybersecurity. But if we just take this example, there's
always a strong risk also that you have security breaches in your system. So it's similar
here also with safety. If you build a system, it's still your responsibility for it. And
just because we provide certain guidelines or engineering principles and so on, it's
still in your responsibility as someone producing a product to make things safe. And also that
way to make sure you really have the described processes in use, use the methodologies and
one of the core questions which typically come is like, oh, so you're from Elisa, you
make a safe Linux, will you certify a kernel version? And that's not what will work because
we all know you have to move forward. There's continuous improvement, there's sink and there
vulnerabilities fixed, so you need to go on. And this gives an additional challenge with
the continuous certification. So we will definitely not have a version and we will also not certify
Linux in this project. We just give the tools and other elements in there. So here, last
part of it, there's still responsibility, legal applications, liability and so on, which
is also near all. Nevertheless, we find a good set of partners already, which are willing
to support this mission. And they subscribe and say we would like to bring the whole
thing forward. And seeing this, there is the mission statement which we have drawn. It's
lengthy basically. You can read that there's set of elements, processes, tools. It should
be amenable to safety certification. We look into software and documentation development
and in the end that we aid the development, deployment, operation, or the adoption of
a project into another project. Okay. So if you look at this mission, you see basically
four key parts, which we will also talk later about. You have elements and software, which
is concrete implementation of what we're doing. And you also have the processes. A development
process always falls into safety critical, into security system, wherever you look at.
And if you start to automate things, if you would like to analyze, there's always a strong
involvement of tools in there. And the last thing is when you do all this kind of work,
you need to document it. And actually, there's a lot of documentation work needed in any
place. So how will we do all this kind of things? We take it in our ELISA working groups.
We split this depending on different topics, on different contexts. They're growing depending
on demands of certain sizes reached. We're extending this. And if we take a first look,
we have a safety architecture work group. This is a group which actively looks inside
the kernel and takes, for example, a watchdog subsystem because watchdog is one of the crucial
elements which we have in use. It looks what are potential safety related functionality.
Is there something in the kernel which is non-safety related? How would these kind of
things interfere? And by this, the safety architecture work group does a lot of analysis,
try to improve documentation in the kernel, provide new tools. So that's a strong set
in there, basically driven by use cases and demands of products. And a little more broader
approach is brought in by the Linux features. And actually, the full name is Linux features
for safety critical systems. So it's not about generic features. It's about the safety
criticality part in there. You can imagine this a little bit like if you're familiar
with security measures like namespaces or other parts that we're looking for elements
in here which could improve safety. So which means if you take this special kernel configuration,
a feature, turn it off on whatever you do and say, okay, this will come up as a blueprint.
This is something how you better work with memory, how you not work with memory. All
these kind of things are tackled in the Linux features. And then it's a nice group because
with the results which are in there, if you're already in a process of enhancing Linux and
don't want to wait for all the results of the use cases work group and so on, you can
have incremental steps here, just take some part of it and make your system more robust,
more dependable. And you can also judge it against how does it compare to securities
things which you're doing. And so here that's the big value of this group. It's more on
a direct use base and serving a long term safety argumentation, but not that it's something
which develops for years. So it's basically assess what's there. As also the improvement
of code quality is very important. We have tools investigation code improvement work
group. The code improvements could be, for example, done with doing fuzzy testing on
the kernel using tools like code checker or syscaller. And then bring them also into a
setup where we have server kind of a CI which runs on Linux next or whatever kernel configuration
to identify issues to get the kernel more robust, more dependable, reliable and serve
also in the argumentation about the quality of the kernel. And what was also on the right
side and some of the challenges part was on the engineering process. And as you know,
there are rigorous methods within the kernel development. So there are a lot of reviews.
Patches are rejected and you see that there's strong demand from traditional project management
when it comes to safety products and not every process complies with it directly. So we need
to find an argumentation. How is there an equivalence to the open source development
process compared to what, for example, ISO 26262 requests for automotive products?
On top what is very interesting to understand here is also that if we look into open source,
you basically cannot easily buy a maintainer or developer there. So you cannot buy features
directly or so you get more an unbiased view or maybe a personal view, but a maintainer
who is really committed for the component for this power subsystem of the kernel and
so on. And with this strong commitment, for example, you already fulfill a little bit
of independent view because in safety systems, whenever it comes later on, the developer
needs to commit to what has been done. But of course, it's not written down. It's not
written down. The maintainer fully commits to whatever it does. So this is some part,
for example, where you can start argumenting on it. And as the different elements need
to get somewhere and need to be visible, we figured this out because we were running
quite in parallel with different streams on this, but never brought this forward. We came
up with the systems workgroup and the system workgroup actually should take all these different
elements, bring them together, works cross-functional and maybe even cross-project and combine the
elements. In order to tailor the system properly, we have vertical use cases, a newly created
one, so there's not much information in this presentation about the aerospace workgroup
yet. The overall idea is it should address everything which flies and you know that in
aerospace there are many safety standards, safety integrity standards, various levels
in there. What you may not know and that's at least what we have heard so far was there
is already Linux in use and also in certified product there's Linux use, but it's only
on a very low safety level, so it's not on a very higher upper level of safety certification.
What's an obvious thing if you see the member there is like 50 to 60 percent is from the
field of automotive and therefore we have an automotive use case in there. If you drive
a car, if you have a scooter or whatever, you may see sometimes that there's an oil
pressure sign, oil temperature sign, check engine, whatever, basically when you put on
the ignition you can see all these little LEDs and this is also the use case which we
are using in the automotive workgroup. Basically what we said digital or cluster, instrument
cluster, the speedometer, everything becomes digital, everyone has a display in your cars
and that gives a good chance because there are more complex system in there, a lot of
rendering, graphics rendering involved and this is actually a safety critical function.
Even if you are in driving or in rear gear mode this has to be properly displayed and
it has a safety criticality assigned. Also showing the check engine part is a safety
criticality. The third group which we have is from the medical devices and here this
is something from a completely different perspective while automotive has the commercial
element in mind, maybe one to have cost savings, driving topics forward with the open APS,
APS artificial pancreas system. It's driven by open source so there were open standards,
there were chances to interact with your insulin pump and you see that this can become very
uncomfortable. So there's a nice TED talk from Dan M. Lewis, I recommend this, I put
the link also in the slide deck, you can download them and check it. You can see that you basically
need to track your glucose level and certain dose of your insulin depending on your glucose
level and this is also with warnings and so on and it's very basically event triggered
so you see the blood pressure, sugar level goes up so you set the dose, it has a certain
delay until it reacts and what came in here was to add the raspberry pi in the middle
writing some scripting around it, getting it stabilized and create a product out of
it and why I want to stress this is not to any IEC ISO certification done, it was done
by an open source engineer, started this project and if you download this, if you use it, you
use it on your own risk and therefore the work of Elisa was basically also the first
use case we put directly in the beginning of the workshop to say let's take a deeper
look, let's analyze what's in there, it's running for thousands of people, it has never
been certified, they are very happy and they see it's increasing quality of their life
but it's not certified, it's a safety critical product not certified and we are not targeting
to do the direct certification of it in the first that we are looking into the different
levels of the analysis, see what is involved, what workloads are in there, is there something
which could make this fail, is there a risk in there, what potentially could go wrong?
And this is basically the completion of the use cases and I've drawn this basically together
as you can see an inner part which is very common for almost all the different projects
which get fed by the use cases, feeding and say this is how you need to configure, how
you need to specialize because you cannot create a full safety critical item completely
out of a context, you cannot have this generic safety argumentation, you always need to judge
it towards assumed context and this then turns into these are deliverables.
A little bit on another view here, you can see also an exemplary system architecture
mainly how we triggered it in the systems work group, it's not only Linux involved in
these latest products, so if you come and you, of course in the medical devices open
APS system, it's a pure aspirin on it, there is not the direct artist involved if you don't
treat the sensor or the insulin pump as the artist next to it, but if you come to more
complex products, you always need to face that there are artists involved, there are
microcontroller, micro processes, container technology come into picture, everybody talks
about containers and embedded these days, and also virtualization technologies that
be Xen or that be KVM, so this is something which gets in there easily, and for this part
if you see on the working group side this Linux features architecture code improvement,
this directly go into the Linux work, so the main outcome of this is for the Linux ecosystem,
the Linux kernel, and a lot of this work is also not directly related to the hypervisor
or the artist, but there are things also which going a little bit further, like the tools
and the engineering process, things which are coming out there may also have a good
value for other projects which you build on, so if you have a Yocto involved in there,
you can build Xen and Zafaya also with a meta layer, and then it may be good to have this
tooling part in there, or also code improvements can come into picture there, certain tools
which we make use of in UCI for testing, OpenQA system or others, this is an element
to be considered here, and lastly the use cases for the completeness, they basically
tailor down this system to whatever you need, so for example in the automotive work group
we for now tailor the system down for getting a better Linux kernel understanding, and we
get rid of the endear originally from the container, the virtualization the others,
but we know once we have solved some parts of our work, we need to get the system context
and the system context involve all these kind of things, right, and saying this, we also
do a certain outreach to other projects, so I put in the Zafaya community, we have the
automotive group Linux which is already in there, there could be other Linux versions,
and also strong involvement of the Yocto project, instead I didn't know where to put the SPDX
so probably on this picture where we see it later on.
How we interact so far, we already are in discussions with Zafaya and Xan, we have weekly
meetings also where Xan members pop up, where Zafaya is present with some representative,
and we saw that these are safety critical open source projects, so they basically share
the same burden, they need to show how the development process is done, how do we guarantee
certain quality levels, so where is the testing done, where are the requirements, management
and the traceability to everything, so this is something which pops in there quite good.
If we take this architecture and as I'm coming from the automotive part, we have different
projects which share these architectural sorts, and there is a large group on the Eclipse
STV project, there is a SOFI initiative from ARM, basically having similar members like
the STV and then we have a large automotive grade Linux, which also is so nice to provide
us with the reference implementation for the automotive use case, so they share very similar
architectures.
Lastly, not directly related to safety, but having safety considerations in there and
being part of the system is the Yocto project for some build tooling part, to get this into
a CI reproducible, here for example the air bomb generation suddenly plays into the game,
which you can do with the Yocto project, and while we were discussing we figured out that
there is also like data needed into a system as bomb, and for this we reached out to the
SPDX and there is actually a SPDX special interest group on FUSA meeting weekly to extend
this scope, I guess there is also later on talk where parts of it get presented.
Why do we do all this, I like this statement from George Bernard Shaw, he said if I have
an apple and you have an apple, if we exchange the apple we have still one apple, but if
I have an idea and you have an idea and we exchange these ideas and we have two ideas
and that's basically where it goes about, we need to get a good understanding, we need
to bring the things together, and by this we of course need to look into certain activities,
so now we come into the part what the different work groups do, and if we check for example
the elements, process, tools, documentation, not every work group acts in the same amount
as the others do, so just put some bubbles in here to see where are mainly our work
is going, so we have a lot of things of course on the software part, the people are interested
in the Linux kernel, and the process part is maybe not so strong because it needs to
be centralized and the usage of this process goes into the other work groups, so the OSAP,
the medical part, architecture a little bit also, they work on these kind of processes
and bring this into the other work groups, tools seem to pop out on multiple work groups
because tools are handy, tools pop up, we bring it into the, into repo, you tell about
it, get it used, and if we want to go into continuous certification at some point of
time there will be a need of having a lot of tool support in there, and basically every
work group does documentation, I want to give you some examples on this from the process
perspective, there is a system theoretic process analysis, that the first topic I will tell
a little bit more about, so it's the dry stuff about the systems architecture, it's not
the code level on this, but we figured out when you do this kind of STPA analysis at
some point of time you reach also a level where you need to understand more about the
kernel, so I'll tell you something a little bit about the workload tracing which we have
done, and also here supporting from the another work group, we have a call tree tool that's
self, not in beta, utilizing tools and the proving thing, but writing something also
from scratch, and this all then later on fits into the meta Eliza, which is basically the
Yocto layer for the automotive use case enhancing the automotive grade Linux demo, we also did
something without modification like the code checker implementations to Scala, I will not
tell that much about it, but just to give some examples for work on, and all our information
is public, so we have quite spread it up, there's a GitHub part, there's some parts
on G Drive, we do regular blog posts, and have some white papers published, so it always
depends on whom do you want to have as audience or readers, so we share this, there's also
YouTube channel, but I don't judge this as documentation, okay.
As at first, we're looking to STPA, so STPA stands for System Theoretic Process Analysis,
what's interesting to see is if you're coming from safety criticality, maybe automotive,
you know, hazard analysis, risk assessment, FMEAs, you may grow with watch, spreadsheets,
drawing cases, checking your API interface and all these kind of things, and the nice
thing about the STPA is you go a little more in a graphical approach, like on the left
part of the picture.
Some basics here, it's still relatively new, I say this because the old analysis part
come from microcontroller worlds up down to the 60s, 70s, I guess 70s is more or less,
so there was a long time where a lot of these analysis techniques came in and they haven't
been much improved, but the systems which have been analyzed have increased complexity,
and this is something which needs to be considered, and this System Theoretic Process Analysis
STPA is able to handle very complex systems.
The reason for this is that you can't start from a quite broad view, and maybe you don't
know all the elements, so you have something, you just get a name for it, you don't know
how it really looks like, and you have another blob where you have more details, so you can
connect all these different blocks, and these analysis will still survive even if you know
not the old block of some specific part yet, and then you will go in a very iterative approach
and just go there step by step, you figure something out, you go to one level down, going
deeper into the system, figure out that your assumption didn't hold true, so you do these
kind of things for the analysis, and what's also good, if you have certain analysis, it
basically looks on an API level, it looks under definitions or so, but this one explicitly
goes on the system context, and it includes human interaction, the human operation, and
this is also what's not there for other parts.
In parallel, you directly get a good, while you do the analysis, you already improve your
documentation, you get a good standing of the system, and you can even if you are in
a QA department, so you can even integrate it properly with existing systems model-based
approaches.
The principles of it, to get the very, very high level, it's quite easy.
There are four key elements, there's the controller on top, this one sends a control action to
a controlled process, and this provides typically feedback.
Well, that's not enough, in the end there's also important to know that the controlled
process as such may also control something else, so that's how things get more grown
up, and the question now in the end is, what could go wrong, what are unsafe control actions?
You can use these methodology for maybe understanding how your water pipes flow in a building, or
how people walk through certain, so you can always attach it to whatever use case you
like, it's always the same approach, but for our case, and the main idea of it was for
safety, criticality, for risk assessments, and that's why we say, let's look under unsafe
control action.
A little bit of warning, and the next slide is in a way that you will not read, it's
level one analysis of this open APS use case, and well, yeah, that's how it looks like,
in the middle there's the open APS system, you have a view from a top level, so it's
a developer view, it's not the full user view here, so you have infrastructure, people
have algorithm developer, you release the software, then they come to the human operator
who uses the software, installs it further on, this goes in the system, we don't know
yet what the system is, this is what I meant with the very first level, you don't care
if it's the Linux system or whatever it's underneath, so this is my open APS system,
and when you have understood what is your critical part in there, how the system context
looks like, you may go into the next level, and now we zoom in into this open APS system,
and go on the next level, and in this you see there is actually a Raspberry Pi involved,
we know this from the hardware part, and the OS in there, so it's a Raspbian, you have
an open APS toolkit involved, the actual algorithm, this may control the insulin pump, the night
scout part is also an external component, you see all these kind of things, and the
work group has been on this level for some time, and then try to write down the next
level going deeper, and then actually needed support, so that's where workload tracing
came into picture, we used the mentorship project here and had support, so someone fully
concentrating on the activity of workload tracing, that's another little table which
you can at least read, therefore the main things to be known as, we use S-trace and
C-scope as the main tools for the analysis, there are stressors in there, like Stress
and G, Pax test and other parts, this may depend on your workload which you use, what
you would challenge with the system, and in this one the information which is coming in
there, now our system calls, how often are these system calls coming in the frequency
of it, which subsystem do they belong to, that you know okay, where is my critical parts,
where is the system call entry point, and by this you can more deep dive into the different
system, and this causes a lot of refinement into the upper layers, again because now you
have iteration and see maybe you have a wrong assumption, but still before everything was
correct as you understood, no you just improve it, related to this calls of the call tree
tool, that's something basically rewritten and own part, so the idea was to see here
is a system call, what else, of course what are the ways, how to interact there, how to
visualize things, because if you just see something and go through the code you cannot
really grab the complexity, and this was just the first shot, so also here it's not worse
to read, but you can see there's a file system part, and the very interesting part is, this
is quite a static thing, so you will see all the potential options, while in the previous
view if you have a call, if you have the workload tracing, you basically see where has the pass
gone, but you don't directly uncover the untraced passes, and here you see all the passes,
but you have the chance that you meet something completely irrelevant, because you're not
on this with your workload, and this is a complimenting element of this, and well you
get a good insights on the kernel construction, and it can help you to analyze more workload
in there, right, we bring all these things together in the meta-eliter instrument cluster,
it looks like the AGL instrument cluster, we saw this picture before, I highlighted the
change which we did, we write danger in there, and this made us the whole thing safe, which
well is of course not the full story, the full story is that we just needed a use case
to which we can analyze, which has safety relevance, and it was a good QT-based demo,
so we could make use of it, it was running on QAML, QAML has a little drawbacks on this,
I'll come to this very soon, but with this you can start analysis tracing workloads,
and also add a watchdog mechanism, watchdog would be the next part of it, basically what
we use in a lot of concept is an external watchdog, even if you don't see it directly
in the open APS system for example, there's still an external monitoring involved which
gives emergency data, if the Raspberry Pi would do something wrong in the wrong or the
other direction, not that it happens, but there is a monitor there which controls, which
will give a beep or so and inform the user, similar you do it in the automotive case where
you have this telltale environment and you want to have something which is traced in
your workload, so yeah, this challenge response watchdog, challenge response basically it's
not simply looking for something but it gives a little challenge to the workload while the
workload process other parts and it gets a response in there so that you know, okay,
yeah, that's really alive and it's not just replying and the demand here comes basically
that we, for a lot of use cases, cannot fully guarantee that the workload comes in the proper
time that the process doesn't hang and this release a lot of responsibility from you by
checking this with an external workload, so it's mainly looking into the safety critical
workload, I know there are ideas to say well let's put this watchdog thing and let's watch
everything in there, this typically doesn't work out, so you really concentrate on the
things and say this is safety critical and all the other parts are related to user experience,
so if you're drawing rendering engine, God's lucky and you see a lot of delay and touch
screen or whatever, that's nothing which you want to experience from a user perspective
but as long as the warning signs come in time and in proper from a safety perspective, this
is all fine, so it's good to split up here between what is the intended functionality,
what is the safety criticality of it, what do I need to monitor and what not and for
this, this is just the safety net in there, here I said this is used widely in automotive,
there are other industries basically always have your safety net somewhere around which
monitor things and what we try to do is we want to get more responsibility to Linux
and by this you can start with a lot of elements in this safety critical part and yeah, so
that's the main thing on this part and the last message is very important for me, it's
not that you consider your watchdog in this design as being there or need to be there,
you basically start creating your system that you never need to trigger the watchdog because
you don't want this, this is just your system functionality and it has to work and in best
case this gets not triggered into a safe state, for TELTA use case for example this could
mean that the screen is turned off or that you do a restart, basically you would maybe
make a black screen or so that people directly recognize the driver, oh it's not going right
here, it could be also be the warning message or what else but depending on what's your
safety process you need to make sure that this is really also triggered so their safety
criticality comes in picture again.
I prepared a one minute video but I never know how these kind of things properly work
if you do a demonstration so I just put the YouTube link on the material and if you are
brave enough or even not, I guess it's a straightforward thing, we have a good documentation
how to experience this demo because when we started with the ELISA work we saw that we
basically start building our topics from scratch, we documented everything right good as best
understanding and then someone came and said well but I'm not using Ubuntu, I'm using an
open SUSE tumbleweed and we figured we need a little bit more maybe that we have more
environments set up that people can reproduce things so we came up with a docker container
which basically gets the things packages installed which you need the right version of it to
make it easier for people then the next thing we observed was oh okay the people do a yachtable
it consumes a lot of space and a lot of compilation, maybe the cache binaries would be a good
option and so we also enabled the estate in there so that you cannot build like in the
parts which are still buildable or needed to be built in roughly 40 minutes on a poor
laptop, it basically depends on your download speed also right it's quite a amount of download
which you typically have with the yachtable, on the long one we also see if we can extend
it to other systems and maybe also Debian version of it or so but for now it's the yachtable
the last thing which we figured out there are also use cases maybe where you want to
deep dive into the system and this would be the complimenting part to this demo if you
don't want to see the video and you want to just try it out directly if you have QM
on your system installed just download the binaries directly they get built nightly
so really nightly so every night you get a new one it always goes to the latest version
of the AGL with a little bit of problems last week but it's up and running again does a
boot check does a boot check so that you can really experience it and it basically uses
the instructions which are written down in the github readmemarkdown file right yeah
this is about this some next steps the STPA is continued so we're getting into deeper
levels of it we need to see that we get the workload tracing properly reflected in the
different diagrams this was heavily driven by the medical devices where the automotive
has not used the workload tracing that much but we bring this in there the call tree also
got extended with another tool which was KS called KS enough does certain kernel static
navigation tool so to get a better analysis on better view on this there for the meter
Eliza as I was talking about QM where everybody wants to see real hardware so we also are
in the past on bringing this on an ARM based hardware for now so we have the 86 and QM
simulation and an ARM underneath is mainly driven by systems workgroup and what is very
important so far this display checking in there so we are not normally would check what
the rendering of a telltale but there's so many different kind of implementation so
that we mock a lot of things there and we want to improve this so that we have proper
display checks and also a lot of monitoring this is basically on the four topics which
we have seen additionally we work on a system as bomb we enabled the as bomb part for generating
material in the demo we want to improve kernel configuration trimmed on the size of the image
then have the RT documentation updated have more complex cluster than we're involved and
that's may need so summarizing what you have seen we talked about the challenges in the
beginning basically what the difference between the traditional safety critical artist and
the new one what this is what the collaboration can and what cannot achieve you heard about
the goals and the way of the strategy which tools we analyze or which which elements we
looked into and also then you could see how the different workgroups interacted how they
put into a system how we all reach to wider community parts I talk about the contributions
of the different workgroups which shared with the community also in form of usable use case
downloadable then you could see methodologies of our STPA workload tracing and lastly we
got a little review on what's coming next and I guess we're good from the time from
the questioning part it does anyone have a question says one above coming down you have
a question okay thanks for the interesting talk you mentioned certification as one big
problem so where can we improve things so that certification processes become more open
source friendly and open source software becomes more certification friendly so what has to
be done or can be done there yeah I guess some part from the city asking how can open source
and certification come closer to each other from both sides right and one thing could
be for example done in the documentation and improving tracing down having tools supporting
how do certain features get from the mailing list into the system if there's a test around
it so this gives a lot of confidence and trust in what it's doing from another perspective
there's not much in the safety integrity standards which allow the usage of pre-existent software
elements so for this there's also an isoparse currently which allows more usage I mean depends
on the safety standard which you're in if you're some relaxed medical standards less
requirements on this but for automotive it's very strong and prohibitive on this so I would
say doing careful work and explaining design decisions and so on making this visible and
more structured having maybe centralized bug tracking and so on this this can help a lot
from this perspective it will be good for the certification authorities and we do a lot
of clearance also yeah I guess if I heard you correctly said from supporting the assessments
and the sororities in there we also have company support where we really are in the working
groups and get from certification authorities input in the continuous work which we are
doing so they are directly working within the work groups as well yeah chin as well thank
you very much for your talk I had a just a quick question I want to get a feel for what
your opinion on on this is do you think there's space as a certification for for something
like Linux improves can you move the mic a little closer because it's for me I hear the
people louder leaving so just a little sorry yeah oh oh wow yes the difference as as as
process for certification and for validation of Linux kind of improve and and change over
time do you think there's ever going to be space for for Linux to be used in in kind
of a critical component on vehicles or do you think that space is completely reserved
for for something that's actually using real time the main part which I heard was if there's
I got the real time part in the end yeah like do you think there is it's already there fair
thank you okay it wasn't there does anyone else have a question you have a question yeah
so what is the place for Linux itself in let's say what's the safety and integrates
a level of Linux itself in this model because if we take let's say ISO 26262 there's a v-model
requirements for development this but Linux already has source code there are no you know
there is no coverage this test with all these mcdc coverage etc etc so what's the place of
Linux and how to keep it maintain it without forking yeah so you say where's the space
in the place of Linux if you see the v-model for example the ISO 26262 where does things
fit in there a lot of demands like car car coverage parts tracing and so on so what you
can see is that first of all speaking about a level you will not directly go to an asl
d level which puts much more requirement on the tools that's for sure so you should start
on the lower asl a b level that's also what we did we relaxed some parts also for automotive
cases let's don't start with too complex parts maybe get a real time criticality out there
because then you have to review much more parts and so the space which I see is that
you should argue equivalence for certain things that you are in close collaboration with assessors
and explain how things are done because when the ISO was originally prepared it was not
considering a complex system as Linux being in use and the large amount of pre-existing
software so from this if you are in an assessment if you are there if you can show and show
the credibility by requirements work by good concepts you may in the first and come up
which to a system which is arguable to be safe but not directly certifiable to your
ISO 262 part but this already showed you the perfect discussion room also right because
then you see well you cannot tell me this is not working but you still say it's not
certifiable and then you see also the glitch of the standard and if you reach this point
you have a lot of good support when you go with certification authorities early if you
have internal assessments and you can judge it and in the end it's also your responsibility
where you say oh I argue for an equivalence because it's not saying in this spec you have
to assess recommended highly recommended leaving you also trace for showing equivalence
to this model I'm using this and on top I'm adding this and by this you can get an argument
and of course getting feedback from your developers that the work which you're doing also into
kernel mainline and so on.
So maybe also it's possible to somehow affect how ISO 262 is developed because it's a bit
outdated in some way.
Some of the members in ELISA have people in these ISO committees that are basically taking
it back into that direction for the future revs of the standards.
We don't have visibility at least I don't because I'm not in those committees but we
do know that some of those member companies you saw up there are there and they are advocating
for things to work a little bit better in future revs.
Is there anyone else who has a question?
Okay thank you for your talk.
Thank you very much.