 Hello everybody. Welcome to our talk about Everest, I am Pete. This is Kai. We are both software developers at the company Pionix who initiated the Everest project. And yeah, we are really excited to present it here. So Everest is in a software stack for charging infrastructure for electric vehicles. But before we dig deeper into whatever is this and what it can do, I would like you to give you a quick introduction into how to charge, how to technically charge a car. And you should think charging a car is easy, right? You just plug it in, plug it in on your vehicle side, on your charging station side, and it should just start to charge. But unfortunately this isn't always the case. Let's have a look on how charging, how easy charging really is. So what you can see here is an overview of the ecosystem of the charging infrastructure that evolved over the last 10 to 15 years, I'd say. So there's a lot of players around, a lot of charging station manufacturers, cloud operators, charge point manufacturers and stuff like that. And today we're going to focus on this little box here, which basically covers mainly the communication that the charging station has to maintain or for which it is responsible for. So you can see what is necessary to build the charging station and what kind of communication is necessary for that. So on the following slides I will show you a little bit about the protocols that you can see here to show you what a charger needs to do or what you need to do when you want to build a charger. So let's dive into it. What do you need to charge your car? You basically need a charging station which usually consists of a control unit, so a small embedded Linux device for example and some power electronic paths. And then of course you need the car and you establish a data link and a power link. And speaking of power, there can be different types of power. You can do AC charging with different voltage levels. You can charge on one, three or even two phases and you can charge with different currents. You can also do DC charging which is usually a lot faster than AC charging and usually also more expensive because of the bigger power electronics part and stuff like that, but you can also think about inductive charging. So there are many different ways that you can use to charge your electric vehicle, many different types that you can use there. And where it gets really interesting is when you think about the data link, you use this data link basically to communicate between the charger and your car. And the communication is not the same for AC and DC charging for example and there are also like different communication standards for AC charging for DC charging and for different types of AC and DC charging. So when we start with AC charging, you usually use this kind of plug over here, the type two plug and it's a really simple pulse with modulation that you use there to communicate from the charging station to your electric vehicle. And you exchange like a minimum data using that pulse with modulation, you exchange the states of your vehicle and your charger, the capacity of the charging cable and the maximum amount of current that is allowed to charge for example. So this basically covers AC charging. It is controlled via this control pilot plug, so you just have one wire for that. And when we talk about DC charging, things get a little bit more complicated. You have different kind of standards for that. The Deanspec 7121 for example, it uses power line communication as well as the ISO 15118. There's also the Shadi mode standard, which is mainly used in Asia. And I want to highlight the ISO 15118 a little bit. It is quite a new standard, quite new means I think it's from 2014 and not really implemented for most of the vehicles and most of the chargers right now. But it defines a lot of more information that is exchanged between the charger and your electric vehicle. Also some really useful information like the state of charge, which is not exchanged when you use this basic AC communication. But you can imagine that you can use the state of charge of your electric vehicle for a lot of stuff. When you think about energy management, you might want to know how full the battery of your car is to like manage the power that you provide by your charger and stuff like that. And there are also a lot of security considerations that are specified in this ISO 15118. You have to implement it on both sides. So it's a specification for the charger and the car, but it's not really implemented by a lot of vehicles and a lot of chargers right now. And the reason for it is that it is a standard that is quite complex. There are a lot of different versions of it. And there's a lot of room for interpretations and every car manufacturer and every charging station manufacturer has to implement this standard. And when all of them do it in different ways, this leads to incompatibilities and to bad user experience because oftentimes charging often does just work using this ISO 15118. And this is why many chargers stick to the Deanspec 7121 for example for DC charging or the the ISC 61851. And the ISO 15118 is not only for DC charging, it's for AC and DC charging. Right. So this was like mainly the communication between the charger and your electric vehicle. But there's another important link when you think about public charging infrastructure, you need some cloud communication from your charger to the cloud. You want to monitor your charger. You want to transmit transaction related data, for example, for payment and bidding services and stuff like that. And the protocol that is mainly used for this communication is the open charge point protocol, which is an application layer protocol on top of WebSocket. And it is used for monitoring, for service, for remote control of your charging station. For remote starts, for example, when you stand in front of a charging station and you want to use your mobile phone or the app of your mobility service provider to start the transaction. What you talk to the backend system there is OCPP when you start your transaction, for example. It's also out there in different versions. So currently in mostly used with version 1.6, but 2.0 is already published. 2.0 covers a lot of the stuff that is specified in the ISO 15118. But this is also the reason why it is not used in many charges and vehicles right now, because if no one has implemented the ISO 15118 stuff, you don't need 2.0 at the moment. And 1.6 is enough for what the charges and vehicles can right now. Unfortunately, it doesn't really end here. There is also cloud communication happening between different crowds if you want to charge your car and your operator does not know your contract or your identifier, you have to establish some communication between clouds so that you can also charge if your operator does not know your ID tag, for example. So for interoperability. And also the OCPP standard is also quite or has also quite some room for interpretations. Every charging station manufacturer has to implement it. There are different yeah back end systems out there with their own implementations. And it leads to the fact that many back end systems have to implement like special solutions for special charges or they have to they have to test with every charger, although it's the same protocol. But there's so much room and yeah, so many different dialects out there. And that makes it really hard. But on top of that, there is a feature which is called plug and charge. This is also covered in OCPP 2.0 and the ISO 15118, which should be there for a while. So people are saying it will be here in two years ever since, since 2014. But still no one's really using it. And that leads to the fact that there is mechanisms out there like auto charge that just uses the MAC address of your vehicle to authenticate. So this plug and charge feature is usually used for authentication so that you don't need to use your mobile app anymore. And you don't need to swipe a card at the charging station to tell who you are, but your vehicle does it. And yeah, things like auto charge makes it a little bit easier. It uses your MAC address of your vehicle. If it is static, it is useful. Oftentimes it just changes so it doesn't work for all of the cars. So it's really, really complex and really a lot of standards around. What else is really important right now, but especially also in the future will be to integrate your charging infrastructure with your local energy management system or your local system, your local grid connection point. Imagine you want to use your solar power plant that you have at home and you probably want to charge when the sun is shining, for example, then you want to control the power of your charging station externally. The same applies for bigger charging infrastructures with many, many charging points where you have a limited grid connection point and limited capacity. And you want to you want to balance the amount of power that goes into your charging station. So for that you need some kind of interface, some kind of communication. There are different interfaces for that out there. There is the Modbus protocol, for example, which is used by some of the charging stations. There's Sunspec. There's also something like EE Bus and it's not really unified. And when you want to build such a charger, you basically have to implement all of them to be compatible with different energy management systems that are usually part of the installations, at least for bigger car parks, for example, or for bigger charging infrastructures, usually have one external controller that controls the power of all of them. But of course you need an interface for that. And there's more standards, more protocols. And the same applies also for the grid integration. When you do not think about your local grid connection point, but about the whole grid, it gets more and more important that we integrate the electric vehicles smartly into that grid. And many people see it as a burden that so many electric vehicles are on the street right now and they are all connected to the grid. But we actually see it as a chance because I mean electric vehicles are flexible electrical consumers. You can control the power that they consume or maybe in the future you can even discharge them to support your grid. But of course you need some kind of communication for that in order to make it possible for the grid operator to discharge the vehicle of your car or the battery of your car or to lower the charging power to have a more stable grid. And you can use electric vehicles for that, definitely. So yeah, to sum it up, it's a bit of a mess. There's no defect to standard. There are many, many links, many, many standards, many, many dialects out there. And yeah, it's even growing. There will be vehicle to grid. When you want to discharge the battery of your car to support your local system in the future, there will be integration to the grid system, which will get more and more important. Right now we have a high afford rate for user experience. We have really expensive and slow development of charging infrastructures because when everything started, the charging station was really just there to charge your car, but right now there's more requirements. Charging stations have to fulfill, integrate with different systems, different packing systems, stuff like that. And that is really a big problem. And every charging station manufacturer and also every electric vehicle supplier has to implement the same stuff and there's really a lot out there. So how can we fix it? We can definitely not fix it by adding more standards. But what we want to do with Everest is we want to provide a holistic reference implementation as a de facto standard for charging stations for electric vehicles. And this implementation should cover all of the communication that I just showed you, which is a lot. And this is basically what Everest is. Of course, we are just a little piece of a bigger puzzle. We are, as the Everest project, part of the Linux Foundation Energy since 2021. And our goal is that Everest is used by a broad community, especially in the last months. The project has really taken off with many projects and partnerships have recently launched. It is currently adopted by some charging station manufacturers like Mahler and FuTech. There are some component suppliers like Chargebyte, which will use Everest in the future. And we'll also spend a lot of their code base, which was closed source in the past. And we will integrate this into Everest as well. And we are evaluating with Texas Instruments and PhiTech how to use Everest with their products and also first project with universities and research institutes have kicked off. And of course, also private enthusiasts and hackers are welcome to contribute and to add new features, tests and bugs and stuff like that. And now Kai will go on and explain to you what Everest really is and how it works. All right, yeah. Like Pete just told you, I'm going to give you like a little overview of what Everest is on the inside. So what we are aiming to do is basically write a complete operating system for electric vehicle chargers, which will provide all the functionality that you need to build charging stations. For example, for a smart home use case where you have a small AC charger at home and then you might want to do some solar integration there. But we will also be so flexible that the same solution also runs well on commercial DC fast chargers like you find them on basically every highway nowadays. This means that we have to pretty much implement everything that runs between the car and the cloud and do all of this. So it runs on pretty much any tiny embedded Linux platform out there. The aim is to support as many different hardware platforms as possible. And as Pete just teased a little bit, it's already running on over like a handful of different hardware platforms at the moment and more of them are coming. All of this is released with a very commercial friendly open source license, the Apache 2.0 license. And yeah, the basic idea is that it's not good for the whole ecosystem that everybody has to reinvent the wheel and reimplement all these protocols all the time. So basically the boring part, what you actually want to do if you want to build a charging station is you want to build on a good foundation and then maybe add some unique features on top of that. And that is basically what we are providing with Everest. So how is it built up on the inside? It's a very modular architecture. So it's kind of like a microservices architecture. We have modules that all run as individual Linux processors. And these modules can then expose interfaces on an MQTT bus. They can also require interfaces of other modules. And we use a config file, like a central module config file to configure the dependencies of these modules and how they are connected. But you'll see that in a minute. The beauty of using MQTT for the inter-process communication is also that you can quite trivially run these modules on different computers and just let them communicate or network, which might get interesting if you do things like energy management, where this might be even not located in the same unit of your charger. So we build a whole framework around this, which we call the Everest framework. And this does all the MQTT abstraction and takes care of starting, stopping modules, and provides a lot of convenience functionality that you need, like logging, etc. A central thing is this module config file. This is a JSON file that you can use to define which modules you want to load. And it's kind of like a representation of the hardware. This image here isn't really meant to be readable. It's just there so you can see what kind of modules or what host of modules you actually need to implement at your charging station. An example is if you want to build a charging box with, for example, like two charging connectors, you can just load the charging core modules twice and then you decide, hey, I want to add some OSPB connectivity. You just add the OSPB module there and then maybe you want to do some energy management and you add that on top as well. Okay, to make this configuration super easy, we also build a little web application so you can see on the left side a list of all the available modules. You can drag them into this canvas and then modify the configuration of them and do some drag and drop between the modules and connect their interfaces together. And then you can just hit the save button on the bottom and everything will restart and you can just configure your box like that. So what are some of the typical modules that you find on the inside? The most important ones are in the charging core. We call this the EVSE manager. This is a central module that basically owns a charging port and the old charging session with a car. So it knows when the charging session started, when you plugged in your car and it knows when it ended, when you plugged out your car and everything that happened in between how many kilowatt hours were charged and all of those things. And it also manages all these interactions with the different norms that we touched on earlier. So if you do this basic signaling with a PWM signal on the control wire, we do this or we also support the high-level communication with an ethernet link on top of this control pilot wire with the ISO 15118 and Dinspec. All right, so these ISO 15118 and Dinspec protocols, they're basically like XML-based protocols that you can use to talk with the car. So you get much more information from the vehicle like how many kilowatt hours it needs to actually fulfill its charging target or how big the battery is so you can estimate like the state of charge of the vehicle. This stack is then like a completely separate module that you can load or leave it out even completely. When you do that, you end up with a basic AC charger, but if you decide to load it, you can also implement a DC charger because DC is basically completely based on these ISO and Dinspec protocols. And yeah, underneath this charging core layer, we have a simple hardware abstraction layer. This is a couple of modules and we try to make this interface as easy as possible. So it's quite easy to port to new hardware. And a simple example would be if you want to build like a really simple charging station, what you just need to do is write a small driver that does all of this PWM stuff. So you can set the correct duty cycle and maybe click some relays. And that's pretty much all that you need to build like a really basic AC charger. And yeah, if you don't need some more hardware abstraction, like for power meters, et cetera, you can also do this in the hardware abstraction layer here. But the good news is if you use commonly available hardware, and most of the work is probably already done, or you can use a driver module that we already have and just modify it a little bit for your use case. So now, looking towards the cloud communication, like Pete said earlier, if you want to do some remote management of your stations, or you want to do billing, you kind of need this. So we also provide a OCPP 1.6 JSON implementation. And yeah, a lot of effort went into this implementation to make it as standard compliant as possible. We verified this with a lot of commercial backends, but also with the official protocol testing tool from the OpenCharge Alliance. And yeah, we also wrote our own tool to integrate it a lot into our simulated charging session tooling and we'll release that in the coming weeks. Yeah, and I think we actually might have the most feature complete open source implementation of OCPP 1.6 available with like all the optional profiles and the security extensions. And OCPP 2.0 support is also in the pipeline, but yeah, there's no complete roadmap to get there yet. All right, another important thing is the energy management. Here you can use a very similar mechanism than the one that I showed you earlier for configuring the internals of this charging station. Here you can use it to basically model the externals of the charging station. So here on the left side you see a 40M fuse, which is kind of the representation for a grid connection point. And there you can add some side modules like a power meter, so everyone knows about the power consumption at this grid connection point. Or if you have a contract, a power contract, if you're an electricity supplier that gives you different pricing at different times of the day, you can also do it at a module for price forecasting here. And from here on out, you can then start to model out the power distribution grid of your house. So on the top right you see a 16M fuse and two EVSEs like two charging stations connected that are also both able to draw 16Ms each. So you won't be able to run them at full capacity without blowing this fuse, so you definitely need some form of energy management here. And then on the further right, we have a few example cars. Like the first one just needs to leave as soon as possible and wants to charge as much as it can. And like the second one wants to leave at 7am in the morning and wants to charge as cheaply as possible. And if you then try to add some solar in the mix in the bottom with a solar forecast where you know that sometime in the afternoon you might have a few hours of sunshine, you might want to schedule this car so it charges between 2 and 4pm and do the rest of the charging in the night when it becomes cheap again. Once you have all of this information, we can then run a whole global optimizer over this tree and get a solution that takes all of these charging goals of the different cars into account and also takes all the restrictions that we have into account and makes sure that we, for example, don't really blow any fuses or something like that. This also gets a lot more interesting. Like Pete also mentioned in the beginning when we have wide support for B-directional charging because then we can do things like I don't know, use the car as a dump solar load and then maybe try to sell the energy that's in that car at a later date or something like that. But this is a part that's under heavy development right now. So and for chargers that have a display connected to them, we also built a little display app that you can run on the charger which just shows you all the important information that you need. This is also under heavy development at the moment and we're going to release the source code to that in I think the coming weeks as well. So we also have a complete software and a loop simulation. So for all of the hardware drivers that we have, we also have a complete software simulation tool available so you can run the whole average stack on your laptop without needing a charging station or a car. So you can just, I don't know, load a simulated car module, run that and simulate a whole charging session from plugging the car until it plugs out again and even, I don't know, connect that to your OCBP backend service. This simulation also has support for ISO 15118 software loop simulation and it makes it really convenient to develop Everest and run it on your machine without even needing hardware. As you might have seen from the screen show earlier and from this one, internally we use a lot of Node Red to build some smaller development UIs and that is really convenient because it connects fairly easily to MQTT and then you can use it to build really simple depth UIs, add some graphs to it and visualize things whilst you're developing. And yeah, if this sounded interesting to you, we do have all of our code on GitHub but we also have a weekly developer sync meeting which is on Tuesdays at 10am Central European Summer Time because I mean we're based in Germany so it's quite convenient for us but this is open to the public so you can show up there if you want to ask some questions but we also have a technical steering committee meeting for Everest which is going on at a monthly rate I think on every 4th Tuesday, first day and the next one is pretty much an exactly a week from now. And yeah, we also have a mailing list, we have a channel in the LF Energy Slack and yeah, if you have any questions, of course. Slides are also I think already. All right, so if you have any questions, we're going to be around for a few more minutes. Well it's running on a few development charges right now from Charger Manufacturers, it's also running on our own like development kit that our company builds like not really for selling, I mean you can buy it I think but it's not meant to be as a consumer device just more like a technology demonstrator and yeah, I think I've been charging my car for almost a year with it now so it's definitely running on some commercial hardware but I don't think you can buy Charger at the moment where it's running on but I'm pretty sure you will be able to in I don't know a year or two. Yeah, I've just put on the slide where you can see a little bit of the community that we have right now. So we are able to talk about some projects that we have with some charging station manufacturers. I said, well I think I told you about Futech and Marlin the hate charge so we are currently working on projects with them with charges coming up in the next year and also with these component suppliers. So ChargeBite is this former intake, it is a German company that does these charge controllers for the charges so they are not charging station manufacturers but they do the communication controllers and they are going to adopt Everest or we integrate them into the Everest project and they will spend a lot of code and will use Everest in the future so a lot of stuff happened there in the last months which is really promising. So we are not focusing only on the European market on purpose so I think like I don't know the protocol really well but SunSpec is some kind of protocol that is mainly used in the US and we are not targeting only the European market. I think I mentioned that we are evaluating to work together with Texas Instruents right now to get Everest going on their devices but that is basically all I can say about that. Just to add to that, we started this project around two years ago and obviously coming from Europe it is a bit European centric but it is definitely not something that we only want to have in the European market. We also want to expand into like I don't know United States, Asia with this because we see the same problems and opportunities there as well. So just to repeat your question, thank you for working in the related field or in the field and the problems with industry standards not being like that open is definitely a bit of a problem but for us it is usually we are buying the standards and reading them and working on that and think it is okay to implement all of these things in an open way. So it might not even be much of a problem for users of us that they don't need the standards. They can just use our software or open source software and don't really have to think about all of these standards. This might be a work around here but it is definitely a bit of a problem that some of these things are under quite high paywalls at some times and hard to access especially like for the enthusiasts maybe. I would say this is something that is not very high on our list at the moment but we are definitely working on things like secure boots and doing things with trusted platform modules to try to lock down some of the hardware but from a project standpoint we are focusing mostly on the standards implementations and protocols and some hardware drivers and usually when you are working with a manufacturer together they already have some form of ecosystem that you can just integrate with and like I mentioned we don't really sell chargers. We just sell a development kit and there doesn't make much sense to have a highly secure platform that nobody can tamper with. This is more something that would then be happening in collaboration with a manufacturer if they want to do it. I hope that answers your question there. So just to recap the question I mean you are asking something how do we see the chances of Warbox kits being available and Everest running on them for example. I think that is actually something that will happen eventually because the hardware you actually need to build a simple AC charger for the home is really simple and inexpensive. I mean you can get away with basically a Raspberry Pi, a relay and some microcontroller where you run some real-time PWM generation code on and that's basically all you need. So kits like that would be pretty easily integrated into Everest but I think we haven't really looked into that right now but certainly in the future. Absolutely I mean this is something where we also are aware of that there's others in this space working on it quite a lot and so we would love to collaborate in this aspect and nothing of this whole Everest project. I mean you can run our modules on this framework pretty agnostically from anything that is EV charging where you can probably write some games that work over the framework or something like that. So that is actually something that we would really like to do and if there's some collaboration aspects or some collaboration possibilities we would really be interested into that. Yeah to quickly add on to that the energy management part is definitely really interesting and we know that there are like single companies who do not do anything else but developing such energy management algorithms and integrate like charging stations and batteries and solar panels into that but as Kai already mentioned like the framework that we created is not really stick to EV charging it can also be used like to run any module that you want so it could be a really nice framework also for the energy management as well for different modules for that we're really looking into this collaboration with research institutes and universities because it's kind of a separated problem that you can really easy like give away to someone who wants to work on it and yeah definitely interesting for Everest to develop also into that direction but currently we are focusing on EV charging and there's a lot to do in that sector I hope that we could present it to you in this presentation. Thank you. I think maybe we can fit in one more question. So this is covered by this OSPP protocol that I mentioned so the cloud communication handles so when you do a charging station you authorize somehow so you swipe your RFID card or you have your mobile phone app you have a contract with your mobility service provider and then all the transaction related data like when did you start charging what was the meter value at the start at the end will be transmitted to the backend system and then will be on your bill of your mobility service provider and this is all covered by OSPP also in the version already in the version 1.2 I guess I know of OSPP in version 1.5 now at 1.6 and 2.0 covers a lot more than that but OSPP was yeah basically starting with all that solving that payment and bidding problem now it's it has a lot of more features for example that it has also features to control the the charge power of your charger so what all these other interfaces also do and for the ng management related stuff but it was usually designed to solve all that monitoring and payment and billing stuff problem yeah and there's another standard out there I think I forgot to mention it it's the IEC 633110 or something which looks like it it'll be a follow-up to OSPP there's an IEC working group on it right now OSPP is just a de facto standard but not really a standard but everyone's using it right now and maybe there will be something different in the future but um yeah there's so much to come and this is why we also think that an open source implementation is so valuable because it doesn't really stop and there's yeah so much more to come all right thank you