 So, I would like to introduce our next speakers, which are WUHA, David Traffula of Sunezis and Nikolai Kandelari of Cyber Grid. And they will discuss open source interoperability for distributed energy storage and other flexibility resources. Thanks to you, you can start now. Thank you. Good morning. So, like they said, we are Nikolai and David. We are for the record both students still. So, please have mercy on us with questions. But then today we'll present you the project interstore and its goals in which our companies and many others are participating. So, the start on the market, on the grid, there are many protocols for the distributed energy resources integration. And this is both a good thing because many protocols means you can integrate many different resources properly. But also it can be a challenge or a problem even because the different protocols and their different implementations of which there are many are hard to connect, to talk to each other. And then there's also a big need, a bigger, well, a rising need for the data exchange, you know, in many use cases around projects and also in real-time scenarios. We see the rising need for that. So, these two challenges brought the wise men of the consortium of the interstore project to start working on the objectives of interstore which are basically the solution for these two challenges. So, the development of an open-source software which would help for easier intercommunication between different protocols. And this software would be then developed on three levels. So, but all three levels would be via NETs and the data model would be IEEE 2030.5. Now, why we will use NETs and not maybe REST, which is more common and why IEEE will leave that to David. But what I can say is that the three software developed will look like this. So, one of the software will be the legacy protocol converter. So, for the existing communication protocols and the conversion to it and then we will develop client-server protocol for the newer. So, the one to be integrated in the grid. And also the third thing we will develop is the protocol certification for this new protocol so that the integration is as seamless as possible. Now, this is the first objective. The second, as I said, is the push for more bigger involvement of data exchange. And the third would be the further integration of distributed energy storages for which we can say batteries, but also many others, into the grid. So, just a quick recap. The full title of the project is Interoperable Open Source Tools to Enable Hybridization, Utilization, Monetization of Storage Flexibilities. The founding mechanism is through Horizon Europe project. The project started this January and will last for three years. And the budget, the total budget is 4.3 million euros. Because of the challenges and objectives, the partners involved in the project are different. You know, I'm coming from CyberGrid, which is a company from industry. And then David is coming from Small and Medium Enterprise, also working in industry, but then there are also some universities. Like the coordinator, the Ahan University. And we have also many other institutes, research and development institutes. Well, the objectives will be... We will work on the objectives in two pillars, in a system of two pillars, which means that we have two basic support structures to the objectives you want to have. The first pillar will develop the open source software and the three implementations of it and also have a push on connecting the data to the open data spaces. And then the second is more practical, more practical connected to existing infrastructure. And we'll develop the already used energy management systems to new levels so that there is an implementation of this new software and also the push for the storage systems. And then using these new tools, the developed energy management systems will try to get an advantage on the market. So we will develop the software, we will make a new generation of EMS, so energy management systems. And then you know to check if everything also works in practice. We have nine use cases, you can see them here on the picture. And you may also see which software, developed software will be used in which use case and which EMS on your right will make sure that the software is properly integrated. And then the use case shows the benefits of it. So here is just a grid. I can also show you here the even more practical case, so a case of this. So as I said, I'm from CyberGrid and we have an EMS CyberNock which really basically helps the aggregation, is an aggregation platform for the distributed energy resources plus it then markets flexibilities from these resources. And we will use these to help the energy community to achieve greater sustainability and then trade the excess energy on the different markets. So what is IEEE 2035? It is also known as smart energy profile that was developed by Institute of Electrical and Electronic Engineers. It is basically a communication standard that involves a range of applications such as demand response, load control, time of use pricing and the management of distributed generation and electric vehicles. In more technical terms, IEEE 2030.5 defines the application layer with TCPIP providing functions for transport and internet layers. It interacts with various physical layers and a variety of lower layer protocols may be involved to provide a complete solution. The standard also defines the mechanisms for exchanging application messages and specifies the exact messages including error messages that are exchanged. It was designed to support a variety of use cases in the domain of the smart grid technologies. This includes supports for distributed energy resources, electric vehicles and customer management systems. It's capable of conveying price signals, demand response signals and other relevant information from the utility to customer devices and vice versa. These two communication allows for better coordination of energy generation and usage. It was designed to basically, the standard has a potential to play a significant role in the transformation energy sector, especially with respect to the integration of renewable energy resources, electric vehicles and the general shift towards more interactive and dynamic energy generation practices. Some advantages of the standard are that it promotes interoperability because it uses common language and format for data exchange, so it makes it easier for devices from different manufacturers to communicate between each other. It's also flexible and extensible as it allows addition of new functionalities and capabilities as the technology involves. It also supports the concepts of demand response, load control, time of use, pricing and other initiatives that make up a smart grid, improving grid efficiency and reliability. It is also easily integrable as it is built on widely used technologies and protocols such as HTTP and XML. Here in this image you can see global interest in IEEE 2030.5 as of May 2021 and in the future we expect this to grow exponentially. Neural Autonomic Transport System, or NETS, is an open-source, cloud-native, messaging system often used in distributed systems, microservices and IoT networks. It is designed to be simple, secure and high-performance with clients available in a variety of programming languages. And even though IEEE 2030.5 uses rest for communication, we will use NETS because of its properties. It is designed to be lightweight and fast, providing high-throughoutput and low latency, which is crucial in real-time systems. It also supports published subscribes, point-to-point communication models, which are asynchronous in nature, so it doesn't create performance bottlenecks and it doesn't block processes. It also promotes loose coupling between services as it uses a messaging system and it doesn't require knowledge of the endpoints and it also supports real-time updates through its published and subscribed model. It also has the advantage of having built-in mechanisms for handling failure such as automatic reconnection, message-free delivery, and queue groups for the distributing load and ensuring continuity of services. Last but not least, it is also simpler than the rest, which has multiple conventions and standards because NETS has a minimalistic design philosophy and a straightforward API. Our project or our toolkit will consist of two solutions, client-server connectivity and legacy protocol converter connectivity. In client-server connectivity, energy devices will act as clients and utility companies will act as servers. Here, basically, devices will send data to the servers using NETS, implementing IEEE 2030.5. This solution is more suitable for grids that are being built and for devices that support custom execution of programs. The second solution is legacy protocol converter. Basically, here, legacy protocol converter will act as a middleware between energy devices and utility companies. Here, devices do not send data directly to the servers, but they send the data to legacy protocol converter using Modbus or MQTT, and then legacy protocol converter will convert this to NETS or MQTT, both implementing IEEE 2030.5. And then legacy protocol converter will forward this data to the utility companies. This solution is more suitable for already established grids and devices that do not support execution of custom programs. Basically, here, legacy protocol converter will act as an aggregator. Our project will be open source available on GitHub. It will include a reference implementation with test procedures, and I would like to emphasize that everybody is welcome to contribute to the project once available. The first version will be available in March 2024. So the idea is that we develop the software for the first part and then the first version, and then we really, if we want to achieve the breach between different protocols, we need your help. We will need an open source community, build an open source community and have as many participants as possible to really reach different aspects, which we will not cover during these three years of development and really achieve the interoperable status we want to have. So for any of you who would like to participate afterwards in the community building part, you're really invited to come to us after the presentation and we can discuss it further. That's it. Thank you. Okay, we have a lot of time for questions. So please, if you have any questions, that's the right time. Yes. Thanks for the talk. Really interesting. I really think it's a really good use project to work on. What was not really clear to me is where does the legacy converter part of the code, where does it live? Is it on device or is it in some kind of backend store? Well, basically it will live on some kind of IoT gateway. Okay. It can also live on some main device to get all the data. But usually it is designed to live on a gateway, but also it can really live anywhere. It will be a microservice so it can be in the cloud or it can be even on device. It will be designed to function on the devices in constrained environment so it wouldn't take a lot of resources, and so on. And after that, just sending it through to the end receiver part then? Yes. Yeah, cool. Okay, thanks. Also here just to say, the legacy protocol converter will also have many different ways of implementation, not just one, in order to have it as big an effect as possible. Yeah, I can imagine that it's custom code so you don't really want to have it downloaded on a device itself. Just send the legacy protocol to the gateway and then parsing it. Cool. And although all those different mappings from the legacy to the end protocol is open source and managed by managing the Gitter project, I think then. Yes. Basically the biggest challenge is mapping from Modbus because each device has different registers with different function codes. This will be the biggest challenge, but with MQTT it's pretty straightforward. We have topics so it's a lot easier than Modbus. Cool, makes a lot of sense. Thanks. Are there any device manufacturers currently busy with implementing the IEEE 2035 standard in the devices? Invert company, you mean? Not just any device like solar inverters? No, there were many talks and there are still many talks and some come back and some say yes and no. But no, for this time, no. Which is a shame, right? Because we really want to have them on board and have a first person experience of what the device looks like behind the hood, let's say. I had a question about the choice for 2030.5. We are from a DSO and obviously focus a lot on 61850. What's the difference or choice between 2030.5 or 61850, which also standardizes DR integration? Why did you choose for 2030.5? Because it's supposed to be newer and there's also a lot of... It's supposed to standardize the communication in a more general way and it's supposed to include a lot more devices and there are already some use cases in California and Australia. But yeah, basically it's... Yeah, I think California and Australia are standardizing on this, indeed by legislation also. The European Union, it's a bit of 61850 and a battle between those two standardization bodies, I guess. Yeah. As much as I have read on this, I think the difference is also that IEEE was made for distributed systems, which we also focus on. Distribute energy resources storage resources, storage systems. And the second one, I'm sorry, I don't know the correct name, so I will say the second one, it was developed after to integrate this part and IEEE was designed for this, so I think this is the difference here. Any other question? Thanks again. The next topic is actually canceled because Abhishek Kumar could not make it today, so sorry for that. So we're going to come back at 2 p.m. for another talk on C-PASS, more technical by Matthew and Florian from RT. If you have any questions regarding the left energy, I think we can definitely answer to some of your questions because you may know that this group of the Linux Foundation is quite new. Definitely I encourage you to join. There is many projects. You have just a sub-overview today of the projects of left energy, but I can say that there is many projects coming. They're very interesting in a lot of different areas. Today we saw already Everest and C-PASS, but there is some others. So there is a few open source governance, so I encourage you to join. Okay, thank you.