WEBVTT 00:00.000 --> 00:10.440 Okay, hi. Good morning. Thank you for being here. I will try to speak as loud as I can 00:10.440 --> 00:16.640 because my voice is not amplified. So I hope in the back view here, make correctly. Okay. 00:16.640 --> 00:23.840 Thank you. So I'm Ego Mercier. I'm a software engineer at IHC.BZH. And I'm going to 00:23.840 --> 00:32.000 talk about a text EVAC, which is an open source project for an electrical vehicle charger. 00:32.000 --> 00:41.120 So a few words about my company that I work for. So we are IHC.BZH. And we are located 00:41.120 --> 00:49.040 in Brittany, North West, France. We are a small team of around 20 engineers. With strong 00:49.040 --> 00:57.040 expertise in embedded software. We have different customers for which we do services like 00:57.040 --> 01:03.440 consumption, consistency, support and development. And we also have a product that is called red 01:03.440 --> 01:11.600 pesc, which is both Linux distribution, oriented to embedded systems and a build platform. 01:12.240 --> 01:20.320 And so the project I'm going to present to you today is an open source electrical vehicle 01:20.320 --> 01:28.400 charger. And it has been done in collaboration with Valiou, which is Carve Carre equipment 01:28.400 --> 01:35.200 supplier. And I wanted to have, while to showcase the possibility of an electric vehicle charger. 01:35.200 --> 01:46.320 So, and they also integrate a third-party commercial stack for the ISO 15118 parts. 01:49.120 --> 01:55.200 So yeah, we are focusing on the the use cases that are interest for us is based on the 01:55.200 --> 02:03.360 ISO 15118-2 and dash 20 standards, which are well basically it's a way as a 02:03.520 --> 02:11.280 San Diego said just before. For the car and the charging station to communicate with the network 02:11.280 --> 02:19.360 product protocol. So it's a TCP over IP protocol, which may involve also TLS. And it does a lot of 02:19.360 --> 02:31.200 things, but basically that's a way to check that the car is authorized to charge and a way to also 02:31.200 --> 02:36.800 check for the billing details, the payment details. So we have different modes of authentication, 02:36.800 --> 02:42.880 either with a simple RFID card that you get to put on the on the charger or something more involved 02:42.880 --> 02:48.080 that is called plugin charge, where you have a contract with an energy provider that is stored 02:48.080 --> 02:53.120 in the car and the car when you plug it will automatically, well the charger will automatically 02:53.120 --> 02:58.400 click check that the contract is valid and will give you access to the charging station. 02:59.040 --> 03:04.880 And it may involve a lot of things online because you have to check the contract with your 03:04.880 --> 03:09.680 energy provider and the charger has to send details to the energy provider as well. 03:10.560 --> 03:18.720 And in ISO dash 20 there is also again lots of things, but one that is of interest for this project 03:18.720 --> 03:23.360 was the ability to discharge, so the car may discharge itself into the grid. 03:23.920 --> 03:31.360 So we've set up this, so we have this defaulting setup for this project, which is quite 03:31.360 --> 03:40.960 classical, we have an embedded board which is made basically of two CPUs, one that runs our red 03:40.960 --> 03:49.040 pesky new XOS and another microcontroller that runs a real time operating system. This one is 03:49.040 --> 03:54.720 in direct contact with the electrical states of the car and is responsible as well 03:54.720 --> 04:03.040 of handling the PWM states that some segmentation just before. We are also as well have module 04:03.040 --> 04:13.600 to handle the energy measurement, something to plug an NFC card reader and it's an internet 04:13.600 --> 04:20.960 connection of course and a small screen for the user interface. So the fact that we have this 04:22.560 --> 04:30.640 complex setup may we may have some security issues and at least that's the we may have some 04:30.640 --> 04:37.840 security issues in the sense that it is a potential large surface of attack because we are 04:37.840 --> 04:42.480 connected to the internet for payments and an application we are connected to the internal 04:42.480 --> 04:48.960 internal network of the car and it's the charging protocols are quite complex so you may have 04:48.960 --> 04:58.880 bugs that could be exploited by attackers. So there are some threats that exist, a simple one may 04:58.880 --> 05:06.160 be that someone find a way to charge itself freely, which is not that bad, but you may also have 05:06.160 --> 05:12.560 a confirmation of network or an electrical risk because you are delivering something that is not 05:12.560 --> 05:22.480 the right current which may, yeah, because the risks. So the design of this project has been initially 05:22.480 --> 05:28.880 thought as with security in mind and we have been using a micro-service framework that is 05:28.880 --> 05:35.760 focusing on security. It comes from Tizen, an operating system that you can find in some 05:35.760 --> 05:43.440 TVs and it being reused also in the automatic grade Linux project. It's basically micro-services 05:44.320 --> 05:50.720 which communicates through remote procedure calls through what we call API verbs and events, 05:50.720 --> 05:59.200 but yeah and the key point is that the different micro-services are isolated one from each 06:00.000 --> 06:06.960 other and they have all their own security context and it's enforced by some feature of the Linux 06:06.960 --> 06:12.560 kernel that is called Linux Security module and especially one that is called smack which could be seen 06:12.560 --> 06:21.280 as an embedded version of the SLE Linux if you know and we also have an applicative permission 06:21.280 --> 06:29.040 database that is called Synagra. So the different micro-services we have for this project 06:29.120 --> 06:36.320 is these different big blocks in rows and green. So we have one that is responsible for the 06:36.320 --> 06:45.200 authentication, one for the display, one to measure energy and one in the middle that is 06:46.000 --> 06:55.760 kind of orchestrates all the different protocols and the logic of the charging protocols and it 06:56.000 --> 07:04.240 is also connected to the powerboard and it will in the end close the relay to the power connector. 07:06.560 --> 07:16.640 And yeah we also I mean focusing on security led us to consider Rust as the primary language of the 07:16.720 --> 07:24.640 project. So every services that I showed here are written in Rust because we found that 07:24.640 --> 07:35.200 it gives us memory safety without compromising performances. So we still have the core part which is 07:35.200 --> 07:41.680 the application framework written in C but we have Rust binding over it but all of the rest is written 07:41.760 --> 07:50.160 in Rust. During the development we had to use some simulators, some car simulators because the 07:50.160 --> 08:00.160 ISO 15118 is not simple to debug. So we have a hardware simulator which costs a lot but we also 08:00.160 --> 08:08.480 developed an open source simulator injector that you can find here that is able to discuss ISO 15118 08:08.480 --> 08:16.320 if you like. So it had been of great help for the project. Yeah so just some screens of the final 08:16.320 --> 08:23.360 product so it reproduced the different steps of the charging sequence so you plug with your car 08:24.240 --> 08:29.200 then it will ask for plug-in charge and if it's not available it will fall back to 08:30.160 --> 08:38.800 it will test the your authentication plug-in charge on all it will fall back to basic charging 08:38.800 --> 08:47.120 and then give you a summary of your charging sequence. So that's it so you can have a look at this 08:47.120 --> 08:55.200 guide page if you like everything is on here so we publish everything under so what most of the 08:55.200 --> 09:04.320 power Apache 2 and the core part is GPL 3 or commercial license with us. Just to give you some 09:06.000 --> 09:12.400 just to give you some words about the challenges we faced so debugging ISO 15118 was not easy 09:12.400 --> 09:18.400 it's not easy it's a quite complex protocol so as I said having the simulators and the 09:18.400 --> 09:29.600 Buggers help a lot either hardware or software. Understanding ISO 15118 PKI I mean the contract 09:29.600 --> 09:35.600 with the energy provider that I thought before is made of certificates and certificates you have 09:35.600 --> 09:43.360 to have a full chain of choice to respect and it involves lots of different actors and it's hard 09:43.360 --> 09:49.680 to understand and this synchronization between the different state machines of charging 09:49.680 --> 09:56.880 sequence is not easy as well so you have slide you have ISO 15118 OCPP and so on so it takes a lot 09:56.880 --> 10:05.760 of time to to implement and debug and in the next steps we would like to add the so ISO dash 20 10:05.760 --> 10:12.080 support to the simulator to our hours of towards the simulator and also have an open source version 10:12.080 --> 10:23.040 of the ISO 15118 logic which is not the case right now and that's it thank you 10:23.280 --> 10:37.120 for the five minutes at their questions yes what is the part in C so the part in C we have 10:40.880 --> 10:47.440 the part in C is what I call the application framework which is still in C and then we have 10:47.600 --> 10:57.840 a binding rest binding over it it's used for this this micro service communications 10:59.360 --> 11:04.240 and the security layer and so on we it's still in C maybe one day we will part it in in 11:04.240 --> 11:14.160 the rest but it's not the case right now and I think for the yeah the simulator part it doesn't it 11:14.800 --> 11:23.920 depend on this framework but it still it still depends on C code that are generated automatically 11:23.920 --> 11:31.920 generated from XML schemas and then we have rest of our rest binding over it and and again 11:31.920 --> 11:38.320 that we that's not the die the the the most direct path we could have a direct rest version 11:38.320 --> 11:44.320 that takes the XML schemas and directly generates rest code that would be a better path I would say 11:44.320 --> 11:53.440 but we we didn't have time to do that yeah yes presumably the thing you just described 11:53.440 --> 11:59.680 you just got very shallow bindings are seen isn't I don't use any significant security risk 11:59.680 --> 12:06.720 score I mean there's no opportunity for human being to foul up that automated chain that's 12:06.720 --> 12:13.520 probably the least of your worries yeah for security if the generation chain is is correct 12:13.520 --> 12:20.000 and valid yes that that could that yeah the question sorry 12:20.000 --> 12:23.920 well the parts you mentioned but not straightforward to do with the eye of the 12:24.960 --> 12:28.960 has had a chance to look at other protocols even though it's not a thing with a hero 12:28.960 --> 12:34.400 just to compare like a child they wanted you for you to see how it is done and if it's better 12:34.560 --> 12:40.960 why do you please read the question for you so yeah the question was did we look at different 12:40.960 --> 12:49.680 protocols between the current the charger except the ISO 15118 I don't think we do because that was 12:49.680 --> 12:55.760 the requirements for the this project of course we we also also do basic charging as some 12:55.760 --> 13:02.800 shadow presented before so the simple one with the the electrical signals but I don't even know 13:02.800 --> 13:08.800 what are the alternative how does this project compare to the average good question so the 13:08.800 --> 13:16.720 question is how does it compare to the average project so average is way more advanced I would say 13:16.720 --> 13:25.680 because it's it's a bigger team but maybe this one is more focused on security that's 13:25.680 --> 13:37.120 what we wanted to to to have and that's what the final customer wants it yes I've been 13:37.120 --> 13:42.000 just giving the dishes is between the hardware simulator and the software simulator or more 13:42.000 --> 13:48.880 particularly used to lead the hardware simulator where you have the software one yes so the 13:49.040 --> 13:56.560 software simulator is about to do you can plug it with an SNAT connection so it can do 13:57.920 --> 14:04.640 the slack negotiation if you are aware of that and it can do the ISO stuck because it's only TCP 14:05.680 --> 14:15.040 TCP connection so it's pure software so it's okay but what it cannot do is play with the charging 14:15.040 --> 14:24.960 state because it's a pure electrical and it cannot you cannot because the hardware part is 14:24.960 --> 14:34.560 able to also use the power line current communication and so on so this cannot be done by software 14:34.640 --> 14:48.880 at least it's it's too complex to do yes last question is this the 14:48.880 --> 14:58.400 question is the hardware available no you cannot no it's not it's not no you cannot buy it directly 14:58.400 --> 15:04.080 but I didn't get the I didn't publish the the bill of materials but you can't find it is 15:04.160 --> 15:11.840 I mean it's quite available hardware that you can find it's a feedback board with quite 15:11.840 --> 15:19.600 common PSC modules and so on so you can find it easily thank you