Okay, welcome to the next session.
So I will be talking about KuxaWall and in vehicle access to standard VSS signals.
I will tell you what it is.
I hope I can convince you that it's a good thing and you want it, but let's see.
I'm Sebastian.
I'm part of the Kuxa project and when I'm working, I'm working for Eters on vehicle
software.
So Eters belongs to Bosch.
If that is something that's more familiar to you.
So yeah, this is about automotive software.
So let's get started.
We will start like very high, you know, like sky high.
And then I promise we go down to code.
So there should be something for everyone.
First thing is what's Kuxa.
It's an open source software project.
So I'm not totally at the wrong place here.
First time for me, first time for Kuxa, I think.
Kuxa doesn't stand alone.
Actually it's part of the Eclipse software defined vehicle working group.
So Eclipse is one of those many happy homes that exist for open source software.
And the Eclipse SDV working group, that's basically a bunch of companies and people
interested in automotive open source software and a couple of other interesting projects
beside Kuxa.
But we're focusing on Kuxa.
You could say Eclipse SDV, it shares the software defined vehicle mindset.
So what is that?
I mean, later just Google it.
You will see that's basically the latest and greatest type in automotive.
So whenever somebody tries to sell you automotive software these days, they will probably put
the SDV stamp on it.
So what does it mean?
That's also, I can only give you a very broad thing.
So it's a little bit of a marketing thing.
But what it normally promises is faster updates.
Like I mean, today maybe you have a phone and you get a stream of updates for two years
and if it stops after two years you're pissed.
If you have a vehicle it's a bit different.
Maybe if you're lucky after two years you get an update with some emergency patches
and yeah, you should feel pleasantly surprised about that.
And SDV is a little bit about making this better in cars that you have more like these
apps and software functionalities added later and not so much big blob of firmware that
we only update in emergencies.
It's often you hear this term 10 times faster development, not 10 times faster than you
are maybe as IT guys, but 10 times faster than automotive is currently.
Because a lot of software there comes rightfully so from the mindset of like deeply embedded
stuff, you know, embedded for real men and women, engine controllers, real time issues.
And there, I mean, of course it is harder in a slower process to develop software.
But somehow it has taken over also to the higher levels of your vehicle now.
So even your infotainment doesn't update as fast as maybe your Android phone.
And that is something SDV promises to change.
Many companies promising that.
So that will make you as a user of vehicles more happy, developers more happy because finally
they can write software for vehicles or it gets just cheaper, makes corporations happy.
So that's, yeah, SDV is awesome.
Just Google it, lots of press releases about it.
So how do we do it?
So I, well, the point is in IT we can already do it.
So it's pretty easy actually.
We take all of our favorite text tags we know and laugh which are super productive.
We put a bunch of beefy hardware.
Okay, we need a little bit more hardware, but that is some understanding that's coming
to automotive.
It might make sense to invest a little bit more on hardware to get cheaper and more
productive on the software side.
And we put it all in a vehicle, done.
Problem is, I mean, we do it, it's pretty cool, right?
I mean, maybe you have your Kubernetes cluster and cars and I'm not joking.
People think about that and doing that.
So you can probably deploy WordPress easily, right?
And if you put good enough hardware, I think your doom frame will be pretty acceptable.
Of course, there are challenges, right?
I mean, it's a vehicle where you drive around yourself with your family or things like that.
So probably thinking about safety and security is a good idea.
And we come to that a little bit later in the talk.
But the problem is, if you put all these in your computer, if you don't have any access
to the vehicle's hardware, if you can't actually interact with the sensors and actuators in
the vehicle, yeah, then maybe it ends at deploying WordPress, right?
You can't do all these fancy automotive applications you have in mind.
And that is sort of the challenge.
It doesn't help you just putting all these text-texts on there.
What does it, let's see, we're stuck here.
Okay, so what does it mean to access vehicle hardware?
So mostly the most interesting part on a vehicle is really signal-based on a very low level
and you have maybe two kinds of interesting things, sensors, how fast am I, and simple
actuators.
You want to open the trunk, open the door, engage the vipers.
Now you might think, no problem.
I read about Linux.
It has can interface, automotive, I just enable it and off I go.
But of course, it should be pretty clear that it's maybe not a clever way to just let anybody
who deploys some software in my vehicle interact with all the bus systems and all the hardware
in the vehicle just for safety reasons alone.
And of course, you want your vehicle still to move.
So that's probably not a good idea.
Second challenge is just the way how automotive software evolved in a vehicle.
Let's say the serialization, the data formats are very much not standardized.
So even a simple concept like vehicle speed, how it's represented in bits and what's the
data type and what's the unit and things like that, that is different from each manufacturer
to each manufacturer from model to model, from model year to model year.
So that's a big pain if you want to write a piece of software that runs in more than
just one vehicle.
Luckily, because we don't have so much time, challenge two, the second one is solved or
it's in the process of being solved, there's something called the Covesa Vehicle Signal
Specification link at the end of the talk.
So yeah, there's some homework maybe for you.
The point is that's a very simple data model describing sickness in a vehicle.
It uses identifiers which are based on a tree.
That's just an example.
In fact, it's much more complex.
But you can already, I think, see the gist of it.
Like here we have something like path like vehicle chassis, axle, wheel, tire, pressure.
So you already have an idea of what it is, what it might be.
And the VSS defines then also what would be the data type of it, what would be the unit,
maybe hectopascals.
I don't know, don't quote me on that.
And if you have that, and if your software stack integrates it somehow, then interoperability
and portability would get much easier.
But the question is, that's a data model.
So it's actually a nice, YAML-based file format you convert it to whatever you like,
but it's not live software.
So how do you bring it to life?
And that's a question, where would you use these kind of nice abstracted model?
And two things, talk again about these real embedded layer, probably not.
Because down there, where you have these super small microcontrollers, few kilobytes of RAM,
safety-critical stuff, maybe you can't or don't want to invest in this cost of abstraction.
Because that, it costs, I mean, it's nice and neat, but it costs.
Then, I mean, all the other way, somewhere in the cloud backend systems that a manufacturer
might have, or that a fleet operator might have, there might be a good idea to have an
abstracted data model.
And that is also the place where VSS is already in production today at several different companies.
You can even go to AWS by a generic service for that, if you want.
So there are solutions there, because that is where at first has taken root.
And the question is, on the way between the sensors, which are very deep in your vehicle,
up to the cloud, where would you do this transformation?
Where would you move from these proprietary signals and very different variants to the
standardized thing?
And I think it's no surprise that in SDV, the answer is still in vehicle, because you
want to be better in vehicle.
But the point is, do it not on a microcontroller, do it in a vehicle computer.
I use the term very broadly, but that would be any computing unit in your car that actually
has a processor and has a real, let's say, POSIX-style operating system.
So Linux, for example, maybe the QNX fence here would also work, but not microcontrollers
but the microprocessor platform.
And that actually is exactly what Cooke-Zawal is.
Cooke-Zawal is an open-source software component that can do just that, sit on a vehicle computer
and provide access to the standardized signals.
How does it look like in an architecture kind of view?
So basically, you have something we call the Cooke-Zawal data broker.
That's like you can see, like a small server, it can run on your vehicle computer.
It provides a GRPC-based interface or network-based interface you can connect to.
You can get said, read, subscribe, all these nice signals, these abstracted signals from
the VSS tree.
So it means the applications on top, yeah, they would be portable.
They work on standardized signals.
Of course, you need to get them in and out somehow because down there, I mean, we have
the non-standardized signal.
So there we have something we call it a VSS provider or VSS feeder as a term you'll often
see in our documentation.
And this is a software component that would transform basically the data from the proprietary
things in a given vehicle to the standardized form as required by Cooke-Zawal and as required
by VSS.
Important some architecture decisions.
So this data broker is written in Rust pretty lightweight.
It does not have many features, so no history or things like that.
I mean, currently, it's like less than four megabytes that's statically compiled, you
know, everything all in.
And that's how we want to keep it so that it could really run on even the smallest one
of these vehicle computers.
There's also, I'm not sure if we have old Cooke-Zawal users there, there's a version
of Cooke-Zawal in C++, but currently, I'm focusing on the Rust version for this talk.
But architecture is the same.
So how would it look like, let's say, if you really want to write an application that can
basically open your trunk, pretty simple, right?
User presses the button, open the trunk, and you maybe also want to see whether the trunk
is open or not.
And VSS terms is pretty simple.
I mean, you talk to Cooke-Zawal data broker, you say, I want to subscribe to the state
of the trunk, because you can show this fancy graphic if it changes.
You might, if the user presses that he wants to open the trunk in this app, or somewhere,
you want to set the target position of the trunk.
So you want to, yeah, state the intent that you want the trunk to be opened.
If it ends there, nice.
I mean, you talk to a database, nothing happens.
So in the end, you need these two VSS providers.
We talk about feeder and control service.
So feeder would be the component that checks actually what is the state of the trunk.
It's back to Cooke-Zawal, so everybody can get an updated state of subscribe.
And the control service would run the other way around.
If the target value is set, the control service would be triggered.
And then it can do basically something, right?
I mean, you can write a can frame or some IP that some of these standards, which are
an automotive.
I can make it a little bit more specific because for these toy examples, because now it's just
PowerPoint engineering, but I think people sitting here, they want to see code, or at
least want to see if it exists.
So the point is, how would we make this feeder, and how would we make this provider?
And I show you examples now in Python, two reasons.
Python is compatible with PowerPoint.
I can fit every single one slight.
And second, we have a very nice Python library on Cooke-Zawal that makes it easy.
But as I said before, the interface actually is GRPC-based, and that you can generate
in virtual every language.
So if you want to write this in Rust or C++ or C, or Go, or whatever, you can just generate
it.
So feeder example, pretty simple.
So here in this example, because then you can run it on your computer, we just simulate
the vehicular access.
Normally there, you will need to have some interface to can or some autosite API or something
like that.
So we just pretend whether there's a file or not that states whether the trunk is open
or not.
We just uncheck for that.
And if it changes, we just set this vehicle body trunk rear as open data point to the
current state.
And that is literally, I mean, this code, if you get the slide there, you can't copy
it.
You can't type it.
You know, like in the magazines 20 years ago, you can type the code and run it.
But this code will run.
So I didn't leave anything out for simplicity.
Maybe error handling.
But if you do everything right, it will run.
Control service is basically the same thing.
The control service is now that thing where we say we want to listen whether actually
somebody wants to change the state of the trunk.
And if I see somebody wants to open it or close it, then we would enact the changes in
the e-architect of the vehicle.
And again, we simulate it via the file and let me check.
I think we are not so bad in time.
So I think I can, I didn't dare to show it live.
I'm not that, how to say, crazy here, but I can show you semi-life.
Same code you have just seen.
So we start off by just starting data broker, so this component that will always run.
Then we use something called the data broker CLI, so you can just simulate what an app
would do.
I mean, it's CLI for that.
So you see, I will just query the state of the trunk.
And it's not surprising that it will say, I don't know, because we just started the
Cooks-Avile bookhouse, should it know.
We can now simulate feeding this value.
I mean, it's against CLI.
We just pretend that the trunk might be open.
So I said that.
And it says, OK, that's a good sign normally.
And now if I query it again, OK, the data is there.
So yeah, hell yeah, we can make a database.
Now let's look again.
That is exactly the code you saw before on the slide.
We simulate whether the trunk is open or not, depending on whether this file in temp
exists.
And you see, there's no extra code.
I just, I'm just running it now.
It actually says trunk is not open anymore, because we don't have this file.
We don't have this file.
And if we query again in the CLI, you see, yeah, that is reflected already.
Now we can also, I mean, now assume you have a user and a vehicle, right?
I mean, he opens the trunk.
He closes the trunk, something like this.
So again, we do this here with our mockup.
And you see this is immediately picked up.
You can see from the locks of the feeder.
And again, on the CLI, you see that the state changes.
And that would already be all you need if you want to have these fancy graphics in there,
right?
So let me show you what is.
I can do the same stuff now with the control service, also the same code as you saw on
the PowerPoint.
Basically, it subscribes for state changes.
That's important.
We always have the differentiation between current value and target value.
Because that's important to see, because some operations take longer and we start it.
Of course, first, nothing happens, because nobody requests anything.
But now, again, we are back in the CLI.
So now I can do a set call, which basically is telling me I have the intent now to open
the trunk.
I'm not good at slower typing.
There it is.
I type it.
But now it's fast.
Yeah.
And don't blink.
So you see the trunk control service sort immediately.
Open the trunk.
You could see the feeder also picked it up immediately, because in this example, it worked.
And then, of course, we can, again, get the state in CLI.
Now we're closing the trunk.
Our trunk is fancy.
It can close by itself.
Then pick it up.
The feeder picked it up and you see it.
So that's round trip.
But yeah, that you can also do at home.
So it's all the links you need are in it.
Now I need to get my mouse back to sit.
So that we just saw.
So now, I think one important thing I want to talk about is now, I mean, that's fine
and it works.
And I mean, probably you believe me, it could also work if you know the magic can command
or something like this.
But the question is, would you want to run this in your vehicle or should you do it?
So the question of safety and security, I think, is very important.
So the thing is, no matter what applications, at one point, you need to think about it.
I mean, security is already the aspect that probably you don't even want to give all
applications access to all the data you might have.
If you support the whole VSS tree, I think it has like 700 to 1,000 signals already,
just in the standard thing.
So maybe not every app should access it.
And the other thing is, again, like opening a trunk is maybe not a good idea if you're
on the highway and driving this 100 kilometers per hour.
And so I'm very sorry to tell you that I cannot magically solve it to you.
I would love to tell you download CookServal and everything is fine.
Of course not.
But it's important to look at the architecture.
So the CookServal, it's written that something in automotive, we call it SQM domain.
That's basically, yeah, maybe it's a well-tested software, but we don't trust it much for
any safety-related things.
So what we do there is, OK, we can have authorization, right?
An application needs to prove that I am allowed to write this value or read this value or things
like that.
That's a security aspect.
Same like now these feeder and service we saw in the example.
Of course you could add some extra security there if you want, but the ones I showed
you, the Python things, not, yeah, they cannot give you any safety, at least not in the midterm.
I think now there are some, let's say, activities to try to make a safe Linux kernel.
And of course, I mean, the data broker is written Rust.
You could test a lot of it.
You can wait until you have certified Rust compilers.
Maybe something in the future that could be also carry some safety load, but for now it's
just hopefully a well-tested Linux software.
But the point is once you go into, let's say now you're right on the canvas or something,
right?
Or you do a summary request.
So then you cross this boundary and then there are several patterns that might happen.
So maybe you talk to some deeply embedded ECU that actually is controlling the trunk
lock or the door lock or something like this.
Those things already have safety guard rails in them, right?
They, I mean, even today when this is the same automotive, it's not that they would just
blindly do whatever you tell them.
So there would already be something in it that will check, I don't do it if I am on
a highway with 100 kilometers per hour.
Of course, in line of this architecture, you might, to rethink if it really captures
all the things.
But anyway, on this layer you have it.
Another thing is, since the interface is GIPC, it's just a network-based interface.
So these feeder and the service, so the things that do the actual conversion, instead of
running them on the same Linux domain, the same Linux machine, you could of course also
run them on a more powerful vehicle computer that might be able to carry safety load.
So like in automotive, we say that's maybe an SLB, SLC kind of thing.
So maybe something that run Q and X and only certified software.
So maybe if you implement your feeder and services there, then they would be able to
carry some safety loads.
And of course, you can always, I mean, use underlying security concepts as you want.
It's always a good idea for defense and death.
So the thing is, as I said, we don't give you the magic bullet, but instead of now giving
every random application access to any kind of vehicle, hardware, vehicle buses, one
thing you have data broker, a single entry point, and basically you can do all the security
you want there.
And then, since this is your control point, and you control what kind of feeders and services
you build, depending on your application, you can see where you need to put some safety
loads and where you need to deal with safety.
Because there are issues where maybe you don't need to do, because in automotive we have
lots of these gateway things everywhere we like them.
So if you have an application that just doing telemetry and receives the data from some
interface where you basically already have a data data where you can't even write, right?
Maybe it's fine to do everything on the Linux one safety side.
But the moment you want to actuate something in a vehicle, you need to think about it.
That's the most important thing, but I think we give you all the knobs you need.
So regarding to enabling SDV, just to repeat it a little bit.
So yeah, if you want any application to access vehicle buses, that's probably a pretty stupid
or insane thing to do.
As you've just seen, at least with Cooke's, you have this single control point where you
can already solve the security issues due to this architecture with the feeders and providers
and this very generic interface.
You can choose where you put those, and you can choose where you put then any safety control
points in.
So that enables you to really build a safe system depending on your application.
Other thing, what we said before, I mean, another big challenge is that the signals
in your common vehicle, they are all different.
I mean, vehicle speed on five different vehicles is encoded in five different ways.
But as in Cooke's, you can use the Covisa VSS specification.
You're basically on the safe side there.
You can use the standard signals.
They're really standardized.
You can also describe your own ones if you want.
That depends on how you want to apply it.
But the point is you have a common language for that, and you can use this throughout your
whole tech stack.
So if you really go to the cloud or things like that, you do the transformation already,
Covisa VSS site on the vehicle, everything else is just piping through, and you don't
need to deal with some weird bits and bytes from Canvas up in your cloud level.
So that is, I mean, as Covisa, we can't solve everything in the software defined vehicle
because we want to leave something for other people, but the interface program that you
have, same, safe, and same interfaces in the secure and safe way, I think that's a very
good starting point.
And the thing is, in the vehicle, everything starts with those low-level signals because
the whole data fabric of the vehicle down there is built like this.
To learn more, yeah, I mean, you can ask me all you want now or grab me outside.
Otherwise, a couple of helpful links.
So our GitHub, where the main hooks of our data broker sits.
If you don't find me here or don't dare to approach me, you can also click the link,
and then you find my contract address.
I would invite you to check out Eclipse SDV, as I say, there are other interesting projects
in there.
Covisa VSS, which is gaining adoption throughout the industry as a data model, it's a super
interesting thing.
And some advertising plugs for one of our sister projects in Eclipse SDVs, Eclipse Velocitas.
So I show you this very bare-bone Python examples, if you want to have something more fancy in
regard to how you write vehicle applications, like a whole development framework with generating
deployable containers and things in CI, then Velocitas might be very interesting.
Why I make advertisement for this, not only because it's cool people, but they also integrate
Covisa.
So if you are a Velocitas app developer, you also get everything that Covisa can do.
Yeah, that's all I have to say.
And if there are any questions, I'm still here for three more minutes, I guess.
Okay, so we have a question from the chat room.
I'm going to pick one, there's a couple.
Are there available CAN or CAN FD data providers for some cars in an open repository?
Yes, so what we have is something called a CAN feeder or DBC feeder.
That's a very generic component to get CAN signals in.
Basically what you need is something called a DBC file that's an industry standard, how
you describe CAN signals and do a mapping.
And it's always hard in industry to get example traces out, but for the CAN feeder, we have
a trace from a Tesla Model 3, not because they give us, but because the community reverse
engineered it quite a lot.
So basically you get a big trace of a Tesla and the mappings to VSS, which you can try
out directly.
Okay, I think the question was with regard to OBD, so the answer to that is it is pretty
trivial to build an OBD feeder and you can do it at home with let's say the Python examples
and if you're in a Python world, yeah, there's something called Python OBD, which is like
a very simple library for all the standard on signals, the challenge why we have not,
in our repositories is we are all a patchy two license on Eclipse Foundation and the
Python OBD, just one example, that's a GPL-based code, so we can't put it in the repo, but
you can, I mean, nothing stops you basically to do that.
Thank you for the presentation.
It's quite inspiring and actually my question is relating to this one.
So let's say if I go home and would like to implement something, then what hardware and
software I would need and how much it would cost me to start develop something?
So if you start with your own vehicle, which is basically your own responsibility, then
what we just heard, like if you buy these OBD adapters, like from AliExpress for five
bucks, you can get them and you can, with a few lines of code and several languages,
get already some interesting information about, let's say, your current vehicle speed, engine
load, oil temperatures, yeah, so that would be, I think, the coolest way if you just hack
around and we actually have many people, also students who do that, hardware-wise, I mean,
if you want to go into real vehicle, I think you need to dare to cut some can lines and
go deeper, but then you go into, let's say, if you're not working with...
If I would like to use your stack, so I would like to use Cuxar, wow.
Basically you can use, so, hardware-wise, I think there's also, Cuxar also has hardware,
I hadn't time to present it here, it's Cuxar hardware, which is a base module for Raspberry
Pi compute module, and it includes two KNFD interfaces and OBD, currently the challenge
is we can't sell them to you yet, because we have the manufacturing files, like online,
so if you have electronic shops, you can do it, but yeah, they're not just, you cannot
not buy them.