All right, everyone, I recommend to this presentation about all the reverse engineer your
canvas and build an ECU with using elixir, I'm Tibo Poncele in a software engineer, and together
with two colleagues, we have built a spin for Tico, which is an IT and a constituency
and product company, and for about seven years we've built an open banking regulator using
elixir, and after so much time in finance, we wanted to explore new opportunities and
see how far we could go with elixir, and if you could be a good fit for the automotive
use case, so in 2024 we took a sabbatical and we've built the open vehicle control system,
which is an elixir-based decade, allowing you to upgrade any vehicle, and by upgrade
we mean converting it to an EV, swapping the engine, creating a new influence on the
maintenance system, and hopefully at some point we hope to allow you to transform your
vehicle into an autonomous one. So in our case we use the two or seven diesel Polo, and the
first thing we did was to convert it into an EV by putting Nissan Leaf electric motor in
it. I won't go into the details of the mechanical work, and there is a lot to say there,
but that's not the topic of the day, and today to show you how to do the reversing engineering
in practice, we will just focus on a very simple use case, which is how to make the VW
dashboard display the RPM value from the Leaf motor, so that's one of the things you need
to do if you want to have a seamless integration between parts from different manufacturers.
So you may know it or not, but in all of your cars you have a canvas, so that's a controller
RR network, and that's basically a twisted pair of copper to on which of the components
of your car are connected and are sending frames, and that's a standard protocol used in
automotive, but also in planes, trains, even for used-car machines, and the good thing is that
you have built-in support in the New York Journal using Hipsocket can, and then the way to
send frames on that boost is standard, but the content of the data, the values that are
sent are not at all, and of course, care manufacturers are not providing any kind of documentation.
So this is what can be frames are looking like, what it looks like, so you have here a list
of frames that are exchanged on the boost of the Polo, you have a list of frames that
are IDs, the frequency at which they are emitted, so it's broadcasted and all the components
can receive all the frames, and then you have the whole bytes that you have to make sense
of, and so when the color of it changing means that something happens, so if you put the
end break, you will have some bits changing somewhere, and you have to find which frame
is linked to what and which value is what, so yeah, the main IDs that you have these frames
emitted periodically on the boost, then the tools that we used, first you need to physically
connect to that boost, so we use the device, which we could put the laptop, and then the
screen you've seen before is from Savica and that's an open source GUI that allows you to
display the values and also replay frames and so on, and then one tool that is a bit less
known, it's a kit can deal, that's the demand that allows you to stream a kit with the IP,
and that's quite useful because then if you put a Raspberry Pi and in this in your care,
you can work from your desk on your laptop, and you can send and receive frames in three
times, so that you can have a smaller cycles. All right, so first thing we need to do is to be able
to receive that FPM value, so the rotation terminates from the leaf motor, and we chose the leaf
the leaf motor because you have kind of a large community of thinkers that already reverse
engineer, actually, the frames are underneath and leave, so we could find some DPC-5 on the internet,
so the DPC-5, it's a frames specification, and in one of these files, but while bossing it,
we could find the inverter status frame in which you have that two by 15 bits of output
revolution, which is supposed to be a big identity, I'm going to call it an design integer,
and then yeah, to validate this because that's a community source, we just connected to the
engine, to the motor, make it run, and then actually it seems to be the two full bytes,
so the 16 bits, it's big identity, but it's a design integer because the motor can go both ways,
so it can go backward too, so that was easy, no, that much of reverse engineering,
so we can hit it, we also have to be able to send the value to the Poro dashboard,
and in that case, we made kind of a big mistake, because when we got the care, we jumped ahead,
removed the engine, and all the parts we didn't hit it, and then we started thinking about,
okay, but how do we reverse engineer that now? So if you want to do this, before doing anything,
just go for a drive, you recurled the word can, so that you have an example of all the frames,
anyway, so there is not such a big community about the VWPoro, but still we could find
someone else that did some research on another Volkswagen of the same generation, so it seems that
the frame 280 has the RPM value in the second and third bytes in little Indians, it's shifting
the bytes, so using that hint, what we did to validate it is that we used the frame center interface
of silicon, where you can define a frame that you want to send, which data at which frequency,
it turns out that the dashboard of the Poro is also validating the frequency at which it's emitted,
so we have to try a few values for this, and after a few tries, we had that needed moving,
so that was already quite a success, but actually on a canvas, you often don't send the value as
is, it's most of the time it scales and sometimes offset it, so you need to reverse engineer that
scale value, again the usual way for that kind of value is to drive the car, you recur the
picture of the dashboard, and then you match the timestamp of the canvas that you have recorded as
well, and then you try to match them, in this case it was not possible again, but actually that was
even simpler, because since we could control the value that was emitted, then we just have to
read the approximate value displayed by the leader, and you put that in a spreadsheet, and then
it's quite easy to guess the scale value, and once you have the two curves that matches, you know,
that you have the right scale, so yeah, it's a bit tedious, but actually you don't have any encryption,
you don't have any anti-reversion engineering methods, so it's just about finding the right bits,
and then how to interact with them. All right, so though we know how to read the value, we know how to send it,
it's we are missing something in between that will do the conversion, so that's the ECU,
we are building today, so the vehicle management system, and we put this in between the two
basis, we don't mix the components from the leaf and from the pull on the same physical canvas,
because you could have the same ID used by the two manufacturers for different use cases, so we
could keep this super segregated, and then we will be with some codes in LXI that we do this
translation and proxy the value in between. What let's do this, why LXI were felt because we liked it,
and also if you may know it, but that's a functional language running on the beam, which is the
machine, and that the machine has been designed by a song a long time ago, to build
Tiffany's features, and so that's designed to build some real-time applications, and it's also,
the can use cases quite close to that the telephone use case, because you receive bytes,
you have to handle them and then just allow them to somewhere else, so you can see that the language
is really fitting, the truth is pretty well, and the pattern matching feature that they have built
is really nice to pass the frames and extract data in a maintainable and reliable way.
concretely, that's all the lines you need to connect to a canvas, and sorry, and receive one frame,
so you have the first few lines that are about connecting to the to the sockets and binding it,
and then you have that sockets receiver function that will block until a frame comes in on the bus,
and then from 9-8 to 13 you have that pattern matching where we assign to the ID variable
the first 16 bits as an integer encoding in LXI, we skip to bits, we extract the number of bytes in the
data, skip three bits again, and then we extract the whole data based on that number, we just form,
and then if the ID matches, we will extract the RPM value as that begin the unsigned integer
and then just show it from the console, so it's quite concise, it's quite feasible, like according to me,
it's quite different to what we would see in some other languages, if you already did that,
you could feel that it's a good patch. Still, when you have to receive and send a lot of
frames, it can be a bit tedious to do everything manually, so while we were building the open vehicle
control system, we also extract it, an open subscribery, that we just focus on providing
an easy interface to emit and receive frames, so basically you will define a YML file in which
you define all your canvases and all the frames and the signals to the values in it,
and a contestic will make sure it converts with the right scale of settings on for you,
you don't have to think about it, and you could also then spawn one process, so in the
Excel that's a gen server, per network to have a receiving loop and then it will dispatch the frame
to all the all the processes that you that's supplied to it, and finally you will have one
emitter process, per emitter frame, and it will take care of emitting it, so you add the right
frequency and do the conversion of the values, all right, so let's build this using
contestic then, so on the on the left you have the YML file with that leaf driver can network,
and then we have received frames of the investor status one that we found on the DBC file,
and we defined that rotation terminates as a big Indian integer, and then on the right you have
all simple business logic code that is primitive also as a gen server, so we spawn a process,
when it starts it will subscribe to the inverteus investor status frame, and then contestic
will send, will send a message to the that process every time the frame is received,
we extract the RPM value, and then the only thing we have to do is send it to the dashboard process,
on the dashboard side we define just one emitted frame, so the engine status one,
we apply the scale that we reverse engineer, so we don't have to take take think about it on the
in the business logic, and here we will just configure the emitter so that it starts emitting immediately
with RPM of 0, and we implement that set rotation per minute function that we just update the emitter
with the new value, of course, VW didn't expect it to be as an engine to run backward,
so we use the absolute function call to only send positive values, and the good thing is that
this call is recalled every 10 milliseconds, because that's the frequency of the live frame,
but the emitter will only send it every one of that milliseconds as expected by the dashboard.
Okay, so now we have the application code, and let's build a real ECU, so an electric
controls unit, so that's the concrete component that we put in the car, and for that we use
a Raspberry Pi with a few Canvas modules, and we are packaging this using now, so now this
an electric platform that we will use build roads to create a very minimal Linux, on which
that we immediately boot on a link, and if we also use FW app to update over the RUSB directly
on the SDK, that's a really nice project too, and yeah, so we package this, we put that in the
car, connect it, and it works, we now have a, thank you, so yeah, we now have that needle moving
at the right, to the right value, when the the leaf motor is running, of course that was just
one little example, and we had to reverse engineer the speed, the handbrake, the throttle pedal,
everything to have a running car, that's not the topic of today, but at least you have the
AIG, again it's not that complicated, and when you start working on this you start
worrying about the security of your car, you can see that it was not designed when the car was
connected to the internet, so maybe things could be, could be improved anyway, and so that's it,
if you want to know more about about to be seen itself, my two colleagues are also presenting
to more afternoon, so don't hesitate to join them, any questions?
Yeah, first of all, great talk, thank you. So when I'm teaching Alexa to people, one of
distinction or one example I usually use of soft real-time versus hard real-time is that you would
not want to use Alexa for say example driving a car, so I'm really curious about how you're
approaching this, and what sort of things you're actually using OVCS for in practice?
Yes, so it's not meant for a vehicle that would go up on an open road, it's not yet certified,
it's open-source, but try it at your own pace, and then we have some parts today running on
our windows, we didn't see, like you really need to control the brakes or things like that,
might be a better idea indeed, but actually for most of the cases you already, you anyway have delays,
you have a horse on the roof, so for none, you have a lot of non-critical
features on your car, but actually the soft real-time part is good enough for what's in it.
And then yeah in practice we still have issues to work on, that's true, but we really wanted to see
how far we could go with that in Excel, it's like, you said a process permitted frame,
do you mean permitted frame type of every single frame is a new process, is that that works?
Yeah, so you have the inverter status frame, that is immediately with 10 milliseconds,
so you have one process for that, but in Elixir, the processes are really cheap, so you could
have dozens of even millions of process without any issues, it's really lighter than the
kernel process. Yeah, just a quick question about reverse engineering, the cam protocol,
easier some kind of community driven effort to have, I'd say, most build-in model,
and that a base of knowledge base of all these protocols and all these things,
like I did some kind of the fact that one might be in the blue car, because I had to fix
an apartment system, but it's only on my blog, it's not somewhere in the, it might be interesting to
also have as a side project, these kind of knowledge base, because you might have come here.
Yeah, so you have some communities on specific cars, like the Nissan Leaf, you have
on tire firms, about it, you also have come out of the AI that is providing an open-dBC
GitHub repository, where they are trying to aggregate this, this gives us engineering,
so yeah, it exists, but not for all cars, not for all generations.
A few besides reverse engineering, the canvas, that you also consider replacing the RPM
reader on the dashboard, for one that's compatible with the...
Yeah, so that's the usual way, when you convert to an EV, when you do retrofitting,
most of the time people are just putting a new screen and it works, it's easy,
but then it doesn't feel as simple as it could, so in this case we really
reverse engineer the ignition block as well, so that it starts the electric engine and so on.
So yeah, it's... yeah, I'll test, I would say. But it's really nice to see the old dashboard
displaying the new value. Also, we didn't do it, but the goal is to display the battery
a level with the tank. So you mentioned during the talk and a few moments ago that you've
got all these communities, all these DBC files for different cars and things, and then you're loading
all these descriptions in the ammo. So you're wondering, is there a converter
why you're not just using the provided DBC? I could show you an example, but the DBC file,
it's a property format, and it's really ugly. But it's the default format, so I couldn't...
Yeah, it was a sabbatical year where we did... we did some fun things, and I could...
push myself in implementing this. But the idea would be to have a conversion tool to go from
the ammo to the... because here it's easy for anybody to hear, and in the DBC file it's like
impossible without GUI, that's really ugly too. But I GUI, that could be a good idea.
We should support those, probably.
Yeah, thanks for the talk. Do you know if we're obitly too connected or also expose this,
we can come on so that you can reverse and linear it without going to the motor and getting
your kin through this from where? So the problem on the obitly, that's the socket you have in all
cars to do the diagnostic. It exposes some things in a standard format, but you don't have access
to all the values. So it's just like the speed, the RPM, so you would probably have, but it's
probably not at the same frequency, but you won't have access like to the endbreak by state,
or the door state, or things like that. So if you want to go as far as possible,
you need to reverse the property frames. Do you want to say that the canvas lines
from the connector are different from the other? Yes, so there's a proxy or something.
Yeah, there is in most of this, so it depends. Like in the leaf, they expose in DODB to
two lines for the internal one and also for the standard one. But on the VW, you just have a filter
version of the other kind.
Yes, one more question. Is there any way to use the XR code and run it on like the speed of it
you or we might call controller a platform instead of full-flage Linux board?
There are some projects, but yeah, to run the beam, you normally need a line XR.
But I think there are some both that were designed to run a line on the metallic self,
but we didn't try it. We also tried to use the cheapest
both and easiest available, so we are using a very price in our windows.
But if you want to go further with that, you should definitely use something else.
It's called XMVM? Yeah, thank you.
Does the open vehicle control platform support automotive Ethernet and
encrypted frames and these kinds of things? Sorry.
The open vehicle control platform supports automotive Ethernet and encrypted frames?
We're not yet. It could easily be added, but
if we don't have one aspect. Just to follow up on what the person was asking here.
What kind of wrong footprint does your beam elixir have? How much space does it occupy?
All the binders and the interpreters and everything with the virtual machine?
Very, very, also what kind of memory requirement does it have?
I don't think it's expensive, but it's really small, and the footprint is really a few megabytes.
What about RAM? A few megabytes too, but on this pair, I should have, which should try.
I don't know. I don't know. I don't know. I don't know how to prepare you.
It's interesting to have an embedded solution,
eliminating memory fragmentation, which can be difficult, because I assume this language is
data-quare, you know, heap, and use heap extensively.
Yeah, it's, you need an OS, and so on, so it's not, okay. Thank you.