The Power of Broker Architecture for CPOs: Part II

Welcome everybody to this second masterclass on our OCPP Broker. We'll get ready in the next 30 seconds. We'll let people find their seats, take a cup of coffee, a glass of water, make yourself comfortable before the masterclass starts. Hello, everyone, and welcome to today's webinar. My name is Christophe, and I'm Marketing and Growth Director at FLEXICHARGE. I'm glad you could join us for the second session in our masterclass series. In December, we kicked off things with a high-level introduction. For those who joined the first one, remember, it was a high-level introduction to our OCPP broker and its role in a charging operator's technology stack. Today, we're taking a step further with a deep dive into the architecture of the OCPP broker, which sits at the heart of reliable and efficient EV charging operations. This session will explore how the broker ensures seamless integration with third-party services, how it manages data flow, and incorporates advanced load and energy management solutions like ours. I'm pleased to introduce Dr. Robert Braim, co-founder of CTO, who will be leading today's masterclass. Robert will provide an in-depth look at the technology behind the broker and share practical insight into its design and functionality. If you have questions, as always, you can drop them in the chat, or you can also use the question section. So let's get started. Robert, the floor is yours. Yes, thanks a lot, Chris. Yeah, welcome, everybody. As Chris introduced me already, I'm Robert. I'm a CTO of FlexiCharge. I'm one of the co-founders working with FlexiCharge now for several years. And yeah, today, I have the pleasure to give you an inside view into our architecture. As Chris said, last masterclass, we had a bit of a broader perspective view. We looked into advantages, disadvantages of a broker. Architectures, and at the same time, also into challenges for CPOs and how to tackle them and how broker or brokerage platforms can help solving these problems. So today, I'm sharing my screen, first of all. Good. Can you see it? Chris, is it visible? Yes, absolutely. Yes, yes, yeah. So what we are going to do today is a quick recap of the first masterclass, just to get the mindset into a broker, architectures, advantages, and challenges for CPOs. Then I'm going to give you a deep technical dive into our broker architecture. So how we have designed it and what have been the sort of ideas behind the design as we have it right now, how our load and energy management solutions are integrated with the broker, tell a bit about the history, why we have been using a broker, because our core product still is load energy management. Then I'm going to explain how data flow happens inside the broker and how external third-party services can be integrated. So how messages can be extracted from the broker or from an OCPP stream and how messages can be injected. We're going to have a look into a very important topic, which is reliability, redundancy, security, and later we have to have a quick look into aggregation of charging infrastructures into virtual power plants based on our architecture. So what have we discussed the last time in the last masterclass? We initially looked at the classic communication stack in OCPP, communication stack where you have the EV on one side, you have the chargers, and you have the CPMS, you have all the roaming connections, DSO control. And yeah, we came to the conclusion that for CPOs, that's quite many systems to orchestrate these days. And the focus for CPOs, charge point operators, of course, is cost revenue optimization, scaling, rollout, site planning, operations, maintenance, support, user experience, excellence, security, innovation, internationalization, energy and load management, DSO control. And what we can see in the market now is that there has been a shift from the classical architecture where the we have the classic data flow from the charger to the, sorry, from the EV to the charger, from the charger to the CPMS to the roaming partner, and the whole way back that we see now more and more software as a service solutions coming into play, for example, for their predictive maintenance, for site planning, for load and energy management, like the FlexiCharge solution, often CPOs are challenged with the need of not only operate one CPMS, but many, specifically those which scale internationally, but often also we see that for national CPOs, which use different CPMS solutions for different segments, for residential charging sites, public charging sites, then we have the whole on the top, the DSO integration, which need to be handled by CPOs. And one solution to tackle all that is, of course, an energy or data brokerage platform, as we have introduced it in the last masterclass. So basically being able to have a central data capturing and data processing system, which can, yeah, forward information to different, yeah, to different systems, to third party systems, to load energy management systems, being able to integrate with different network operator and different requirements or interfaces from network operators. And finally, also being able to integrate to several different CPMS. So at FlexiCharge, sorry, I missed that slide. So from the classical architecture, as I explained before, so EV, EVSE, which is the charging station, now I think the more modern, and we actually see that for enterprise, big international CPOs, these sort of architectures are preferred for the reasons I mentioned before. So for, yeah, for modern architectures, we see the broker here between the EVSE and the CPMS as a data exchange, data brokerage solution. At FlexiCharge, we have, I mean, our main focus has always been, or still is, load energy management solutions for CPOs. And from the beginning, we had built our system around the data broker. We never made that available to our customers, but we have been using it for many, many, many years. And it basically shows what advantage, what sort of advantage a data broker can bring. And for us, for FlexiCharge, and for our customers, a major advantage is that we can provide an open load energy management solution to our OCPP data broker. So in principle, we can connect any charging station, which is OCPP compatible, and which supports OCPP smart charging profiles. Connect that through our broker to a CPMS, and then you can see it here on the right-hand side, be able to extract information from the OCPP data stream, and basically react on it by providing load or energy management. So controlling the charge currents of chargers via OCPP. So that has been sort of our core initial solution. And what we have done now since the end of last year, we have actually opening this data broker to our customers to be able to integrate their own data analytics tools. For example, we see also a trend for bigger CPOs, which are building their own data warehouses, data lakes. They want to have unfiltered raw data, OCPP data, but also energy data or power flow data. So that's obviously possible through a broker. Then certainly, it's obviously also possible with a broker to integrate third-party solutions, software-as-a-service solutions, like Available is one of our partners, which can be integrated through our OCPP broker. So in general, the idea is to provide the broker platform to open new revenue streams for CPOs, have an easy, simple, off-the-shelf integration for load and energy management, be able to plug in third-party integrations, provide grid services, energy market integration, ensure adaptability to DNOs and market dynamics and regulatory requirements. So that's basically what we discussed in the first masterclass. So what I would like to do now, of course, this is a very abstract view here of our data broker. You see here on the left-hand side, the charging stations are connected. The data goes through the data broker, which then makes it available to these components here on the right-hand side. So inside our broker, how is our architecture? How is that broker being built? Or how is the whole FlexiCharge technology? What is it based on? And it's basically based on microservice stacks. So what we are doing is we are using microservices, and we stack these microservices into stacks. And each of the microservices is actually responsible to provide a specific task. I will get into that in a second. So what we are doing, so when you use the FlexiCharge data broker, one prerequisite is that we group charging stations and local energy assets into sites. Basically, that's everything which is connected to the same grid connection point. Because still, we use, and we do that, you will see that later. One reason why we do that is to ensure we're not having a single point of failure. And secondly, to be able to provide load energy management and comply to local constraints. So we are grouping charging stations and local energy assets into sites. Everything which is connected behind the same grid connection point. The site is operated by the encapsulated and self-contained microservices. And each microservice inside the stack has a specific purpose and a specific task. And this stack then operates a number of chargers, including, for example, energy assets like power meter integration. So reading external building load or integration of batteries. PV panels and so on can be done, but not necessarily needs to be done. These microservices, what are they? Here's an example. We have a specific microservice which provides a load management. We have a specific microservice which provides an energy management. We have microservices to interface with local assets, to read power meter data, to control batteries, to integrate to solar inverters, and one microservice. And now I'm closing a bit the loop to the broker story, which provides a local OCPP, or which is a local OCPP message broker. These microservices, they are internally communicating via an event-based publisher subscriber system. Each microservice stack has an independent local message data broker, which provides data brokerage or communication between the microservices. And the beauty of this solution is that each of these microservices can operate completely independent. So it is not dependent on any of the other services. It is dependent on information from one of the other services, but it's not dependent on, how to say, the runtime if another microservice is running or is not running or where the information is coming from. And that's one of the beauties of a publisher subscriber system, that they are completely decoupled. So what we can do with these microservices, we can independently, for example, update them. We can restart them without affecting any of the other microservices. And that's one of the big advantages of this architecture, broker-based architecture. And we really lift the broker from, and you will see that later when we look a bit more into the macro perspective, that we use, we lift that from the, from the small microservice stacks towards the overall global architecture or platform, as you will see in a second. So if we look more now into the functional, look inside these microservice stacks and you will see what is, what is, how, how, a functional diagram of the microservice, how it's actually interacting and how these microservices are interacting. And one of the core components of a microservice stack, again, remember, which operates a site behind a grid connection point, is this local OCPP WebSocket endpoints, which, which provide data exchange between the charging stations and the CPMS. So that's one of the core elements here. So the charging stations, they connect to WebSocket endpoint, just in the same way as they would do for any CPMS. On the other side, for any charging station connection here, WebSocket connection here, the system will establish a WebSocket connection to the CPMS and stream data between the two here. There is a data pipeline between these two WebSocket endpoints, which forward every OCPP message from the charging station to the CPMS and which streams any data from the CPMS to the charging stations on the other side. There is no filtering. There's nothing. There's no delay. Messages are just fed through like in any routing system, so to say. Now, a central element of the microservice stack to operate a site is the local message broker. So these WebSocket endpoints here, they see OCPP data stream from the charger, from the CPMS and can provide information about this OCPP message. So the message contents to the local message broker. So they will publish information, for example, if charging station sends a status change the WebSocket endpoint will publish that on the local message broker. This charger has changed the status from available to preparing. Or if a charger sends OCPP meter values, it will send that information on the broker. Then there are other services which can subscribe to these information. And the best example is a load manager, which will subscribe to status information that will subscribe to OCPP meter values information. So what is the actual charge current? So at any point in time, the load manager, due to this local message broker to these WebSocket endpoint information has a complete picture of what is the status, what are the current charge currents at the particular site, and it can react on it. So it will publish, for example, for a particular charging station that it should change the charge current. So these WebSocket endpoints, they not only publishing information from the OCPP stream into the system, they also subscribe to particular information from the load manager to, for example, change the charge current for a particular charge point. If that message comes in, it's published by a load manager that the charge current should be changed for a particular charger. The WebSocket will generate an OCPP message, send it to the charger. It will rate for the accepted message. It gives the feedback and then the load management is done. So that's the example how the message extraction and the message injection into the OCPP stream is being done. Based on our load management system. But obviously, you are also able to inject other messages. I mean, we are also able to inject complete OCPP messages. If any message we want as a row OCPP message into the OCPP message stream here. And obviously, also, we are able to extract any OCPP message and make that available. So this is how we can do it. The core microservice stack actually works. There are other services now. I've drawn them here. So you can, there are services to integrate, for example, with local power meters. And all these services is doing is actually make a Modbus connection to the power meter, read the power meter data, stream it the whole time. What is the current consumption at the grid connection point or for building or for PV panel? And the load manager again will subscribe to that and digest and process the data. The same with the battery integration. There's a specific service to integrate the battery and control charge discharge current of stationary batteries. In addition, we are able to integrate local software as a service APIs to particular microservices. So to recap a bit, why is it built like this? And one reason is that we didn't want to have a single point of failure. And doing this microservice stacks, it gets very clear that per site. So again, number of charging stations behind the grid connection point, there is this one web socket connection. Endpoint here, which could be a potential single point of failure. But due to the fact that we operate one microservice stack per site, if one fails, then you might be losing like five or 10 charges, but you're not losing your 5,000 charges, right? So that's one of the reasons why it's designed like this. These microservices, now you might ask, yeah, but these microservices is a bit weird thing. Yeah, it's software, obviously, but we operate these microservices on server clusters and we actually distribute these over server clusters. So what you can see here, each microservice is hosted on a server and all the microservices, they are distributed over many, many, many, many servers. And these servers also provide redundancy. So if a server goes down, for maintenance or for example, these microservices, they can be migrated and they can also automatically migrate. If a server has a problem, it crashes. There's a system behind which can detect that the microservice goes down a stack and it can migrate it to another server, spin it up again. And then within 30 seconds, the service, the complete service and the complete site is up running again. And obviously with that, you can reach really, really high uptimes and provide really reliable operation of charging infrastructures. Another advantage of this microservice stacks is that we can run them locally as well. So we can run them on central servers, server clusters from the cloud. Then we provide load management from the cloud, but we can also run them on local industrial PCs. That would be our FlexiCharge gateway connect, we call it. Then the complete stack, including all the load management, everything is running locally. Now that is necessary if, for example, you want to integrate local power meters or you want to integrate local PV panels, or you want to integrate a local stationary battery, or you just want to have your load management running locally. So with that, all these microservice management, all these stack are managed and monitored by a central management system, which can migrate, update, complete stacks, but also single services, and which can also detect faults. If one goes down, it can spin it up again. Now, coming back to the broker. I mean, this was more like the reliability security part. Or redundancy part. Now, we talked a lot about the central local message broker. Now, your question might be, okay, that's all nice, but now I have like, if I have 500 sites and I have 500 of these microservice stacks running, how can I get my data? How can I, for example, provide the data to a third party software as a service provider, like available or any other? Or how can I extract data, OCPP data? Or how can I get the data from all my power meters from a central interface or from a central connection point? And the way this works is that each of the microservice stacks here, the local message broker, which is built into each microservice, is mirrored into a central message broker. So we have a central data backend system where every microservice, every stack, every local message broker is basically mirroring all the local communication into a central message broker. And that message broker, of course, that central platform now is able to provide from hundreds of thousands of these stacks and sites centrally through an API or through direct message bus access data, whatever you wish. So it can get all the OCPP data stream into here, into a central part, into the central backend system, and you can access it here. Or the power meter data, or the charging, whatever. Everything, what is happening locally here. And since there is a local broker, which basically aggregates everything and gates all the messages or routes all the messages locally, so that's all the information you can ever get and you get them all centrally. And then that data can not only flow one direction from the microservice stacks towards your own data lake or a third-party system, or you just want to access it through the API, but it can also go the other way around. So what is possible is from the API, you have access and control to any local message broker and you can inject OCPP messages or other things into the local microservice stack and you have the microservice stack processing the data and actually acting on it. In the simplest cases, you can just send a row OCPP message from here to any of your chargers in the field. To, for example, hard reset, soft reset, or do whatever. Yeah. And that is what the central or overall overview of our broker architecture is. One of the advantages or one of the things we are using this central message broker to is to build a VPP. So we are able with this central message broker and being able to aggregate sites, so local microservice stacks, and at the end of the day, hardware chargers into VPPs and being able to control, for example, for a number of sites, what should be, for example, the maximum charge power or we can, the current load on like a thousand chargers separated over a hundred sites. We can lower by 10%, 20%, or we can lower by half a megawatt or whatsoever. So there's a central interface here to be able to control or, yeah, control charge power or other things for chargers as a total. Yeah. I think, that was it. I don't know what the time is. I hope I'm still in time. Yeah. It fits. So this is basically what I wanted to share for today. We'll have a third masterclass where we'll look into the broker integration process. So how you can integrate the broker into your existing communication technology stack. What are the options for the broker? For hosting? How you do your own data warehouse integration and how you can integrate third party software as a service solutions on the fly. That will be the topics for the next masterclass. Thanks for listening. Yeah. Yeah. I wanted to mention, thank you, Robert, for the masterclass. And I wanted to mention that the fourth will be about the close collaboration between the broker, and the CPMS, which is a key topic, obviously, given the, the strategic, I would say, positioning of CPMS in the technology stack. So I will make sure you people will be again, invited to the, to the next one. So you don't miss. But before we close, there are a few questions. And again, now is the time to ask your questions, even though you can always reach out to us afterwards. The first question that was from, from, from Job, which asks, do I interpret your infrastructure correctly that you also build tools or functionalities inside your broker? How are you then able to track changes, messages sent? I'm not sure I understand the question. Yeah, I guess about the, you have also built tools or functionalities inside the broker. So I guess maybe it's alluding to the charging analytics. So what are the tools that are inherent to the broker that are part of the broker? Yeah, well, yeah, one, one of the tools is for example, our charging analytics tool, which is presenting or it's a basic, how you call it charting or data provisioning tool, visual data provisioning tool based on the broker. But the broker as such is raw. I mean, that that's a, that's the rawest thing you can have. I mean, there's nothing built into the broker to do something with the messages or to filter or whatever the message broker as such as raw. I mean, and then it provides data to yeah. Other services like for example, the charging analytics. I hope that that answers the question. Yeah. Well, you either, you can chat now or you can continue. We can continue afterwards. I know we, and then the second question is from Evangelos. So nice to hear that our webinar is also reaching to Greece. So he says, since you have a charger, CPMS communication through local message broker, why do you use the WS to WS direct communication as well? Isn't the first enough or sufficient? Again. Yeah. If you talk about the, if you want to talk about the secure web sockets. Yes. Yes. There is two. There's obviously two ways of how we are hosting. The microservice stacks. One is from the cloud. So then they are hosted on a server on the server cluster. And then obviously when the charger connects, it will connect to one of our servers. Yeah. And then you will make the web socket connection and that server is somewhere in the internet. And then obviously you make a secure web socket connection. If however, you use our flexi charge gateway connect locally, then it's part of a local network. And then the chargers connect also to the gateway locally. And then obviously you don't need to secure a web socket connection. Yeah. Hopefully it answers. Yeah. Otherwise, otherwise I'm happy to. Yeah, of course. Absolutely. Yeah. We are available. Evangelos, you can reach out to us. So we'll also make sure in the follow-up emails to, to put a link to the, to the handouts. I guess if people want to have your slides or at least we can request them. We're happy to, we can follow up. It's a complex topic and exciting topic. So we, we love questions follow up. So on that note, thank you very much, Robert, for this masterclass and wishing everybody a great afternoon. Thank you. Thanks a lot. Bye. Bye. Bye.