How will you just use X to try and?
Hello.
He's going to talk about open source EV charging.
Yes.
Thanks a lot.
Yeah.
I'm Marco.
I'm part of the Everest OpenSource project.
Yes.
I tried to visualize here.
And I would love to tell you about the easiest EV charging.
What we try to do there with your open source project.
Yeah, how we fix all this messy real-world problems.
So in principle, with all this energy transition going on, we want to electrify billions of cars in the world.
So that's quite not so.
And if you look at the industry, there's currently thousands of different car types in the won't get less.
There's thousands of charging stations, types, backends, apps, whatsoever.
If you just extrapolate, we will use billions of charging stations in just this just interpability nightmare.
We see maintenance issues in the field.
We see stranded assets.
And let's say software quality isn't where it should be.
And what this picture visualized, we have a commentary problem.
Like if you have 1000 car types, 1000 charging stations, types, 1000 backing system types.
It's a billion combinations.
You have to consider when you test.
And that's basically impossible.
And there are really systems where you have to test every combination or it would be better if you do so.
So how do we address that?
First of all, yeah, yeah, we could sanitize all of this then everything would be better.
But as, in the case, did you also point it out?
Just adding more and more standards is not the solution here.
So we should try something different.
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.
So the idea is unifying that ecosystem with Omsource.
And I guess, my dear friend, I'm listening to this.
No, I'm not saying everything has to be one open source project.
But I think having a thousand implementations out there is not solving the thing.
So if we can dance it down to a few, would it actually help quite a bit.
And this shared investment is also freeing up resources for doing actual useful stuff.
Instead of having the tens or hundreds implementation of their kind action protocol.
So what ever is technically doing, yes, with Apache license, software stack, under the Linux Foundation energy.
We do all kind of interaction between cars, payment terminal displays back and management system.
The power grid either locally or remote.
And so that means we have tons of different protocols to integrate.
And we have a lot of data machine in the middle.
And the problem is every charter looks different.
So you have maybe single port home chargers, which has super damped you have public charging parks.
There's a lot of different hardware configurations.
How do you map that into one software stack?
Yeah, we build something like a module framework where you can freely configure for whatever what you want to build out of that.
So it can tailor the software to your hardware.
So building block thinking.
The problem with that, if you do that.
So you enable the huge ecosystem of different players and vendors using that with their product.
So being compatible or building that into their product and using it in their charles in the field.
But you can't just cover that visible unit test of testing the single line or just making 100% code coverage.
Because you need something like scenario coverage and then back to the building combinations.
So now try to map it with a colleague last week.
That's the stuff we're actually doing out there.
So it's not just unit tests.
We are going from your best practices.
We look so nice to address that to us.
Like CICD codes, mail, audits.
We're doing all of that on top of that.
We try to implement each protocol as much as we can from both sides.
And not only implementing the chargers side of a communication channel, but also the car side.
So we can at least test against ourselves.
But if you test against yourself, you also may be talking bullshit to yourself.
So we also need to test against third party.
You need the system level testing.
Like having real hardware in the loop, having other third party software,
other third party hardware in the loop in the testing.
And really down to real broad feedback loops.
Like what happens in the field is something happening there.
What we maybe should think about.
And even back to giving the feedback loop into a monetization to maybe even fix the standards.
So this slide will be a bit big.
Let's see if that works.
So typically, as one example, we're looking at three different entities.
The charting station, the middle, count the one side and count on the other side.
And one way, every one at the moment is testing is from the open charter lines.
That's a Dutch non-profit which specifies the protocol between the charting station and the cloud.
They build a test system, what they offer, unfortunately, paid for all their members and everyone else
for testing this link.
So they can either take a charting station and talk to another back-end system,
or they can take a back-end system, talk to another combination of charges and or cars.
And that's nice and that's helpful.
And together with an ever-space charting station, you can even use that for testing your car.
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,
they're cross-testing against Everest.
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.
So the way we are, it's called in their world, golden system and a test.
So they, before they release their official certification tool, their testing against our open source implementation, and before we will release something,
we'll test against them, so kind of help each other to up-level ourselves.
And based on that, we mean also offer kind of the same tooling as charting station car combination,
based on the Everest Open Source deck for other back-end systems, so they can test against that.
And you can even think about combining those tools which are out there, like using an Everest fake car,
together with this rich test set from the Open Charge Alliance to test charting station, the middle, just a black box test,
or potentially also a white box test if you want to fake user interaction without actually pressing buttons.
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.
Going after the car or M, so they can test their prototype cars years before they release to the public against that software stack,
which is not just the dumb test system, but actually production code which will end up in the field.
So with all that combinations, we try to bring Open Source and Open Standards into this as much as we can.
Yeah, and this virtual charter park is basically a cloud service we built around Everest,
in order to make it easier.
But in principle, all the components of Open Source, this description, how to set up Docker containers with that.
And you can see we also used Node Red to build this more user interface for that emulated charger,
the good thing is all the logic under the hood between weaker communication, power system communication.
All of that is not faked, but it's the actual bits flowing just on a local host.
What we also built in the Everest community are just starting to, because we realize testing is super hard.
If the community built a couple of test cases, there's always something missing.
So one vendor suggested some months ago, like, could we do federated testing?
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.
How to do that? Yes, there are some Everest internal test cases, but actually every vendor, every R lines can register.
It's like, okay, please tell me when you do a test run.
I will copy through my proprietary system, do a test run with my commercial set up there as well,
and then tell back to the community, oh, this is good or this is bad.
So this way we can outsource the testing effort into the companies who use that code and don't break something there.
We're also, we're using the cost of the effort on the Opusource project and make it even more industrial usable.
And everyone can register for free, but that also comes with the responsibility.
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.
So what else is this industry doing? Now it gets even more messy into the reality.
There's some speed dating events for tech. Well, let's say 10 cars and 10 charging stations meeting,
and every combination gets two hours together and see if things spark literally.
That's called then test reveal from the, from Charlie, which is a big industry consortia.
Similar things happened with back-end system and charging stations and it's called OCPP Plug Fest,
with their own charge aligns, you often see prototypes there, and it's super, super helpful, because having those different combinations that really works.
One fun anecdote, there was recently a new standard released from the old Bob and Charge Alliance version 2.1.
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.
What we then realized like, oh, they're all tested silently over the last weeks against our public GitHub.
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.
Beside that there's also commercial solutions from vector, commands or whatever big hardware blocks, which come with the software subscription,
where you can also run a couple of, let's say, industry-maintained test cases.
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.
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.
So from a bug reported to unrolling and firmware update in a canary way, so starting small increasing fast.
It's also good practice, so we have the feedback loop to the real productive world.
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.
But there's also a lot of generic IT platforms out there, like things bought.
But also we are super happy that Elef Energy recently sponsored the penetration testing for the Everest project.
It was done by Quark Slap, I think it was over the last eight or six months or so.
It was also organized off this energy death room worked intensively with them.
So principal quite happy side anecdote here.
The number one bug they flexed, like, oh, but you can copy RF ID cards quite easily.
Then you can fake anyone else in the room and copy their charter account, like, yes, we know that.
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.
And things like that popping up there, but also a few other things which have been useful.
And then we're responsibly fixed and disclosed by the scenes before unrolling the report in the public.
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.
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.
And that's just started continuous in two weeks from now.
And the goal is really having the feedback loop on what criteria should the community focus on?
What should be the roadmap? What KPI should you measure for?
What do we expect from a good system to behave?
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.
Yeah, and end of the day, the organization is super, super slow.
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.
The previous one is out there since eight years.
And the previous previous one is still 80% adoption rate.
So, everything happened in the last eight years plus is less than 20% in the field.
So, still, we try to be the first implementer of new things with the community doing that really really cross vendors.
What you often see is one vendors interested in the future, then they go after it and others interested in another feature.
The community we tied that together, and then end of the day, we hopefully have a really cool and feature complete implementation.
And often we also see issues with the standard in that process, so we can cycle it back to the committees.
Sometimes we got asked by the committees like, oh, this was not specified. How is everyone doing it?
Then we tell them, and they may be go after that solution and put it into the standard.
So, I think it can be a really fruitful relationship.
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.
Yeah, that's it about Everest.
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.
The presentation of their different work and groups every week, there's a couple of different meetings for sub-seconds.
Yeah, give us a ping and if you have any questions, let me know.
Thank you.
A four minute for the question.
Thanks for the presentation.
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,
you're not going to cater with the CPU.
Is it something you are planning to cover in the future?
So, I know what you're talking about.
So, in principle, going back to the picture, Everest focuses on the chart on the middle.
The chart for operators are in my symbol, like the yellow dots here.
And the protocols you talk is kind of another layer behind this.
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.
There's a few, like Centrino as a synopsonation, may even in others out there, so they hopefully take care of that.
We're peeding the question, so what is the organization behind the Everest project?
It's a company or community, so my startup started that open source project, like six years ago, five and a half years ago,
donated to the Linux Foundation, like one here later or so.
And since then, we are given the Linux Foundation tools, like 600 people already touched that project, more than 80 organizations.
So, yes, my startup is still one of the drivers, we do quite a bit, but we are by far not the only one.
And so, I think, in some way, we're not the biggest contributor.
We are one of big ones, but there's others which are in total way bigger than us.
Does it answer your question?
And right, how we organize this monthly technical steering, committee meeting, where the high level political decisions are made in consensus,
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,
and then there's Ruler Pshet and GitHub interaction and pull requests, and there's all the details then.
So, it's super hard, so how many challenges are on the field, what's Everest super hard to guess to it?
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,
huge vendor who are in a retrofit 300,000
chargers and within the next weeks.
So we will have the post plan for next end of last year,
but everything is later as you know.
So we will have like 3,400,000 in some days.
And then do you see these vendors actually
support in the maintenance?
Yeah.
Not every vendor supporting the maintenance,
but some vendors do.
And it's like I can name some who already public,
like Alpham from the Netherlands,
contribute a lot to a certain library for a certain version.
Now another vendor is picking up for the next version,
helping there.
Really, wherever someone is interested.
No one pays, no one pays, no one pays.
Then the base for maintenance?
No, no one pays for maintenance.
The maintenance is like best effort.
If you need something super rock solid tested,
you may be able to do it yourself
or find someone helping you.
Yes, I would do that in principle,
about a general business case of economics.
So the business case of Pionics,
we help people to code missing features
if they can't do it themselves.
And we offer hard for modules which are compatible
with errors, offering cloud solutions if they need something
on top.
But every itself, we not make money with that.
The installation isn't making money.
This is just more than a million lines of code
by a lot of people built together.