Okay, hi. Good morning. Thank you for being here. I will try to speak as loud as I can
because my voice is not amplified. So I hope in the back view here, make correctly. Okay.
Thank you. So I'm Ego Mercier. I'm a software engineer at IHC.BZH. And I'm going to
talk about a text EVAC, which is an open source project for an electrical vehicle charger.
So a few words about my company that I work for. So we are IHC.BZH. And we are located
in Brittany, North West, France. We are a small team of around 20 engineers. With strong
expertise in embedded software. We have different customers for which we do services like
consumption, consistency, support and development. And we also have a product that is called red
pesc, which is both Linux distribution, oriented to embedded systems and a build platform.
And so the project I'm going to present to you today is an open source electrical vehicle
charger. And it has been done in collaboration with Valiou, which is Carve Carre equipment
supplier. And I wanted to have, while to showcase the possibility of an electric vehicle charger.
So, and they also integrate a third-party commercial stack for the ISO 15118 parts.
So yeah, we are focusing on the the use cases that are interest for us is based on the
ISO 15118-2 and dash 20 standards, which are well basically it's a way as a
San Diego said just before. For the car and the charging station to communicate with the network
product protocol. So it's a TCP over IP protocol, which may involve also TLS. And it does a lot of
things, but basically that's a way to check that the car is authorized to charge and a way to also
check for the billing details, the payment details. So we have different modes of authentication,
either with a simple RFID card that you get to put on the on the charger or something more involved
that is called plugin charge, where you have a contract with an energy provider that is stored
in the car and the car when you plug it will automatically, well the charger will automatically
click check that the contract is valid and will give you access to the charging station.
And it may involve a lot of things online because you have to check the contract with your
energy provider and the charger has to send details to the energy provider as well.
And in ISO dash 20 there is also again lots of things, but one that is of interest for this project
was the ability to discharge, so the car may discharge itself into the grid.
So we've set up this, so we have this defaulting setup for this project, which is quite
classical, we have an embedded board which is made basically of two CPUs, one that runs our red
pesky new XOS and another microcontroller that runs a real time operating system. This one is
in direct contact with the electrical states of the car and is responsible as well
of handling the PWM states that some segmentation just before. We are also as well have module
to handle the energy measurement, something to plug an NFC card reader and it's an internet
connection of course and a small screen for the user interface. So the fact that we have this
complex setup may we may have some security issues and at least that's the we may have some
security issues in the sense that it is a potential large surface of attack because we are
connected to the internet for payments and an application we are connected to the internal
internal network of the car and it's the charging protocols are quite complex so you may have
bugs that could be exploited by attackers. So there are some threats that exist, a simple one may
be that someone find a way to charge itself freely, which is not that bad, but you may also have
a confirmation of network or an electrical risk because you are delivering something that is not
the right current which may, yeah, because the risks. So the design of this project has been initially
thought as with security in mind and we have been using a micro-service framework that is
focusing on security. It comes from Tizen, an operating system that you can find in some
TVs and it being reused also in the automatic grade Linux project. It's basically micro-services
which communicates through remote procedure calls through what we call API verbs and events,
but yeah and the key point is that the different micro-services are isolated one from each
other and they have all their own security context and it's enforced by some feature of the Linux
kernel that is called Linux Security module and especially one that is called smack which could be seen
as an embedded version of the SLE Linux if you know and we also have an applicative permission
database that is called Synagra. So the different micro-services we have for this project
is these different big blocks in rows and green. So we have one that is responsible for the
authentication, one for the display, one to measure energy and one in the middle that is
kind of orchestrates all the different protocols and the logic of the charging protocols and it
is also connected to the powerboard and it will in the end close the relay to the power connector.
And yeah we also I mean focusing on security led us to consider Rust as the primary language of the
project. So every services that I showed here are written in Rust because we found that
it gives us memory safety without compromising performances. So we still have the core part which is
the application framework written in C but we have Rust binding over it but all of the rest is written
in Rust. During the development we had to use some simulators, some car simulators because the
ISO 15118 is not simple to debug. So we have a hardware simulator which costs a lot but we also
developed an open source simulator injector that you can find here that is able to discuss ISO 15118
if you like. So it had been of great help for the project. Yeah so just some screens of the final
product so it reproduced the different steps of the charging sequence so you plug with your car
then it will ask for plug-in charge and if it's not available it will fall back to
it will test the your authentication plug-in charge on all it will fall back to basic charging
and then give you a summary of your charging sequence. So that's it so you can have a look at this
guide page if you like everything is on here so we publish everything under so what most of the
power Apache 2 and the core part is GPL 3 or commercial license with us. Just to give you some
just to give you some words about the challenges we faced so debugging ISO 15118 was not easy
it's not easy it's a quite complex protocol so as I said having the simulators and the
Buggers help a lot either hardware or software. Understanding ISO 15118 PKI I mean the contract
with the energy provider that I thought before is made of certificates and certificates you have
to have a full chain of choice to respect and it involves lots of different actors and it's hard
to understand and this synchronization between the different state machines of charging
sequence is not easy as well so you have slide you have ISO 15118 OCPP and so on so it takes a lot
of time to to implement and debug and in the next steps we would like to add the so ISO dash 20
support to the simulator to our hours of towards the simulator and also have an open source version
of the ISO 15118 logic which is not the case right now and that's it thank you
for the five minutes at their questions yes what is the part in C so the part in C we have
the part in C is what I call the application framework which is still in C and then we have
a binding rest binding over it it's used for this this micro service communications
and the security layer and so on we it's still in C maybe one day we will part it in in
the rest but it's not the case right now and I think for the yeah the simulator part it doesn't it
depend on this framework but it still it still depends on C code that are generated automatically
generated from XML schemas and then we have rest of our rest binding over it and and again
that we that's not the die the the the most direct path we could have a direct rest version
that takes the XML schemas and directly generates rest code that would be a better path I would say
but we we didn't have time to do that yeah yes presumably the thing you just described
you just got very shallow bindings are seen isn't I don't use any significant security risk
score I mean there's no opportunity for human being to foul up that automated chain that's
probably the least of your worries yeah for security if the generation chain is is correct
and valid yes that that could that yeah the question sorry
well the parts you mentioned but not straightforward to do with the eye of the
has had a chance to look at other protocols even though it's not a thing with a hero
just to compare like a child they wanted you for you to see how it is done and if it's better
why do you please read the question for you so yeah the question was did we look at different
protocols between the current the charger except the ISO 15118 I don't think we do because that was
the requirements for the this project of course we we also also do basic charging as some
shadow presented before so the simple one with the the electrical signals but I don't even know
what are the alternative how does this project compare to the average good question so the
question is how does it compare to the average project so average is way more advanced I would say
because it's it's a bigger team but maybe this one is more focused on security that's
what we wanted to to to have and that's what the final customer wants it yes I've been
just giving the dishes is between the hardware simulator and the software simulator or more
particularly used to lead the hardware simulator where you have the software one yes so the
software simulator is about to do you can plug it with an SNAT connection so it can do
the slack negotiation if you are aware of that and it can do the ISO stuck because it's only TCP
TCP connection so it's pure software so it's okay but what it cannot do is play with the charging
state because it's a pure electrical and it cannot you cannot because the hardware part is
able to also use the power line current communication and so on so this cannot be done by software
at least it's it's too complex to do yes last question is this the
question is the hardware available no you cannot no it's not it's not no you cannot buy it directly
but I didn't get the I didn't publish the the bill of materials but you can't find it is
I mean it's quite available hardware that you can find it's a feedback board with quite
common PSC modules and so on so you can find it easily thank you