 So I think we can Jen don't know start with a K Eaman from Pionics So K with a discuss about open hardware and software for EV Chargers. So let's hear More from him now. Thank you Yeah, thank you. Thanks for having me Today I'm going to talk to you about the everest project and how you can use it to build your own vehicle chargers With some hardware designs that I will also present to you First few words about myself I'm Kai I have a background in computer science and robotics and I've been working at Pionics on the everest project for Over two years now Here's a short overview of the talk first. I'm going to give you a rough overview of how electric vehicle charging works This will be followed by an introduction to to everest then I'm going to show you the open hardware designs the yeti and Yakboard and how you can use them to build an AC charger But also how you can kind of abuse them to build a DIY DC charger and in the end I will conclude with a Short how to how you can integrate your own custom hardware into everest to use it as a charger So let's dive right in what's needed to Get a car charging you obviously need some form of connection between the car and the charging station this needs some form of a data link and Power link here in Europe. We have standardized on the CCS type 2 combo plug For DC charging and in other parts of the world you have different physical connectors that can also be electrically different and Speaking of the electrical side of things You can do obviously AC charging you can do it with different voltages For example, if you're in the US, you're probably doing one phase AC charging with 110 volts and here in Europe You do it with up to three phases at 230 volts You can also do DC charging at different voltages and currents here It's totally dependent on what the cars battery actually wants and there are different communication standards Specified for AC and DC charging Let's focus on AC charging first Right now almost every AC charger out there uses a super simple PWM signal to exchange if the car is plugged in and requests power and From the charging station side to encode The amount of current that the car can draw and this PWM signal is transmitted over the control pilot wire in the plug DC charging on the other hand is a bit more complex Here you have the Deanspec 71 to 1 which is mostly used for DC charging right now There's a demo which uses can as its Signaling a player, but that is mainly used in Asia and then there's the iso 1511 8 The iso 1511 8 specifies communication using power line communication It is a communication standard for DC as well as AC charging and You can get a lot more interesting information from the vehicle from the charger side For example things like the state of charge of the battery or how long it will take to charge up to like 80% or 100% The iso 1511 8 especially like the dash 2 has been around for quite a few years now But it hasn't really been used in that many cars and charges Up until now the reason for that is is quite a complex standard and Fork of the iso 1511 8 in form of the Deanspec was available quite early on But things are changing quite quickly here with the introduction of the iso 1511 8 dash 20 and the focus on bidirectional power transfer More interest from manufacturers is coming and we can definitely see that in the industry right now So how do you actually charge a car? I would categorize it broadly in three categories. You have the basic AC charging, you know when you're at home You might have some form of a portable charger that you can just plug into your wall socket Or you have a wall-mounted charger with up to like 11 or even 22 kilowatts and The same kinds of charges you can also find in a more rugged diced Casing in the public which are the slow AC Chargers Nages plug your car in and leave it for a few hours and come back and Then you have the smart AC charging which not a lot of cars support that yet this is using the iso 1511 8 and The I guess most prominent feature here would be plug-and-charge which is simplified Yeah, it's a better or more secure way of Authenticating a charging session with the back-end systems What might be interesting here and what's upcoming is bidirectional AC charging where you can Use your car as a as a battery and return, you know electricity back into the grid Yeah, and then we have DC charging as I've already mentioned with the Dean's back in the iso This is what you typically see near the highway the big fast Chargers But there's also smaller units for home use coming up That you'll make use of the Of the fact that you don't have that many conversion losses if you do DC-DC conversions and then use it maybe you know your car as a buffer battery or as a as a house battery So now that we kind of know what charging is it can't really be that hard can it? but unfortunately There's still lots of issues with either broken charges with software bugs in them or even electric vehicles that have software Bugs that don't get patched in time I mean things are definitely improving there with over-the-air update capabilities, but you still have issues and Yeah, this usually problems here come from the high complexity of the involved standards and Because there's a lot of your companies and manufacturers involved the interoperability between implementations can also be a bit problematic Yeah, now let's have a quick look at the Part of the technical ecosystem that has evolved around EV charging in the last 10 to 15 years You obviously have a lot of you know functionality you have a lot of manufacturers Operators in the for the back end systems involved and lots of protocols and standards you have the electric vehicle side of things You have the charging station you have back-end systems that then have to use roaming protocols to talk to other back-end systems You might have energy management systems involved or even grid operators if you're a big charging parks So as you can see there's a lot of interaction between different actors and this is what makes it quite complex But luckily for you will only focus on the part that I've encircled in red here the Communication between the electric vehicle and the charging station So let's talk how the basic PWM charging Works you have this control pilot signal. It's a simple plus minus 12 volt signal And the car can lower the positive part of the signal By adding resistors to it To signal different states to the charging station If it lowers it to nine volts it says that the car is connected if it lowers it to six volts It says that it wants to charge and that's pretty much it. There's a few other voltages that you can set but Those are the two that you typically only need and since it's a PWM signal The charger can then use the duty cycle to encode the available current Which typically goes between like six and thirty two amps at least here in Europe and then we have the high-level charging this is Using a power line communication on top of this control pilot signal uses the same wire and uses the home plug Green fire standard and how this roughly works is that a logical network between the Charger the electrical vehicles supply equipment and the car is set up using slack then IPv6 addresses are assigned on both sides the car then sends UDP broadcasts and waits for a charger to reply With its IP address and port number Then the car opens a TCP TLS connection to the charger and starts speaking ISO 15118 on that connection and that protocol is an XML based protocol that is then Encoded in a binary representation Called XE which makes it relatively small to transfer Now let's talk about Everest It's a complete software stack for electric vehicle charger is runs on Linux it is a patchy 2.0 license and available on many different hardware platforms It includes a rich collection of modules and all the domains that you need for Charging it contains the charging logic and protocol implementations for the relevant protocols There's hardware drivers for things like charging hardware, but also power meters There's an energy management included authorization system and simulation facilities to actually test all of this It's built with a modular architecture with modules that communicate with each other over MQTT and There's even a graphical setup user interface that you can see here To configure the connections between these modules You can also use this configuration interface to set up the energy management as well and And now I would like to dive a little bit deeper into how the framework behind Everest works As I've already mentioned, it's a modular architecture You can kind of think of it like a microservices architecture where each module runs in a separate Linux process And these modules can expose interfaces on this MQTT bus and other modules can then require these interfaces and call Functions on the other module or receive data that they are subscribed to Let's visualize that very quickly That's a super we have two modules module a and module b and Module a provides an interface that I would call charger this interface Defines a command the set max current and the variable the intercharged Module b can then require this interface and if you then connect these modules in a config file together module b can call the commands of module a and Get if it subscribes to the energy charged variable it will get that The value of that Yeah variable over MQTT This all happens Completely transparent to the module the module doesn't even know that MQTT is involved Yeah, and this is kind of how it looks like in the Yeah configuration files. We have the charger yaml on the left side. This is the interface that Describes this command and the variable then we have the manifest file of module a where we say that it provides this discharge interface Then the manifest of module B Says that it requires the interface and it requires exactly one kind of module that provides this interface And then on the right we have a configuration file that sets up the connection between these modules and That's not where it stops. We have other features things like software and hardware in the loop simulation and we implement lots of Relevant protocols things like OCP P 1.6 is very much completely implemented and working hard with On the implementation of 2.0.1 and also on the draft of the 2.1. That's just been like released a few days ago Then we have ISO 15.118 with AC and DC support the inspect support for the PWM charging obviously yeah, we have Support for mod bus based power meter the Sunspec devices and other things that can talk MQ2T And if you want to write your own modules, we have multiple language bindings for C++ for for Python and for JavaScript One of the goals behind Everest was always that it's easily portable to new hardware Which means that the interfaces are you know relatively small I would say that you have to implement and Porting to a new hardware usually means that you need Some form of device driver that can get the control pilot signal events and generate the PWM signal and as a minimum drive the relays that Yeah make Actually electricity flow to the car Everything else is More or less optional you you don't need a power meter if you don't need it if you don't care about You know what your RCD reports? I mean you need it electrically But you don't need to write a driver for it if you don't if you're not interested in the leakage currents And if you don't want to do any authentication, you don't need AFLE readers or any form of human interface device there's also a few deeply integrated hardware reference designs already available the Pionics the AT in the open hardware is based around the Raspberry Pi 4 Compute module. There's also hardware from Texas Instruments and Phytec based on the AM6 to X and Charge by it has a controller. I think it's called the Terragon controller That's I think based on an MX-NXP controller it's Mostly like the OS support is also quite good. I mean we have layers that work with at least Dunfell and Kirkstone Might have also gotten it to work already on on FUD which is ancient by now I think so let's talk about the open hardware First of all the most important thing you can find the designs here on Github It's released under the CERN open hardware license version 2 and the idea behind these designs was always to be Yeah, as developer friendly as possible So the designs are obviously not optimized for cost but for features So you can play around do a lot of interesting things with it It's been designed in Keycard 6 and there's also some case design files available Now if you want to build some form of an AC charger You're quite lucky that it's quite easy because you don't need to Build a battery charger where you can actually have to talk to the battery and Set correct voltage and things like that You pretty much just have to build a smart relay Yeah optionally No, not not optionally, but new optionally you can add a power meter and you need to add an RCD for safety and a microcontroller to create the PWM states and and read them back and If you want to do some more advanced things You can add a Linux board on top. You can see this Yeti 22 kilowatt AC free-phase power board that we've designed it comes with Comes with a lot of features like I already mentioned it does control pilot signal generation It can do the sync signal sampling back In sync with this PWM Has an onboard relay for free-phase power switching We have also free-phase power metering up to eight kilohertz so you can measure voltages currents power frequency of all the phases plus the neutral There's an RCD module that gives you the measured leakage current back for telemetry which can be quite interesting because some cars Actually produce a considerable amount of leakage Then we added a 10 pin connector with a UART That does the connection to the Yuck high-level control board There's connections to an SPI LCD If you just want to run the Yeti board, it's also possible and external GPIOs and Obviously, it has a onboard power supply. We can run it from 110 volts to 230 volts the microcontroller on board is an STM32 and The firmware for that is also publicly available under the FHG 2.0 license It obviously controls all the devices on this Yeti board and has electrical safety relevant code encapsulated and Does all the communication with Everest over a protocol using protobuf over the UART Here's how you can use this Yeti board And you can either use it as a standalone charger or as the power path for a smart charger And you can implement some form of automatic switching if you detect that your high-level Linux board fails You can still go back to the standalone charger mode if you want to provide free charging for example, if You want to use it as a standalone charger. It's quite easy. You just plug it in and it works and it can then use the UART to observe the charging session you see the events that are called and You have some limited control over the session. You can pause it. You can resume it But you can also put the firmware in the low-level control mode with a simple UART command and here You then have to provide all the charging logic externally only the basic state machine remains in the microcontroller and You can set the PWM signal then from an external board and read back these events and this is the mode we use in Everest to enable things like high-level charging using the ISO and the Dinspec and To make this work. We've designed this high-level control board that yeah runs on the notes it has a Like I already mentioned the Raspberry Pi computer module 4 on board this 10-pin connector for connection of the Yeti There's a real-time clock with a backup battery included power line communication modem for high-level communication with the car For convenience we added a connector for popular RFID modules. We have You know canvas, ethernet, USB ports, external GPUs, yeah lots of things And here's pretty much how you would put it together You put a type 2 connector on the left side plug it into the Yeti board stack the Yakon board and Just wire it up with a mains free-phase power and you're pretty much Good to go And if you want to do something a little bit more interesting if you Paid attention the last couple of minutes. You probably noticed that the Yak comes Already prepared with everything that you need for for DC communication because the DC communication just uses the power line communication, so we kind of repurpose these both boards to build our own DIY DC charger you can see diagram here where we use the Yak connected via a can to a power supply and My mod was to an isolation monitor and use the Yeti's relays to switch some DC contactors and This is how it looks like in reality like on the left side You see an image where on the top you have basically the AC input side and the DC contactors With the Yeti and the Yak board and on the bottom you have a like 19 inch 30 kilowatt DC power supply that we've gotten for cheap off the internet and Yeah on the right you can see the the Yeti board being used to switch the DC contactors Obviously, you don't need to use a Yeti board, but I mean you just have a few of them lying around and I mean this is probably the least exciting photo in this whole presentation because successful charging isn't really that easily photographed But you just have to trust me that we've already gotten it to work with with a scooter and Yak and Yeah, it works already quite well and we've been we're gonna be working on that a little bit more over the coming Weeks and months and give an update on that as well So now if you want to build your own board support package for an Everest power charger I give you a quick example Using the the Yeti driver as as the base you can see the whole I think manifest of the Yeti driver and Don't really have to pay too much attention to the top part of the config But only what it provides in the bottom it provides power meter because it's already on board But it also provides this board support AC interface and this is literally the only thing that you need to implement to get a To get a AC charger working with Everest You know short overview the condensed version of the interface you literally just have to implement a Very small set of commands You have to you know return the hardware capabilities with a minimum maximum current that you support and the number of phases You have to be able to enable and disable the charger We need obviously need PWM control. So we need to set the duty cycle and turn it off and on again We need some form of signal to signal to the charger that it is now allowed to switch the relays on and If you have a detachable cable on your charging Station you also have to return the current carrying capacity of the cable and And then there's only a few variables the most important of these is the events variable Well, you just have to report back the control pilot events things like that the car has plugged in that the car has requested power That the car has requested to stop power and the car has unplugged which you can directly infer from the voltages that you read on the control pilot and if you have now implemented your board support package driver and You can then hook it up with our You know web-based tool to Yeah, pretty much connected to everything else we now start with the the Yeti driver here on on the bottom and We add what we call the EVSE manager to it. This is a very central module in in Everest that represents a Charging connector and has all the charging logic and session management included in it and a few other things and this module is what we use to orchestrate the access to this one connector, so It's more or less like owned by the EVSE manager Then that you can actually have some energy flowing through the system. We need to add an energy manager which Is responsible for the distribution of the available power With one driver and one connector. This is not particularly exciting, but if you have multiple of them connected and You can't use all of them at You know full capacity or you would blow your fuse to To the grid then you can use this energy management system to set certain hardware limitations But you can also use it to get up to OCPP for example and use OCPP's smart charging features to set certain profiles that either Yeah, are for the whole station or Just for this one charging charging session Optionally, you can add an IC5118 Protocol stack and the stack module. Here you obviously need a driver for your power line communication Modem, but since there's not too many companies around that make these I Think the linux driver support is already quite decent here And they just expose an ethernet device that you can just use with these stacks and They do all the work here then and If you then want to do it as a public charging station You add some authorization on top of it in form of an RFID reader It just read your RFID card and this authorization module Is then connected to the EVC manager and validates if the card was valid It can also connect to things like OCPP To do authentication there and and it you know validates all the requests and reports back to the EVC manager All right, if that was you know interesting for you Here's how you can get involved you can check out the code on on github You can also look at the hardware designs and microcontroller firmware that you can also find on github We have a mailing list where we try to be relatively Responsive and you can ask all sorts of questions related to ever is there We have a quick start guide and some tutorials on how you can set up Simulation how you can add OCPP to ever is if you want to develop new modules and more We then also have a Technical steering committee meeting Once a month every fourth Thursday of the month where we talk about yeah, what what we did in the last month and you know Talk about what went into our new monthly releases We try to adhere to a roughly monthly release schedule right now and you can't make it to that To that meeting the recordings are available on YouTube relatively shortly afterwards and If you want to get really involved you can join our developer meetings That happened every Tuesday between 3 and 4 p.m. Central European summertime and the meeting for that you can also find on our mailing list Thank you very much. All right. We thank you guy. We've got time for questions. So if you have any questions feel free. Yeah Hey, thanks for the talk. It's a really cool project I want to ask like there's a lot of certifications involved in building it hard to have each other Is there any products that have went through certification that are using the open source hardware? We have one product right now that It's more like a business to business product like a test equipment that you can use to Validate ISO 15118 with that went through CE certification at least and Yeah, we're working. I'm not sure about the hardware designs pretty sure the the chargepad controller This is widely deployed not not with ever is widely deployed, but it is available with ever is from chargepad And this is obviously certified because it's running in commercial installations already Not sure about the TI fighter card wear, but Probably Certifiable as well Thank you Yeah, thanks from from my side as well There are at least two other open source hardware projects focusing on EV charges. There's one called open EV SE and I've seen one on the beagle board booth together with seed studio. Can you state how the differences between these projects are and if you Collaborate somehow or use similar components? I'm not completely familiar with with their hardware designs So I can't say too much about them but what differentiates us I'd say is that we you know focus on Not making a small like microcontroller based easy AC charger, but We've already built this with like DC charging and more complex things in mind Where you just need a little bit more compute power pretty sure you can do all of this in a microcontroller as well But for some applications, it's it's much easier to to use a Linux based board And I think most of the other open hardware designs I've seen focused on a microcontroller based approach and this is in my opinion a bit more more extendable But yeah, there should definitely be a little bit more collaboration. Maybe I'll drop by later and say hello and ask it Okay, thanks Hi, and thank you about the ISO 15118 Implementation is still based on Java rise V2G or you made some we actually have three stacks Available right now. One of the options is the rise V2G with Java Then we have the the Joseph community edition as a back end available, but we also have a module that has been donated to us by charge by it which is written in C++ and C and uses Open V2G as its back end But as a fourth option, we are also working on a complete own implementation of the ISO 15118 especially the dash 2 but then also the dash 20 Just to have it in a more Compatible license because the the open V2G is LGPL3, which is problematic for some vendors that want to do Want to work with it some of them, you know, they read GPL and they run away sometimes So we want to write an implementation of our own or actually are working on implementation on our own That will be a patchy 2.0 license But yeah, these are the three stacks available right now and they've had they've been quite well tested already on Different testing events and work relatively well, I'd say Okay, thank you Hi, thanks for the presentation. I get a question in regards to the control pilot It's embedded in some of the module that you presented on the presentation Yeah, what we actually do is we do the whole control pilot Reading and generation we do this in the microcontroller firmware like we read out the Yeah, we read out the positive part drop voltage drop of the of the car So we we read out that the car is connected and it wants to request power But we also generate the PWM signal in the microcontroller But there's not at least one board that we're running on That does all of that pretty much in in Linux and that also works relatively well, I'd say So I hope that Was your question No, actually I was asking about the modules that you presented and on the on the everest project whether Who's actually responsible for the which of the module is responsible for generating and signaling the PWM to the car Well, it's it's the the Yeti driver Which is responsible for doing like the high-level signaling to the car But the microcontroller code in the microcontroller on the Yeti board is then Responsible to actually set the PWM to its correct duty cycle and to read back the events there Okay, and yet another question about the Actually referring to the to the ISO 15118 What's the rationale about? Having multiple options for the ISO 15118 as a module. It's mostly Getting results quickly as we we started this project like two and a half Years ago and like then we we personally didn't have anything so we tried to find other Implementations out there so we started with the rice V2g worked a little bit with that saw, you know It's drawbacks things like Java and things like that Then last year the Joseph communication was Released, but then we were already working on our own solution But we are also interested to see how that works and it's not that he's not that hard to Integrate it within every especially since we have like Python module support. It's not that hard and That the third stack that was actually donated to the project from Charge by it as a contributor So they had that stack. It was battle tested over the last couple of years supports the Dean's break as well and so integrated it and Are quite happy with it right now But we're still working on our own solution because we think we can do it maybe a little bit More integrated I think we have time for our last question Okay. Thank you guys. So it's now we're gonna have a short break until 11 a.m. So it's time for coffee. Thanks. Thanks again