Hello my name is Robert. I'm the CTO of FlexiCharge and in this short 10 to 15 minutes video I'm going to introduce you to our broker architecture. So we are going to have a deep dive into the backbone into the technology stack which is behind the broker. So what can you do with our broker? Basically the broker streams OCPP and other data between different services or between different entities in a charging infrastructure technology stack. So the classic use case is to have charging stations, charging infrastructures being connected to a CPMS. So in this case the broker sits between the charging infrastructure and the back end the CPMS is basically proxying or streaming data from one side to the other side. The advantage of the broker is that because you have the broker in the middle you can now also stream data to other services. So at FlexiCharge and the broker has always been an initial implicit part of our architecture and from the beginning we have built our load energy management solutions around this data broker technology. And we are making this now available to customers. So the classic use case how we use the broker at FlexiCharge, our broker, it's developed by the broker, it's developed by us and has been in use for very many years, is that charging stations and CPMS charge point management systems exchange data. And we connect our load energy management systems to these data streams. So the broker allows for these services or enables these services to actually listening and see the OCPP stream. And in that respect, load management system can of course also act on specific OCPP messages, which are sent for example, by the charging stations. And this is status changes. This is for example, also meter values. So what are the actual charge currents of EVs currently charging and then the the load management can do some dispatching. So it will decide based on constraints, for example, specific grid limit, how much a specific EV or charging station should be charging with to not, for example, exceed the grid limit or the grid connection limit. And so the broker in in that situation is not only streaming data, so it's not like a man in the middle listening only, but it also allows to inject messages. So at Flexi charge from the beginning, we have used this message injection capability of the broker to inject messages into the OCPP stream, for example, to set a maximum limit for charge currents at the specific charging station during a charging session. And so basically, this is the whole story or the fundamental idea of the broker that on one side, you can extract, you can receive OCPP data, but on the other side, you can also inject messages if needed. Of course, the broker is not only streaming OCPP data or making OCPP data available to services like a load management system, but also data from entities like power meters, local batteries, so that you can basically aggregate data and have one single data stream for all your data, data from one central point of contact, which you can basically interface to services from one central point of contact, and that is basically the broker. So these other services, we can see that here in the middle here, that that's a broker, here's a charging infrastructure. And then here we have the load energy management system. And then here the classic CPMS systems. And now we have just announced that we can also connect to specific software services. We have just announced the integration of Evercharge, an operational platform based on artificial intelligence. And so operation system based on artificial intelligence, it's basically receiving OCPP data and inject, analyzing or trying to predict charging station, mail functioning, for example. And so the, in that case, it's very similar to what I explained earlier with the load energy management system. Basically the system receives OCPP streams. It's doing some, some AI and algorithms with these streams and some, some analysis, but then it's also able to act, for example, to, uh, for preventive restart of a charging station in case the system might have come to the conclusion that the charging station needs a restart. So that, that is another example where you can see that it, it receives on one side. And then on the other side, when it needs to restart a charging station, then of course, it's also injecting messages. But, um, that's only one example. And, uh, the, the, the, the last part here is that, of course, you can, you can connect your own data lakes to the OCPP broker, uh, at your own analytics tools, um, maybe a third party tools, whatever you use in, in-house for data analytics and for data, um, or operations. Um, the beauty is of course, um, as a CPO, if you operate more than one CPMS, then you have a central system data broker, where you can basically exchange or manage your, your different CPMS systems from one central user interface. So that was a bit the, the, the, the view from, from the top, um, with, with, um, yeah, a bit abstract and not, not technically deep dive. Um, and we are going to do the tech deep dive now. So what is behind the broker? So what is behind this nice picture saying OCPP data broker harmony? Our architecture, our whole architecture is based on a microservice specs. So each charging station, sorry, sorry, each charging infrastructure. So a group of charging stations behind, uh, grid connection point is basically operated by one microservice stack. And these microservices, uh, inside the microservice stack, they have, uh, all specific purposes. Um, they are completely, uh, encapsulated self-contained microservices. So one microservice does not depend on another microservice. Yeah. It's a bit abstract, but that's the way it is. And, uh, for us, um, that's, that's a, that's a great way to, to maintain, uh, microservices to, to, to, to be able to individually, for example, upgrade micro, uh, services while not affecting others. So a charging site is operated by encapsulated self-contained microservices. Um, so that's the basic core fundamental concept behind our architecture. And we'll come back to that in a second. Um, these microservices, um, these microservices, they basically communicate using an internal event-based publisher subscriber system. So there's a local message broker and each microservice within the microservice stack is communicating based on a publisher subscriber system. Um, so each stack has a local message broker, which basically orchestrates the communication between the microservices. microservices that's very important to understand when we, when we later see how, um, we, for example, build VPPs or how we are able to build. a very redundant and and system without any single point of failure so what is what are these microservices so this is um again it's a microservice stack so it's it's one stack but now with the specific functionalities which are built into the stack and what you can see one core element of each microservice stack is basically this ocpp proxy call it um service so that's one service here which maintains on one hand here on the left hand side the connection to the charging infrastructure to the individual charging stations so that's one web socket endpoint and then for every charging station which is connected here to this stack it maintains ocpp web socket connection to the cpms in this case this is monta and then between these two there's a direct message stream so it's a direct communication there's no buffering there's no queuing there's nothing um the the the messages are just fed through how they're coming in from the left hand side here from the charging stations or from the right hand side from the from the cpms and these web socket endpoints they of course listen or forward these messages to the to the local message broker and the message broker and the message broker is basically distributing the messages to services which are interested in particular information so you could think about for example our load energy management or our load manager is interested for example in the information about a state of a charging infrastructure so it will basically subscribe to a specific topic a specific channel from this local message broker which is the status of a charging station and then it can based on that it can do some load management it might as well also subscribe to ocpp meter values so it gets the actual charge current and then it can provide load management through that these endpoints here they also subscribe to specific messages ocpp or messages from other services which they should inject into the message stream and one of these messages is for example the smart charging profile which our load manager will send public service and the web socket endpoint here which is connected to the charger and the web socket endpoint here which is connected to the charger will see that message and actually forward or send it to the charging station other services in the stack here for example connect for example just their own they have a specific purpose and the purpose for example is that they they connect to a power meter via modbus TCP and the the the the the the only thing they are doing the whole time is basically ensuring that the connection to the power meter is maintained and deliver for example power consumption current current current current values current consumption values at the grid connection point and will feed that into the system so they will publish every second for example what is the current on the l1 l2 l3 and whatever other service might be interested in that information can subscribe to the information and can do something important to understand this so again why why do we do this with with individual encapsulated stacks this is to provide no single point of failure so each stack as i said a number of charging stations and typically this is charging stations which are the same grid connection point which are behind the same grid connection point are managed by one micro service stack so if you have four sites then four stacks will then each side will be basically be operated by an individual micro service stack so there is a local message broker there is a local message proxy there is a local load manager there is a local service for integrating power meters and so on and so forth so in that respect if one of these fails it means that there is only two or three charging stations failing but not the overall system so we have designed it in this way basically to prevent a single point of failure the country's moving forward to it so further use it in this way so we have limited screens offering but if you rad to based out there are also any CAS instance batteries or other local entities where we need a local connection by a local LAN and then Modbus for example then the FlexiCharge gateway is used to host that individual stack on the gateway directly and here and that's a bit of a special case I don't want to talk about that here we can also have only specific microservices running on the gateway locally and others we can host on the server so we call that a hybrid so then two three microservice for example to integrate a power meter are hosted on the gateway but the proxy and the connection to the charging station and the connection to the CPMS for example runs in the Microsoft server in the Microsoft Azure server cluster that's that's also an option then we have a full microservice management system behind it so these stacks are monitored and managed by microservice management system and that allows us to dynamically migrate microservices so for example if we have a server here and that server needs maintenance whatever security update or something then we can during runtime actually migrate the containers and put them onto other servers while that server is maintained but the system the microservice management system is also able to detect faults if a stack has has problems has crashed or something it will automatically restart it run it and run it on the server where where space and memory and so on and so forth and we can remote update all the individual services from from that microservice management system so that's a really powerful tool behind this infrastructure to to to operate our microservice stacks so as i said earlier already these microservices are these individual stacks they are all interconnected so not only as i explained earlier i each microservices here be interconnected by a local message broker but the local message broker they are also itself connected to one central micro uh uh uh to to one central message broker which we run in avs so this is now in amazon web services and that's sort of our back-end system and through this central micro uh to this central message broker we can actually make all information from local stack so everything which is exchanged here on the local stack we can make actually available by an api or to buy direct message bus access so here you can connect your own systems or you can or third-party and you can also see the other tools like like evercharge are connected but you see that um i mean it's it's from from from from the the the micro service up to the full overall architecture it's it's it's built in a way so that it's fully resilient um redundant uh and and and and secure um these stacks even if let's say something goes wrong in the back end here communication breaks or something these stacks will still operate independently so they do not depend on on on each other but we can interconnect them and we can actually interconnect them to for example build um vpps i will i will explain that to you in a second there's of course a much more here in the back-end system there's also databases and so on and so forth but the the the the general um uh uh architecture is is exactly as i'm i'm showing here um yeah so with respect to message flow uh two three sentences to that so one key central element of course is ocpp and this is now specific ocpp message streams so we can basically through the broker now abstract here shown as our harmony platform but you now know what is behind it so we can stream um ocpp data the classic way back and forth between the cpmf and the charging station um next quarter uh q1 25 we will be able to even split the streams here so we can send ocpp messages from the charging stations to not only one but two back-end systems at the same time this might be might be interesting if you if you test new cpms systems or there's an update of the cpms system which you don't want to roll out immediately but you want to test first of course um you can you can have not only one cpms system but for for each charter you can have basically an individual one and then we can stream to to um other to our own services which is for example load energy management or vpp um that the pirate power plant uh virtual uh power plant i will explain that in a second as well uh specialized cpo services like evercharge i explained it or you can you can have your own data lakes or analytics tools or operations tool connected to the broker um as i said earlier uh due to the fact that we can enter interconnect each uh individual micros microservice stacks or each individual sites we call them we are able to uh have um to be able to to control centrally for example the maximum charge currents or the maximum power drawn by a specific infrastructure from a central point and that is our central message broker and the top of the central message broker we we are having our vqp control layer so you can combine sites individual sites here into virtual power plants we um with our charging analytics tool we can provide you the information what is the load we can provide you for for example if you want to participate in frequency curtailment reserve what is the capacity of your complete charging infrastructure portfolio so how much flexibility can you bid that you will be able to kit into the grid to participate for example in in fc fc r d for example and then this vpp control layer will make sure that when an activation comes through that all infrastructures are drawn down or driven down by a specific amount for example half a megawatt 100 kilowatt or whatsoever so that's a really powerful tool or architecture which is which is i i think also unique in the market we are the only ones which can do that and again remember this also includes local stacks which are which run locally on our gateway it includes stacks which run in the in the micro microsoft azure server cluster so that's that's very powerful um um architecture i i would say um and um yeah then on top sits of course our harmony platform user interface and so on and so forth but um in this presentation i'm not gonna gonna dive any deeper into that um yeah basically um i think uh i i i came to an end now or i coming to an end now um why we are the right partner um we have been from the beginning been been focusing on ems energy management solutions load management we have a hundred percent cpo focus um we have a future proof architecture i mean that's up to you to to evaluate but but um we we always have tried to build the architecture so it's fully scalable it's very flexible and it is easy to scale not only in terms of of charging stations or customers but it's also simple to scale functionality to to add functionalities and and we'll see more functionalities in the future um we have a long history um and long experience um due to that we have been using the broker for several years now and has been an implicit part from the beginning from our load energy management um solution so it has always been the the the data carrier in our system so so it's very mature we have the experience and um to to with ocpp communication and also web socket connection to cpms and and charging stations so that basically puts us on the same level as as as as cpms systems i would say in in terms of that and then of course um it's one solution to to to cover it all um every uh charging station is compatible every ocpp cpms we can integrate other data streams as well um power meters or other data uh we are vpp ready and um yeah obviously there's there's there's many more things in the pipeline to come we can integrate batteries um yeah so that was the the deep dive uh thanks a lot uh if you have questions uh feel free to contact me my my email is here um thanks a lot