All right. Why can't everyone, while the last people join the room, let me ask a few questions
to get an idea of the audience that we have here. So, quick show of hands. Who of you
knows AGL Automotive Grid Linux? That's quite a lot. Awesome. Another question. Who of you
knows Cooxer? Okay, let us change that because that way, fewer hands than for the AGL. But I
think that's a good thing. Last and final question. Who's here still from the beer talk?
Like room beer? Okay, I'm glad. We actually came out of these talks. So, as you can already see
in the introduction slide, we will talk about vehicular abstraction. So, we talk about Automotive
Grid Linux and we talk about Cooxer. So, before that, maybe a bit of context. Who am I? So, I'm not
the super automotive developer doing a Canon AutoZer for the last 20 years of my career,
also due to age. But I started with really coming from the cloud. I used to keep an
E2 working on different projects in Github. And I thought, how can we actually make
application development for vehicles more fun and efficient? And one really large essential piece
here is one challenge because there are no restandardized signals. You can develop an app for
one car and it won't run on another vehicle, even maybe from the same vendor. So, what we often
see in the industry is this kind of high end-to-end complexity. So, every application is developed
for every specific model, every specific car, and we have a huge pay point for that because you
cannot port your applications there. You cannot scale, so if a developer is developing an app
for one brand, it won't work on the other brand and also maintenance is just a nightmare because
just build it for one car and then you completely forget it. So, as always in computer science,
one solution to that is abstraction. That's why we also took a lot of effort in the topic of
vehicle abstraction here. So, how can we make a world like this happen? So, where we have tons of
applications that develop against the same API, against the same data model and that work just
on different cars. While it's the same car, it's the same time. I'm talking a bit too much about
cars. We run it on different models, different brands and so on. So, basically how do we get to
the world where we ride at once and run it everywhere and to also attract third-party developers
because this is how you grow the ecosystem and also make it more attractive to develop the
unrealized synergies. So, for this abstraction, I would say we basically need two things. One is a
data model to operate on and the other thing is the APIs to interact with the data model. Coming
to the first thing, I hope, here we go. When it comes to the data model or you might also call
a taxonomy, we decided for the CoVisa Vehicle Signal Specification. So, it's done at an organization
called CoVisa, formerly known as GenoVee. Maybe that rings the bell for some. And it was basically
does. It creates a tree structure for all kinds of data that might be available in the vehicle. So,
for instance, you get the tire pressure. You follow the branch of vehicle, chassis, axle, road, one,
wheel, tire and then you get to the pressure signal. The same way you have sensor values in
here, you can also have actuator values. So, for instance, when we have a seat position, we could
just change this value of the seat position and eventually that seat in the car would move to
that position. That's the idea of this whole data model. If you want to play a bit with that,
there's also a really cool website called Digital Auto that makes nice visualization of that and
also shows some example applications how you interact with VSS. Okay, now we go to the first
piece. How about the second? And this is where Cooxa or more specific Cooxa Viara comes into
play. So, while in this case, vehicle abstraction layer, so we talk about abstraction, so the idea
is to have Cooxa running in the vehicle computer. So, some kind of computer which might run Unix or
something similar to that. And we also assume this is a place where we decub the hard from the
software in the vehicle. So, the underlying assumption is something you can see on the left. So,
we have a lot of deeply embedded layers, can, autos, are, lin, sum, IP, whatever you like or
maybe don't like, which is maybe really proprietary in some cases and also the signals and the bits
are really specific to the car. So, then people would write something that we call provider or
also feeder to translate between these really specific systems and embedded systems towards
VSS using the Cooxa API. This is where the API is coming from because we use here Cooxa. If you
like more on the abstraction side, we also can say like in the deeply embedded layers, we mostly
have data like really 1001 or the bits and we kind of need to interpret those. So, we translate
it to VSS, get some information out of that and then by combining this information in different
applications, we actually create knowledge. And here Cooxa is a nice building piece for that. So,
what is Cooxa in general? So, since we are in the open source conference, obviously it is open
source, fully licensed on the APHG 2.0 license and as I just mentioned in the previous slide,
it is some kind of digital twin based on VSS. So, it shows the current and the target value of your
vehicle. I don't want to go into the definition of digital twins but I guess you kind of get what
I am getting at here. And so, you only have the current value which is quite nice but you also
have the target value. So, coming back to our seed example, when you would change the value, the
current value as an application from a seed, this doesn't meet the seed is actually where I
wanted to have. So, I actually will set the target value and then it is up to the deeply
embedded layers, so the actual vehicle to move the position of the seed over time. So, that is
why you can change both value and hopefully at some point the current value will be the target
value because that is the whole idea. So, much about the concepts. Let's get to the code. Or
maybe I won't show code here but what it is actually written in. So, we wrote this in Rust. If
you steadily compile it, it is less than 4 megabytes, large or small depending on which word
you are coming from I guess. Like, these are the cloud words and it is small from the automotive
words, maybe large to you. And it is quite language agnostic because the interaction with
this is with it because we have a GIPC interface with some basic functions like get, set and
subscribe and also a number of client libraries using this. And with that, that is actually the
basic of Cooxing and I have to be honest with you, if you have been in this death room last
year, you would say where is the news because this has been shown there as well. So, let's get to
the news. So, what has happened in the previous year? First and foremost, it was using AGL so
Scott will talk a lot about that in the next minutes. But we also have some other news. For
instance, we now have a Cooxer Android SDK, we have a mock service and we also did some work
with later from our side. So, the Cooxer Android SDK, I mean it is kind of straightforward
because in the end of the SDK, that is now available in Maven Central and you can interact
with the data broker from an Android application. So, be it Android automotive or maybe your own
app on your smartphone. So, assuming you have some kind of Cooxer abstraction in your vehicle,
you can use a companion app for instance, which we are about to release to the F2O store. Now,
there will be a moment for the releases there. We did support request beginning of the week, but
we still wait for F2O to actually show this app in their repository. So, stay with me till Monday,
then it might be there hopefully. Another thing is a mock service because the guys in the previous
presentation had their robot here. We cannot always have a car on our lab to test the application,
but we kind of depend on the behavior of the vehicle. So, we need a way to mox this. So,
the community came up with a behavior definition. For instance, whenever the signal of a seed is
changed to a certain value, like 1000, then the current value should also change to that value.
And this is what you can basically mock or emulate with the mock service to show you just an example.
Here we have just an example I mentioned. So, whenever the driver's side position changes,
then we create an animation to move to that position or to move the current value to that
position, which makes it quite easy and flexible to test whatever you desire with your car.
And last but not least, this is just a sneak preview into the lab. So, Cooxer is part of the
larger community in the Eclipse Foundation. There's an Eclipse software defined working group,
or short Eclipse STV. And there's another distribution called Eclipse Leder, which tries to
combine some of the major pieces of the ecosystem there. And this is called Leder. And what we
managed to do is actually run the Leder-Yogtu layer on top of an HGL, so that you actually get these
pieces, like especially Cooxer, but also some other projects like Cantal, to run on the HGL stack.
And I think this is a really good opportunity to learn a bit more about HGL here.
Oh, okay. I'll take over then. All right. Thank you, Sven Eric. So, I have done a lot of stuff
around HGL, so people might recognize me. I'm Scott Murray. I've done Linux for a long time,
and I've been at Linux for a reasonably long time as well. I've been working on HGL on contract for
pretty much eight years at this point, and doing all kinds of different things for the project around
keeping the Yogtu stuff up to date, and also doing a lot of the demo and integration type of things.
So, there was maybe almost half of the people indicating that it would be what HGL was, but
I'll do a very quick run-through. So it's a collaborative open source project,
basically trying to build a base platform that you can build an automotive product on.
So it's about 10 years old. We have a vast array of members now, a lot of the major OEMs,
and tier one and two new suppliers. It's pretty much a code first sort of thing, where we are
more focused on let's build the distro and get it there for people to try and involve. A lot of
work went into that. You might have seen HGL demos for several years doing that type of stuff,
but our members were basically saying in 2020 that they weren't interested in maintaining that
because they weren't going to use it in product. They all have their own application frameworks,
or they buy an application framework, and they like to see HGL focus on lower level,
show us how to use open source more than writing new stuff. So we started out, our tech demos,
or integration demos are more like taking best of breed open source projects and showing people
an automotive. Here's how you use these things. And so this really worked out well, because we
weren't connecting. We needed something to show here's how you will do vehicle signaling, and
VSS and Cooks of Al basically were starting to come out around the same time that we needed a new
thing. So I had started playing with Cooks of Al in 2021. Our first release basically was our
spring release in 2022. And it replaced our old signal composer and our can service with basically
the original Cooks of Al server. And so since then, basically since spring 2022, we have recipes in
our layers for HGL to build the Cooks of Al server, now the data broker. And as well, we actually
have some signal customization stuff to sort of access an example of here's how you add some custom
signals. And we use their can feeder to basically sort of wire up and show here's how you put all
these pieces together. We have our own sort of like mocked up HGL virtual car can definitions.
And so that sort of acts as an example for people to use. So that was spring 2022, like I said,
and that won't go into all the nitty-gritty there. But originally, we were using the original Web
socket API, which is a standard thing with sort of companion to VSS. We actually had can working
in our demos. And so through 2022 and into 2023, we were sort of keeping up with the Cooks of Al
releases. I started, you know, some nominal updates around switching how we were doing our
signal additions and stuff. And then this past summer, our pike release, basically, I started
the process of switching over to the data broker, which is the rust based implementation. And so
I actually got interesting because we're based on Yachto Kirkstone, which is the LTS release,
which at this point is two years old. And it has older rust. So we couldn't actually build the
data broker. And so that was the thing where basically, a jail, we contributed upstream, I have
a layer that you can get for the Yachto Kirkstone like mix in basically gives you a newer rust to
be able to build the data broker, which other people I now are no are using for building other
rust projects. So that, you know, we're now starting to look at the data broker, this cop coming
release. Basically, we were now using the absolutely latest version of Cooks. And that now I fully
have us all switched over everything's data broker using gRPC, all our demos are converted.
And that basically acts as a thing. We're trying to see this with the automotive community, because,
you know, we see a lot of vendor, you know, or we encode that people open source is all like
custom IPC and stuff like that. And it's like, Well, no, there are open source projects that are
heavily used that do, you know, gRPC and, you know, interact with cloud providers and stuff,
you don't have to reinvent the wheel. So Cooks of Al has been a very good thing for us to sort of
try and get that to people. So how exactly are we using an AGL? So there's, you know, the assess
applications. As Eric mentioned, the concept of, you know, there's actuators. So there's, you know,
apps that basically just listen to sensors. So like dashboards type of, you know, things like that.
And then for acting on signals, so basically implement an actuator behavior, we have some example
services that do that kind of thing. It's like HVAC sort of stuff. There's also setting an actuator
value. So that would be like on a user facing infotainment app would be like HVAC controls or,
you know, audio or volume that type of stuff. So in our tree right now, we have two demo services
that basically do that actuator side of things. So we have HVAC service that basically listens to
all the like signals in the VSS hierarchy around HVAC controls. And then in our demo setup, which
unfortunately we won't have the full setup here, actually pushes out to drive some fans and things
like that. In the audio side, basically I'm listening into the audio like volume signal that's in
VSS and we, you know, have some custom things that I'm working to push upstream. But basically
actually drive that down into wire plumber and actually like adjust the, you know, the audio setup.
The user facing side are demo applications, the QT demo, which I think we might be showing
tomorrow. Basically we're using the SS signals for like everything pretty much. So all the
applications in that demo, which are in our source tree, you can grab them, basically are all wired
up to do VSS signaling. And the code is sort of in a nice little library now and basically allow you
to reuse it. On our newer Flutter demo, which I'm not truthful, actually maybe I think we'll have
one setup that'll have that tomorrow. Basically it's, you know, it has a unified sort of home screen.
It's doing GRPC from Dart. And right now I don't have that sort of library sort of packaged up yet,
but that might happen this year. Or we might move it to native code. Tidder, who are big into Flutter,
they tell us that's what they do that for some of their stuff. So, you know, we're pretty much,
this is what our newer Flutter demo looks like. And so in this demo, like the tire pressure,
all the likes, you know, vehicle speeds and stuff like that, and all the, like the AC controls and
the temperature, all of that is going through VSS signaling to driving, you know, demons or whatever
you want to do. Or KNData coming in actually gets converted back into a signal update. So,
so there's some extra, you know, presentations from Sven and Eric myself. And we're going to be in the
AW building tomorrow. We're open bed at work today. We're to have that table tomorrow. We'll have our
demos. And this is, you want to do your pitch? Sure. So if this sounds interesting, or even
if it doesn't sound interesting, there's a huge chance to engage with the community around
coaxa and the larger communities in the automotive sector. So we have something called Bosch Connected
Experience. It's hosted by Bosch, but it's basically very large hackathon in Berlin in the end of
February. So a bit short notice, but I would be really glad to see some of you there. We have the
chance to work with a lot of things like maybe actual seats, maybe actual cars, hopefully. Or
and also we plan to have some meetable assimilation of a car which is then connected to a data
broker. So I think it will also be cool what you can do with combining these physical and also this
cyber physical world, if you will. So I really encourage you to do that. If you want to come there,
you normally have to apply. But if you just approach me, I think we'll find a quick way to get you in
because being you in this room, I think qualifies as a good hacker for that. So was that maybe
you there on another community meeting? So thanks a lot for stating this out and we open for questions.
Yeah, I think we have a couple of minutes.
Yeah, we'll have to share.
Thank you. Great talk. Just wanted to understand a little bit about your
testing cycle. So if you you're developing something with this and then you test it in a
virtual environment and then you want to test it on a real car, like what do you do in practice
when you're developing stuff? Do you have an answer to that?
So I wouldn't have a straight answer because here we talk more about implementing that abstraction
layer and mostly testing it against things like this mock service or with something like a feeder
where we have recorded data. But things that you're touching on a small like a really general
topic on how do I actually get my automotive software up and running and into the vehicle. So
that's a bit beyond the scope of what just the Cookshead project is doing. So not too much I
can comment on here, but I think it's a good topic for the communities, either AGL or Eclipse
STB because we have some rounds of meetings where we exactly talk about that.
Yeah, I would just say that it's still actually pretty early days for
DSS. I mean, I know there's a bunch of OEMs and interior ones that are actively working to product
eyes. So I don't think we have visibility yet into how they're actually going about and testing.
So I think hopefully in the next year or two we'll see more and we'll maybe get some ideas there.
Any more questions?
Maybe in two or three words, can you share a little bit about the data broker? Is it something that
looked like Debus? Is it something like look like MQTT broker? Something else? What it looks like
exactly? Is it something that we can reuse elsewhere or is it specific to Cookshead?
I would say the data broker is really specific to VSS data. So it's not like you can
put any data in there. So the way it works is you start the data broker and you also give it this
VSS data model that you have. So the VSS data model is expressed in a JSON or in a YAML file.
Then you put this JSON or YAML file into the data broker and then you can basically do get set
and subscribe. That's why I put up this slide again on this kind of data which is expressed in the
data model and then the data broker implicitly knows about that. When you talk about MQTT,
there's also I have to admit other APIs to interact with VSS. For instance, VIST done in W3C
and they also looked a bit into how to do that over MQTT. But again here,
the data broker is especially tailored to interact with VSS signals. That's why I cannot
generalize it too much. Basically, when I go home, I have a project that our vehicle to cloud,
Expert Group in Agile, wants to see basically pushing from VSS up into the cloud. So I'm going
to be building a proxy that will basically take a list of signals to listen to from the VSS
data broker or cooks a data broker and then basically MQTT them up somewhere. So then talk to
us in a better world. I'll have a story for you then. Maybe one final thing to add to that.
As there's one slide, I actually removed it from the slide deck but there has been a huge
discussion in the VSS community whether VSS is actually fit in the vehicle or whether you should
use VSS more on the cloud back end so that you put all the data from the car and whatever form it
up to the cloud and then consume it in VSS there. And the data broker is kind of like an answer to
yeah, it's also possible to do it in the car in addition to the cloud. So that's kind of the
background story as well. Okay, so I think that's all we have time for for the moment. So thank you
very much Sven Eric and Scott and round of applause.