WEBVTT 00:00.000 --> 00:07.000 How will you just use X to try and? 00:07.000 --> 00:08.000 Hello. 00:08.000 --> 00:09.000 Hello. 00:09.000 --> 00:12.000 He's going to talk about open source EV charging. 00:12.000 --> 00:13.000 Yes. 00:13.000 --> 00:14.000 Thanks a lot. 00:14.000 --> 00:15.000 Yeah. 00:15.000 --> 00:16.000 I'm Marco. 00:16.000 --> 00:19.000 I'm part of the Everest OpenSource project. 00:19.000 --> 00:20.000 Yes. 00:20.000 --> 00:22.000 I tried to visualize here. 00:22.000 --> 00:26.000 And I would love to tell you about the easiest EV charging. 00:26.000 --> 00:29.000 What we try to do there with your open source project. 00:29.000 --> 00:33.000 Yeah, how we fix all this messy real-world problems. 00:33.000 --> 00:39.000 So in principle, with all this energy transition going on, we want to electrify billions of cars in the world. 00:39.000 --> 00:41.000 So that's quite not so. 00:41.000 --> 00:45.000 And if you look at the industry, there's currently thousands of different car types in the won't get less. 00:45.000 --> 00:49.000 There's thousands of charging stations, types, backends, apps, whatsoever. 00:49.000 --> 00:55.000 If you just extrapolate, we will use billions of charging stations in just this just interpability nightmare. 00:55.000 --> 00:57.000 We see maintenance issues in the field. 00:57.000 --> 00:59.000 We see stranded assets. 00:59.000 --> 01:01.000 And let's say software quality isn't where it should be. 01:01.000 --> 01:05.000 And what this picture visualized, we have a commentary problem. 01:05.000 --> 01:11.000 Like if you have 1000 car types, 1000 charging stations, types, 1000 backing system types. 01:11.000 --> 01:13.000 It's a billion combinations. 01:13.000 --> 01:15.000 You have to consider when you test. 01:15.000 --> 01:17.000 And that's basically impossible. 01:17.000 --> 01:23.000 And there are really systems where you have to test every combination or it would be better if you do so. 01:23.000 --> 01:25.000 So how do we address that? 01:25.000 --> 01:31.000 First of all, yeah, yeah, we could sanitize all of this then everything would be better. 01:31.000 --> 01:35.000 But as, in the case, did you also point it out? 01:35.000 --> 01:37.000 Just adding more and more standards is not the solution here. 01:37.000 --> 01:39.000 So we should try something different. 01:39.000 --> 01:47.000 And what the Airbus Omsource product is doing is we try to have one software stack which solves and serves all the possible combinations here. 01:47.000 --> 01:51.000 So the idea is unifying that ecosystem with Omsource. 01:51.000 --> 01:54.000 And I guess, my dear friend, I'm listening to this. 01:54.000 --> 01:57.000 No, I'm not saying everything has to be one open source project. 01:57.000 --> 02:01.000 But I think having a thousand implementations out there is not solving the thing. 02:01.000 --> 02:05.000 So if we can dance it down to a few, would it actually help quite a bit. 02:05.000 --> 02:12.000 And this shared investment is also freeing up resources for doing actual useful stuff. 02:12.000 --> 02:17.000 Instead of having the tens or hundreds implementation of their kind action protocol. 02:17.000 --> 02:25.000 So what ever is technically doing, yes, with Apache license, software stack, under the Linux Foundation energy. 02:25.000 --> 02:33.000 We do all kind of interaction between cars, payment terminal displays back and management system. 02:33.000 --> 02:37.000 The power grid either locally or remote. 02:37.000 --> 02:40.000 And so that means we have tons of different protocols to integrate. 02:40.000 --> 02:43.000 And we have a lot of data machine in the middle. 02:44.000 --> 02:47.000 And the problem is every charter looks different. 02:47.000 --> 02:52.000 So you have maybe single port home chargers, which has super damped you have public charging parks. 02:52.000 --> 02:54.000 There's a lot of different hardware configurations. 02:54.000 --> 02:56.000 How do you map that into one software stack? 02:56.000 --> 03:02.000 Yeah, we build something like a module framework where you can freely configure for whatever what you want to build out of that. 03:02.000 --> 03:04.000 So it can tailor the software to your hardware. 03:04.000 --> 03:06.000 So building block thinking. 03:06.000 --> 03:08.000 The problem with that, if you do that. 03:09.000 --> 03:15.000 So you enable the huge ecosystem of different players and vendors using that with their product. 03:15.000 --> 03:22.000 So being compatible or building that into their product and using it in their charles in the field. 03:22.000 --> 03:29.000 But you can't just cover that visible unit test of testing the single line or just making 100% code coverage. 03:29.000 --> 03:34.000 Because you need something like scenario coverage and then back to the building combinations. 03:34.000 --> 03:37.000 So now try to map it with a colleague last week. 03:37.000 --> 03:39.000 That's the stuff we're actually doing out there. 03:39.000 --> 03:42.000 So it's not just unit tests. 03:42.000 --> 03:45.000 We are going from your best practices. 03:45.000 --> 03:47.000 We look so nice to address that to us. 03:47.000 --> 03:50.000 Like CICD codes, mail, audits. 03:50.000 --> 03:52.000 We're doing all of that on top of that. 03:52.000 --> 03:56.000 We try to implement each protocol as much as we can from both sides. 03:56.000 --> 04:01.000 And not only implementing the chargers side of a communication channel, but also the car side. 04:01.000 --> 04:03.000 So we can at least test against ourselves. 04:03.000 --> 04:06.000 But if you test against yourself, you also may be talking bullshit to yourself. 04:06.000 --> 04:09.000 So we also need to test against third party. 04:09.000 --> 04:11.000 You need the system level testing. 04:11.000 --> 04:15.000 Like having real hardware in the loop, having other third party software, 04:15.000 --> 04:18.000 other third party hardware in the loop in the testing. 04:18.000 --> 04:21.000 And really down to real broad feedback loops. 04:21.000 --> 04:24.000 Like what happens in the field is something happening there. 04:24.000 --> 04:27.000 What we maybe should think about. 04:27.000 --> 04:33.000 And even back to giving the feedback loop into a monetization to maybe even fix the standards. 04:33.000 --> 04:38.000 So this slide will be a bit big. 04:38.000 --> 04:39.000 Let's see if that works. 04:39.000 --> 04:44.000 So typically, as one example, we're looking at three different entities. 04:44.000 --> 04:49.000 The charting station, the middle, count the one side and count on the other side. 04:49.000 --> 04:55.000 And one way, every one at the moment is testing is from the open charter lines. 04:55.000 --> 05:02.000 That's a Dutch non-profit which specifies the protocol between the charting station and the cloud. 05:02.000 --> 05:10.000 They build a test system, what they offer, unfortunately, paid for all their members and everyone else 05:10.000 --> 05:12.000 for testing this link. 05:12.000 --> 05:16.000 So they can either take a charting station and talk to another back-end system, 05:16.000 --> 05:21.000 or they can take a back-end system, talk to another combination of charges and or cars. 05:21.000 --> 05:25.000 And that's nice and that's helpful. 05:25.000 --> 05:31.000 And together with an ever-space charting station, you can even use that for testing your car. 05:31.000 --> 05:39.000 What we're also now doing, because they have to test their testing system if it actually makes sense, if it actually does, what it should do, 05:39.000 --> 05:41.000 they're cross-testing against Everest. 05:41.000 --> 05:49.000 So every new release of this test tool is testing against us, and now every new release of Everest is tested against their test tool. 05:49.000 --> 05:53.000 So the way we are, it's called in their world, golden system and a test. 05:53.000 --> 06:02.000 So they, before they release their official certification tool, their testing against our open source implementation, and before we will release something, 06:02.000 --> 06:07.000 we'll test against them, so kind of help each other to up-level ourselves. 06:07.000 --> 06:15.000 And based on that, we mean also offer kind of the same tooling as charting station car combination, 06:15.000 --> 06:20.000 based on the Everest Open Source deck for other back-end systems, so they can test against that. 06:20.000 --> 06:27.000 And you can even think about combining those tools which are out there, like using an Everest fake car, 06:27.000 --> 06:34.000 together with this rich test set from the Open Charge Alliance to test charting station, the middle, just a black box test, 06:34.000 --> 06:41.000 or potentially also a white box test if you want to fake user interaction without actually pressing buttons. 06:42.000 --> 06:52.000 And end of the day, we're also using Everest quite successfully since a while, with deploying some example charters from Pionics or from anyone else. 06:52.000 --> 07:00.000 Going after the car or M, so they can test their prototype cars years before they release to the public against that software stack, 07:00.000 --> 07:05.000 which is not just the dumb test system, but actually production code which will end up in the field. 07:05.000 --> 07:12.000 So with all that combinations, we try to bring Open Source and Open Standards into this as much as we can. 07:12.000 --> 07:18.000 Yeah, and this virtual charter park is basically a cloud service we built around Everest, 07:18.000 --> 07:20.000 in order to make it easier. 07:20.000 --> 07:25.000 But in principle, all the components of Open Source, this description, how to set up Docker containers with that. 07:25.000 --> 07:32.000 And you can see we also used Node Red to build this more user interface for that emulated charger, 07:32.000 --> 07:38.000 the good thing is all the logic under the hood between weaker communication, power system communication. 07:38.000 --> 07:44.000 All of that is not faked, but it's the actual bits flowing just on a local host. 07:44.000 --> 07:50.000 What we also built in the Everest community are just starting to, because we realize testing is super hard. 07:50.000 --> 07:55.000 If the community built a couple of test cases, there's always something missing. 07:55.000 --> 08:00.000 So one vendor suggested some months ago, like, could we do federated testing? 08:00.000 --> 08:10.000 So having a centralized system which is just saying, okay, there's a new branch coming in, and we want to test that against reality. 08:10.000 --> 08:17.000 How to do that? Yes, there are some Everest internal test cases, but actually every vendor, every R lines can register. 08:17.000 --> 08:20.000 It's like, okay, please tell me when you do a test run. 08:20.000 --> 08:26.000 I will copy through my proprietary system, do a test run with my commercial set up there as well, 08:26.000 --> 08:29.000 and then tell back to the community, oh, this is good or this is bad. 08:29.000 --> 08:38.000 So this way we can outsource the testing effort into the companies who use that code and don't break something there. 08:38.000 --> 08:44.000 We're also, we're using the cost of the effort on the Opusource project and make it even more industrial usable. 08:44.000 --> 08:49.000 And everyone can register for free, but that also comes with the responsibility. 08:49.000 --> 09:03.000 So if you don't fix bugs, you're flagging after why we would remove you from that blocking queue, because you can't block a release for years if you gave up on that. 09:03.000 --> 09:09.000 So what else is this industry doing? Now it gets even more messy into the reality. 09:09.000 --> 09:15.000 There's some speed dating events for tech. Well, let's say 10 cars and 10 charging stations meeting, 09:15.000 --> 09:21.000 and every combination gets two hours together and see if things spark literally. 09:21.000 --> 09:28.000 That's called then test reveal from the, from Charlie, which is a big industry consortia. 09:28.000 --> 09:33.000 Similar things happened with back-end system and charging stations and it's called OCPP Plug Fest, 09:33.000 --> 09:44.000 with their own charge aligns, you often see prototypes there, and it's super, super helpful, because having those different combinations that really works. 09:44.000 --> 09:51.000 One fun anecdote, there was recently a new standard released from the old Bob and Charge Alliance version 2.1. 09:51.000 --> 09:58.000 We had been on a test reveal with our Everest implementation. This was totally brand new code, we tested it and everything worked like what the fuck is happening here. 09:58.000 --> 10:04.000 What we then realized like, oh, they're all tested silently over the last weeks against our public GitHub. 10:04.000 --> 10:13.000 So we don't even have to come in certain situations because we kind of becoming the free resource countertest tools for the industry, which is really really nice to see. 10:14.000 --> 10:21.000 Beside that there's also commercial solutions from vector, commands or whatever big hardware blocks, which come with the software subscription, 10:21.000 --> 10:26.000 where you can also run a couple of, let's say, industry-maintained test cases. 10:26.000 --> 10:34.000 And I think Everest compliments that because we're not a dedicated test system, we just let's say the productive code, which you can also use for testing. 10:35.000 --> 10:46.000 What we're also now doing, or what the industry typically doing, IT spaces, monitoring the things out there in the field, see if there are bugs, if there's issues. 10:46.000 --> 10:55.000 So from a bug reported to unrolling and firmware update in a canary way, so starting small increasing fast. 10:55.000 --> 11:00.000 It's also good practice, so we have the feedback loop to the real productive world. 11:00.000 --> 11:07.000 It's in the build system, which is dedicated for Everest, and it's then the lock file, and it's then the even charting specific harm. 11:07.000 --> 11:12.000 But there's also a lot of generic IT platforms out there, like things bought. 11:12.000 --> 11:19.000 But also we are super happy that Elef Energy recently sponsored the penetration testing for the Everest project. 11:19.000 --> 11:26.000 It was done by Quark Slap, I think it was over the last eight or six months or so. 11:26.000 --> 11:30.000 It was also organized off this energy death room worked intensively with them. 11:30.000 --> 11:34.000 So principal quite happy side anecdote here. 11:34.000 --> 11:41.000 The number one bug they flexed, like, oh, but you can copy RF ID cards quite easily. 11:41.000 --> 11:49.000 Then you can fake anyone else in the room and copy their charter account, like, yes, we know that. 11:49.000 --> 11:56.000 It's a flaw in this download. It's a bit like you can't be more secure as an implementation at the standard you implementing are. 11:56.000 --> 12:01.000 And things like that popping up there, but also a few other things which have been useful. 12:01.000 --> 12:09.000 And then we're responsibly fixed and disclosed by the scenes before unrolling the report in the public. 12:09.000 --> 12:18.000 Another feedback loop we're now implementing is not only having the developer of Everest in the community in the different working groups, but also having the users. 12:18.000 --> 12:26.000 So, like, the ones who buying charting station unroll them into the fields and have to lift with the stuff we're building here as a community. 12:26.000 --> 12:31.000 And that's just started continuous in two weeks from now. 12:31.000 --> 12:37.000 And the goal is really having the feedback loop on what criteria should the community focus on? 12:37.000 --> 12:40.000 What should be the roadmap? What KPI should you measure for? 12:40.000 --> 12:43.000 What do we expect from a good system to behave? 12:43.000 --> 12:52.000 So, I think user groups are a perfect way on a very slow compared to unit tests, feedback cycle and equality, but I think it's really crucial. 12:52.000 --> 12:56.000 Yeah, and end of the day, the organization is super, super slow. 12:56.000 --> 13:05.000 Often quoting this OCA standard here, just to give you an idea, I think the current standard 2.1 is out there since two years. 13:05.000 --> 13:08.000 The previous one is out there since eight years. 13:08.000 --> 13:11.000 And the previous previous one is still 80% adoption rate. 13:11.000 --> 13:18.000 So, everything happened in the last eight years plus is less than 20% in the field. 13:18.000 --> 13:27.000 So, still, we try to be the first implementer of new things with the community doing that really really cross vendors. 13:27.000 --> 13:32.000 What you often see is one vendors interested in the future, then they go after it and others interested in another feature. 13:32.000 --> 13:39.000 The community we tied that together, and then end of the day, we hopefully have a really cool and feature complete implementation. 13:39.000 --> 13:45.000 And often we also see issues with the standard in that process, so we can cycle it back to the committees. 13:45.000 --> 13:50.000 Sometimes we got asked by the committees like, oh, this was not specified. How is everyone doing it? 13:50.000 --> 13:54.000 Then we tell them, and they may be go after that solution and put it into the standard. 13:54.000 --> 13:57.000 So, I think it can be a really fruitful relationship. 13:57.000 --> 14:08.000 And the good thing is, if our implementation is ready as soon as they are ready with drafting, we can accelerate this eight years before a new version is used, but I just quoted quite a bit. 14:08.000 --> 14:10.000 Yeah, that's it about Everest. 14:10.000 --> 14:20.000 If you're interested in joining us, all the code is here, we have quite an active chat space, we have a lot of, also quite an extended refresh. 14:20.000 --> 14:27.000 The presentation of their different work and groups every week, there's a couple of different meetings for sub-seconds. 14:27.000 --> 14:30.000 Yeah, give us a ping and if you have any questions, let me know. 14:30.000 --> 14:37.000 Thank you. 14:37.000 --> 14:43.000 A four minute for the question. 14:43.000 --> 14:45.000 Thanks for the presentation. 14:45.000 --> 14:58.000 I know there's a lot to cover in this field, but if you didn't talk about the interaction between the CPU and the interfaces that are planned facing, 14:58.000 --> 15:01.000 you're not going to cater with the CPU. 15:01.000 --> 15:06.000 Is it something you are planning to cover in the future? 15:06.000 --> 15:09.000 So, I know what you're talking about. 15:09.000 --> 15:15.000 So, in principle, going back to the picture, Everest focuses on the chart on the middle. 15:15.000 --> 15:19.000 The chart for operators are in my symbol, like the yellow dots here. 15:19.000 --> 15:23.000 And the protocols you talk is kind of another layer behind this. 15:23.000 --> 15:32.000 So, we're not going after that, because this OCPI and all the testing on that, and it's the duty of another open source project. 15:32.000 --> 15:44.000 There's a few, like Centrino as a synopsonation, may even in others out there, so they hopefully take care of that. 15:44.000 --> 15:52.000 We're peeding the question, so what is the organization behind the Everest project? 15:52.000 --> 16:00.000 It's a company or community, so my startup started that open source project, like six years ago, five and a half years ago, 16:00.000 --> 16:05.000 donated to the Linux Foundation, like one here later or so. 16:05.000 --> 16:12.000 And since then, we are given the Linux Foundation tools, like 600 people already touched that project, more than 80 organizations. 16:12.000 --> 16:19.000 So, yes, my startup is still one of the drivers, we do quite a bit, but we are by far not the only one. 16:19.000 --> 16:23.000 And so, I think, in some way, we're not the biggest contributor. 16:23.000 --> 16:28.000 We are one of big ones, but there's others which are in total way bigger than us. 16:28.000 --> 16:30.000 Does it answer your question? 16:30.000 --> 16:37.000 And right, how we organize this monthly technical steering, committee meeting, where the high level political decisions are made in consensus, 16:37.000 --> 16:44.000 then there's different working groups for let's say meeting once a week to discuss, go left, go right, how to do certain features, 16:44.000 --> 16:55.000 and then there's Ruler Pshet and GitHub interaction and pull requests, and there's all the details then. 16:55.000 --> 17:02.000 So, it's super hard, so how many challenges are on the field, what's Everest super hard to guess to it? 17:02.000 --> 17:11.000 Because it's a process, you don't know who adopted it, based on our best knowledge, it should be roughly 76,000 right now, 17:11.000 --> 17:14.160 huge vendor who are in a retrofit 300,000 17:14.160 --> 17:16.400 chargers and within the next weeks. 17:16.400 --> 17:20.200 So we will have the post plan for next end of last year, 17:20.200 --> 17:21.960 but everything is later as you know. 17:21.960 --> 17:25.280 So we will have like 3,400,000 in some days. 17:25.280 --> 17:28.600 And then do you see these vendors actually 17:28.600 --> 17:30.080 support in the maintenance? 17:30.080 --> 17:31.200 Yeah. 17:31.200 --> 17:33.560 Not every vendor supporting the maintenance, 17:33.560 --> 17:34.720 but some vendors do. 17:34.720 --> 17:37.600 And it's like I can name some who already public, 17:37.600 --> 17:39.600 like Alpham from the Netherlands, 17:39.600 --> 17:42.960 contribute a lot to a certain library for a certain version. 17:42.960 --> 17:45.320 Now another vendor is picking up for the next version, 17:45.320 --> 17:47.000 helping there. 17:47.000 --> 17:49.160 Really, wherever someone is interested. 17:49.160 --> 17:54.880 No one pays, no one pays, no one pays. 17:54.880 --> 17:57.480 Then the base for maintenance? 17:57.480 --> 18:00.000 No, no one pays for maintenance. 18:00.000 --> 18:02.560 The maintenance is like best effort. 18:02.560 --> 18:06.080 If you need something super rock solid tested, 18:06.080 --> 18:07.320 you may be able to do it yourself 18:07.320 --> 18:08.920 or find someone helping you. 18:09.000 --> 18:10.920 Yes, I would do that in principle, 18:10.920 --> 18:14.200 about a general business case of economics. 18:14.200 --> 18:16.000 So the business case of Pionics, 18:16.000 --> 18:18.160 we help people to code missing features 18:18.160 --> 18:19.800 if they can't do it themselves. 18:19.800 --> 18:21.960 And we offer hard for modules which are compatible 18:21.960 --> 18:25.360 with errors, offering cloud solutions if they need something 18:25.360 --> 18:25.960 on top. 18:25.960 --> 18:28.240 But every itself, we not make money with that. 18:28.240 --> 18:30.200 The installation isn't making money. 18:30.200 --> 18:33.200 This is just more than a million lines of code 18:33.200 --> 18:34.760 by a lot of people built together.