Hello and welcome to our
dSPACE Innovation Coffee Break. My name is Fabian Bronner, and today I would like to show you
our adaptive AUTOSAR virtual ECUs and how they can help you to simulate
and validate your adaptive applications. So, I would like to start with giving a sketch
outlining the road from software development to integration of the software
in the vehicle. I would start the sketch with a software
development where our software developers implement the adaptive applications. In par
allel, most likely, another company
will develop the ECU hardware and then we will bring together
our software and the hardware and create the ECU, the adaptive ECU,
for the vehicle. So we can integrate
this ECU in the vehicle and we could do some test drives at this
level to collect some test data. However, you might not want to
start testing at this level. You want to do it earlier,
maybe without the vehicle and here we have hardware-in-the-loop
testing, which basically can be labeled as
testing without the vehicle. So we connect our ECU to a HIL simulator and
produce some test data from there. We can move testing even further
to the left of this sketch or earlier in our development chain
and have software-in-the-loop testing, which kind of translates to
testing without the hardware or more precisely
without the ECU hardware. So, at this level, we create
the virtual ECUs and we connect them to
an offline simulator. So, we can simulate the virtual
ECU on our development mac
hine and produce test data from there. This is beneficial when you do not
have the ECU hardware available or if you want to save time and money
and virtualize this testing and you can scale it up, for example,
for continuous integration, where you might want to have a lot
of simulations running in parallel. So, how can we create these
adaptive virtual ECUs? Let's take a closer look. So, to better understand the idea of our
adaptive AUTOSAR virtual ECU, let's bring a picture of a real
adapt
ive AUTOSAR ECU next to it. Here we see different layers. First, the application layer with one or
multiple adaptive applications. Then we have the adaptive stack
also referred to as our middleware. And then we have a POSIX based operating
system, typically a Linux kernel. And now we want to bring different layers
to the virtual ECU. The first layer is the application layer. We bring all the adaptive applications
to the virtual ECU. And we do the same for the middleware layer. We also bring t
he middleware
to the virtual ECU. However, now for the operating system,
we have our own simulation Linux kernel, which comes from dSPACE and has some patches
that can be quite beneficial. We will see and learn more about this
in a minute. If you have specific adjustments
for your Linux kernel, we could also bring these adjustments
to the virtual ECU and then create some kind of a custom simulation Linux
kernel that has your patches and ours. And, well, this just mentioning, again,
is an op
tional step. You could do, you could just use our
simulation Linux kernel. All right, so now we want to simulate
this virtual ECU on our computer. How can we do that? Well, we have the virtual ECU
and we make use of a hypervisor so we can boot the virtual ECU
as a virtual machine on our simulation computer. And this will give you a performance increase
because now we can really use a hypervisor instead of an emulation here. You do not have to worry about creating
and managing this virtual ma
chines. Our tool VEOS will handle this for you. Now, to make the simulation system more
complex or even more meaningful, we can add further virtual ECUs, further adaptive,
classic or even non AUTOSAR virtual ECUs. And on the other side,
we can also add environment or sensor models
and the restbussimulation so that we have
everything connected. For this purpose VEOS will simulate
a virtual Ethernet bus. And VEOS is also the time keeper
of your simulation, which means VEOS will keep all the
simulation components synchronoss, so that you, for example,
can have reproducible simulations. And VEOS can also change
the simulation speed, so you could also run your simulations
faster than real time. All right, now I want to
give you a short demo so that you can see how to create
and use an adaptive virtual ECU. For this purpose, we
need a demo scenario. I chose kind of a generic scenario here where
we have a sensor, controller, and actuator, kind of a typical component chain. And the
sensor will be a rain sensor
outlined by a software component that just produces an
artificial rain intensity. Our wiper controller asks
for the rain intensity and decides whether
to trigger a wiper. So, we have kind of a rain
controlled wiper in this case. All right, so the first tool
that we use is SystemDesk and here we use the virtual ECU
manager to create virtual ECUs. And for the adaptive virtual ECU,
we combine different archives that together form the
Linux root file system. So,
the first archive is from the middleware
provider, the middleware layer, and then we have the three
adaptive applications. So, here we have the rain sensor,
the controller and this dummy actuator to just log whenever it receives
wipe movement comment. Now, I changed too, hand over to VEOS,
the VEOS player and I already imported our adaptive virtual ECU here and
it will be the only component for the simulation scenario. So, I can start the simulation,
I see that the simulation time is incre
asing here at the bottom. And to better understand what's actually
happening in the simulation. I can open this out fire here. And this will give us an insight to the
console output from the adaptive virtual ECU. So when I pause the simulation. I can see in this console here different messages,
for example, from our rain application, and it generates this rain intensity. Can now resume the simulation. And bring the VEOS player here to the
front and I can change the simulation speed, for example
, to ten times real time. So, not I see that the simulation
time is increasing faster and that log messages are
coming in more frequently. Now, I might also want to get more
insight into this simulation, and for this, VEOS is storing this
output file on my simulation computer. So, I just wrote a script that plots the
different values from the applications. So, let me start the script. And here I can see the different values:
the rain intensity, the decision from the controller,
whether to tur
n on or off the wiper and then this trigger value whenever
the wiper performs the movement. So, we just saw our adaptive AUTOSAR
virtual ECU and we used two tools for this, SystemDesk to create the virtual ECU
and VEOS to simulate it. There are more tools in the dSPACE world, for example, TargetLink to develop
adaptive applications and ControlDesk to get a more
comprehensive access to your virtual ECUs. So, let's go to the conclusion of this
innovation coffee break. So, we learned that there
are tools from the
dSPACE to create and simulate virtual ECUs. When you want to do this, you need your
adaptive applications and your middleware image for the x86 architecture, and then you
have your adaptive AUTOSAR virtual ECUs. They are realistic because you also
have your middleware image there. We have high performance simulations
as we use hypervisor and no emulation. We have reproducible simulations
as we have a time synchronous components within the simulation. We can also have synch
ronized debugging
when we make use of a debugger for an adaptive application. We can have complex simulation systems
with further virtual ECUs, classic and non-AUTOSAR virtual ECUs,
an environment model and so on. We have easy to configure simulation
scenarios where we can easily exchange single adaptive applications and we can scale this up
by using container's, which is especially interesting
when it comes to continuous integration. So, thank you very much for listening. I hope you learn
ed something new about
our adaptive AUTOSAR virtual ECUs. If this sounds interesting to you,
please feel free to get in touch with us and we can have a more in-depth discussion. Right. So thanks again and bye bye.
Comments