 which is Marco and Cornelius who are talking about how to charge your electric car with the open-source way. So over to you. Thanks. Thanks a lot. Yeah, we want to show you about EV charging. It sounds easy, so charging a car shouldn't be too complicated and is it really that easy? Let's dive into it. That's a really, really huge ecosystem, what kind of evolved over the 10 years. So even before there have been a lot of cars. And it's from the car, the charging station, a lot of different cloud operations. There's a lot of protocols. I don't want to dive into all of that. We're just diving into that, say, car versus charger versus a bit of more. And yeah, let's digest that. What's all included in there? And you basically start with the charging station. There's a controller, let's say, Raspberry Pi. There's some power electronics and there's a car connected. Data link and power link. So yeah, power. There could be different versions of that. AC voltage is different in every region. Number of phases is different. The amps are different. You could also go DC, you can go inductive charging. So a lot of ways of transferring the power. On top of that, you also have a data link. There's a physical layer, how you can transfer that information between car and charger. And there's a really dumb version where you just have a PWM signal, which is often used, but there's also way more smart stuff where you exchange in kind of XML messages in a really, really weird format. And this is just an extract of the different protocols you have. And this is just one link. If you're extending that, wait, one second. And last layer of complexity just between car and chargers is the plug. I mean, in Europe, we are kind of standardized to this type two or type two combo with DC pins. But there's another link from charging station to cloud. And also there you have a lot of different protocols. Open charge point protocol is one we just often use, but some legacy stations are using something else or doing their own stuff. And also here, a big protocol stack. The fun fact is, most stations have settled on this OCPP. So you think, hey, it's dominant. We're all saved. But there are so many different dialects like everyone speaks the different versions of that protocol. At the end of the day, you have to really test each cloud with each charger and it's a big nightmare. But it doesn't end there. So one cloud has to talk to another cloud to do roaming. So if you have a payment provider from company A and the charging station in front of you from company B, how do they communicate with each other? Yeah. And then ideally, you just want to plug in your car and it charges. So you have to put a lot of public infrastructure on top of that to get that running. Looks like a nightmare and yet it's not running yet. And it should be there since 2014 really soon. And it's not yet out in a broad distribution. So next level, you maybe want to talk to humans. So you have maybe a display, maybe an FID reader. And there's kind of no standards at all. Everyone is doing something different there. And yeah, then you have maybe other charging stations. Left, right. You have electric grid where you want to drain power from. Not to here. Again, a lot of different ways how you want to communicate with your local solar stations. A lot of different protocols. And it's really nightmare. If you ask any electrician of can I get a charging station which speaks to my solar and I just charging what's left over, it's barely able to buy that because nothing works together. And yeah, if we then go to the big electricity grid, it's even worse because they're just starting yet to get some way of exchanging information about electricity. So what's the current pricing? What's the future pricing? Can I get basically only pay the current stock market price for the energy? Not something like an average. And can I maybe disable my charger if there's a local shortage of transmission? So even if the stock price for that electricity is really low, it could be there's a bottleneck in your local grid in your street. So you could get paid for that if there would be a protocol to manage that. So in total, with a lot of links in the charging stations, there's too many standards, too many dialects. It's ever growing. Nothing really works. You have really pure user experience. It's really, really expensive to build such charging stations. Yeah, because of all that reasons. And in the end, I think it's not good for the goal of electrifying all cars and basically get rid of all carbon exhausts in the entire industry. What we have to do for saving the boiling planet. So how can we fix that? We could invent a new standard, right? One standard who fits it all. But then we're ending up in that situation. Then we just added another standard to that nightmare. The other ones won't go away. So we think that won't work. We think you can do that by open source. But just basically implementing all the standards in one common library. Maybe you remember the browser was. Nothing was compatible 10, 20 years ago. And you have to test every website against every browser. It wasn't fixed by improving HTML. It was fixed by getting less engines and doing them open source. And yeah, we adjust the tiny puzzle piece in an even bigger ecosystem. We're part of the Linux Foundation Energy, which tries to build a software stack for the digitalization of a green electric grid. And there's so much more to it. And we just scratched on the car charging part, which will be big in the future. But again, it's only a tiny fraction of what we have to do. And let me hand over to Cornelius. So how we want to fix that? Yeah, so let's have a look at whatever it actually is and how we're trying to solve this mess and improve it. So we're basically writing a complete operating system for AB charges. That provides all the functionality needed for both the smart home use case. So basically for AC charges at home, where you want to do solar charging and all that stuff, but also for commercial fast charges that you find on the highway. So we're basically trying to implement everything that's between the car and the cloud. The average stack runs on basically any tiny embedded Linux. And the aim is to support as many hardware configurations as possible. And it comes in a commercial friendly license. So it's all Apache 2 license. And the whole idea is that it's not good for the ecosystem if everybody reinvents the wheel. That's the current situation. Everybody reimplements the same protocols. But what we want to do is provide an open source layer that just everybody can use to improve compatibility. And then all the charging manufacturers can focus basically all their energy on providing just a few unique features for their product on top of the open source stack. So how is Everest built up on the inside? So it's a very modular architecture. It's kind of a microservice architecture where each module runs as a separate Linux process. And these modules can expose interfaces on an MQTT bus. And modules can also require interfaces from another module. And there's a config file to connect those. We will see that in a minute. And then modules can communicate. So one interesting topic is we'll see that later how that helps is that these modules also can run on different computers. Since it's MQTT, they can also communicate over the network with each other. And there's a whole framework around it which we call the Everest framework that basically does all the MQTT abstraction and takes care of starting and stopping modules and stuff like that. So one central thing is the configuration file in Everest. So it's basically a JSON file where you describe which modules to load. And it kind of represents the hardware. So the image is not meant to be readable. It's just showing like what modules are typically there. So the idea is if you build a wallbox, for example, with two outlets to charge two cars, you basically just load the charging modules twice. And then maybe you want cloud connectivity to back end. So you load the OCPP module. And maybe you have some energy management. So you load some energy management modules. And then you basically configure your product. And this is super simple. There's even a graphical tool to do that now. So it's a web tool where you can configure the whole software stack. You can basically see on the left side all the available modules that are there. You can just drag and drop them, configure the individual modules and also basically create that configuration file by drawing lines between the modules for the connection. So that's super simple. And then once you're done, you can basically hit run. And it will start Everest. And you have a charging station up and running. Configured for your hardware. Yeah. What are the typical modules that are inside? So most important, of course, is kind of the charging core. So there's one module which we call the EVSE manager. That's essentially the central module that controls one charging port to one car. It also owns the charging station. So it basically knows when it starts, knows when it ends. It knows everything in between, like how many kilowatt hours have been charged and all that. And it also manages all the interaction between the different norms. So Marco briefly talked about this. So there's kind of a basic signaling which is just a PWM signal on the control pilot wire. But then they found that it's not enough to just have a PWM signal. So they put an Ethernet link on top of that by using power line Ethernet over the same wire. Which means there's also the so-called high-level communication with ISO 15118 or Deanspec. Which is essentially a protocol based on XML where you can talk with the car. And it gives you more details such as how many kilowatt hours are required by the car to fulfill its charging target and how big is the battery. And there's a lot of more information that you can get out of the car while charging. And that stack is kind of a separate module which you can load to support that. Or you can just leave it out of the configuration and then you have just a basic AC charger. For DC, you always need that because DC is completely based on ISO and Deanspec protocols. Underneath these charging core modules, there's a couple of modules which basically represent the hardware abstraction layer. We try to make it super easy to port it to new hardware. There's basically just a few things needed. There's one module needed for the control pilot signal fee. I think that fee is all the PWM generation. You just need to write a small driver that outputs the PWM at the correct duty cycle and stuff like that. And then there's hardware abstraction for things like power meters if you want to measure how much you charge for RFID readers. Basically for the power line layer, there's also a slack driver. But if you use commonly available hardware, there are good chances that there is already a hardware driver in Everest for that. Looking at the other side, not so much to the car but to the cloud for basically payment stuff, we provide an OCPP 1.6 JSON implementation. And we took a lot of work to actually make it standard compliant and not just our dialect of it. We verified this was as many commercial backends as possible and also with the official protocol testing tool from the open charge alliance who supports the standard. And I think we're the only implementation of OCPP that actually supports all the optional profiles, even with smart charging and all the security extensions which typically no one implements, even not in the commercial stuff. So I think we're the most complete and also we're the only really working open source implementation of that. One of my favorites in Everest is actually the energy management. So you can use the same mechanisms that we just showed for configuring the charging station, basically drawing these, like track and dropping these modules and connecting them, this time not to represent the internals of the charging station but you can also use it to basically represent the externals of the charging stations or whole power distribution G of the house. So on the left side you see this label fuse 40 amps for example that's kind of the grid connection point where the power enters where the house is connected to the power grid. You can basically load a module for that, that's typically just a fuse so Everest needs to know what the fuse there is but you can also connect like side modules to it for example a power meter so that Everest knows what the power consumption at the grid connection point is and if you for example have a electricity contract that has variable prices for each hour that's at least in Germany there are no three providers available for that you can also feed that in so Everest knows in the end okay at that point I'm getting power it's that much and it comes at that price and from there basically you can model all your like fuse power distribution tree of the house and it can be basically any arbitrary tree I just made some example here with the 16 amps fuse on top and two chargers that are also 16 amps each so you can already see that you cannot operate both of them at full power at the same time and on the right side you see there are cars connected to these charging stations and typically every car has a different goal so for example the first one just needs to leave as soon as possible so we want to charge as much as we can the second one for example needs to leave 7 a.m. next morning and wants to charge as cheap as possible until then and that's already relatively complex because you see on the bottom we also connected like solar panels here in the energy tree and it comes with a solar forecast for the next couple of hours so if you want to leave 7 a.m. next morning an optimal solution might be that you're charging for example this afternoon between 2 p.m. and 4 p.m. because you know that the sun will be shining and there will be excess power available and maybe the remaining energy that your car needs will be charged in the night between 2 a.m. and 4 p.m. because there your price indications show it's going to be cheap but since you know from the car how many kilowatt hours it needs you can pre-plan that ahead and make sure that it's actually full at 7 a.m. the morning and this for example is the use case that actually no charging stations currently really can do and yeah the other charging goal such as I only want to charge excess solar power that otherwise would be wasted and I don't care when it actually is full and there's already also cars that are connected to the charging stations that are already fully charged but still block one charging station so once we have all that information available we're basically running a global optimizer over that whole tree that makes sure that all the charging goals of the individual cars are fulfilled as good as possible while at the same time all the restrictions from fuses are also met and we will not blow any of the fuses at any time and we can control this a lot faster than the fuses are so we can make sure that actually that always works the whole energy management gets a lot more interesting when chart when the cars are able to charge bidirectionally so so that we can draw power from the cars back into the grid because then you can do a whole lot more optimizations for example the one car that uses the excess solar energy but doesn't have like a fixed time to leave can be discharged to charge the car on the top who needs to leave as soon as possible to fulfill that target because we know that when that car is already gone we can recharge the other one with the solar power again so then the whole optimizer gets a lot more complicated that part is actually under heavy development and we'll have a small workshop on that tomorrow morning at 11 a.m. so feel free to drop by at our camp yeah what else do we have we have a small display app so for all chargers that actually have a local display there's the flutter based app that we will also basically port to android and ios in the future but right now it's only for the local display what's interesting as well we have a complete software in the loop simulation so the hardware abstraction layer I was talking earlier about for each of the hardware drivers there's also a software simulation module available so that basically you can run the whole ever stack just on your laptop without any charging station or a car and you can also load a simulated car module that you can attach to those simulated charging station modules and you can run full charging station sessions including iso 1511 aid support and basically develop averse and run simulations and can do fully automatic testing for example yeah we do use a lot of not read during development since it's based on mqtt it's actually fairly easy to drop in uh not read and build some development you eyes to visualize something or add some buttons to do something in the meantime so that's a very uh nice tool to use with averse um yeah and basically that's whatever is what is about yeah so and again feel free to join us on the github and feel free to come to our camp uh we're say here some meters was it what some meters north from here um we have a couple of cars I think you can't miss it um we'll do the energy management workshop tomorrow and we're basically here the entire time and we're also meeting once a week we do all our developments meetings publicly once a month we have like a summary what's new what's going on you can join and yeah if you have any questions feel free to ask uh do we have any questions at the moment well I've got one is this going to lead to more affordable electric car chargers as an owner myself I think it will lead to stuff better working and cheaper charging stations because at the moment I don't know the the company spending a lot of money on engineering again and again again the same stuff sorry they don't have to do it yeah any other questions actually out of interest how many people here own an eb at the moment oh a fair few and how many of you will buy next mch anyone planning to buy one between next mch or you're all sticking to I don't know I don't want to think about how much diesel is going to cost by that okay anyway brilliant thank you very much indeed thank you