 Please take your spot. All right. OK. Hello, everybody. My name is Sanne Jansen. Today I'd like to talk about the OpenSmartGrid platform. Maybe you expected Jonas van de Boog had here, but he was sick. So I replaced him together with you. Like I said, I'd like to talk about the OpenSmartGrid platform. Why did we start the OpenSmartGrid platform? I work at a Dutch utility known as Allianter. And at Allianter, we're a power distribution company. So we provide electricity to the houses. We distribute electricity. And we see a changing landscape in the field of energy. Their energy is shifting from centralized production to a more decentralized production. And what we need is more insight in the grid to cope with this change. And one particular example where we needed the OpenSmartGrid platform was for switching the public lighting. What we have right now is a technology called ripple control technology, which basically is a big sender who sends out the poles over the 50 hertz grid. And then you have devices that pick up that signal and then switch on the street lights or switch them off. Not really intelligent. And also municipalities were banging us from a, we like to have more control over the street lights. So then colleagues were looking into a solution to control all those devices and build an app for municipalities. And they found that the existing vendors were very locked up. It was a silo yet high cost on a long term and a big vendor lock in. So therefore, colleagues decided to build our own. And part of that is the OpenSmartGrid platform. So OpenSmartGrid platform is a layered architecture and can be seen as an IoT gateway between applications and devices. So with an application, you can connect throughout the OpenSmartGrid platform to devices. And current use cases include smart lighting, like I said, for municipalities, smart metering. So you can read millions of smart meters, microgrids. We have an island in Amsterdam, which is its own microgrids, a small grid that balances itself. And it's using OpenSmartGrid platform to send out signals. We're also planning to use it in distribution automation, where we want to use it to get data out of the grid to prevent outages or to recover outages faster. Load management is a thing we're working on. That's especially relevant in Germany, where sometimes it's too much solar power. So the start worker, the utility wants to switch off certain solar panels. That could be done with the OpenSmartGrid platform as well. And the OpenSmartGrid platform also contains device management. So you can see which devices are connected. And right now, there are multiple protocols connected to the OpenSmartGrid platform. DLMS Cozen for smart metering, 61 in 50, and OpenStreetLight protocol for smart lighting. So a little bit more detail about the OpenSmartGrid platform. You get web services on top. And every web services fits to a certain domain, for example, smart metering. That domain checks if a command is allowed. Can this application, is this application allowed to access this kind of smart meters? Then you get a core layer, which reroutes the messages to the correct protocol adapters. You can have multiple protocol adapters within the same domain. And that core layer also incorporates all the generic functions, like time synchronization and keep track of all your devices, so a list of devices. And on below, you have the protocol layer, which talk directly to devices with different protocols. Key features of the platform is that it's fully scalable and high performance. We build it so you can scale out to millions of devices if you want to. Since we're a utility company, security is quite vital for us, because society expects us to keep the grid on. So there's state of the art security, and security is built in from the ground up. And there are a lot of security measurements. The platform is generic. I showed you some use cases from the smart grid field, but you can also add your own and make use of the generic framework, what we're having. And it's open source for them. And we try to use as much as open standards as possible, where we can find a good one. OK, so now it's time for a quick demo. Hello, my name is Joep. I work for CGI and part of the development team that helped developing this application. I'm going to give you a small technical demo. Just going to go through it quickly. We have different components through which the messages are sent. We use ActiveMQ to deliver those messages. Our small demo, we've built a device simulator for the OSLP protocol. So we can add devices here and just simulate the messages and the control of the devices. We also have a demo application. So we can see the devices over here. We can add them and control them as well. So I'm just going to add a device. So the device will be delivered to the platform. Now we can simulate the device actually being connected. So I'm going to add it just over here. So this simulates the device actually being connected to the platform. The platform picks it up, so it registers itself. I'm also going to confirm of register and then confirm. So the device is now added to the platform. So we can do stuff with it like this. What this actually does is it fetches the status of the device. So it asks the device, can you give me the status? And it syncs the message. This is my status. So in this case, the light is off. It has no value. What we can do is we turn on the light. It sends another request towards the platform in which it says, well, for this specific device, I want to have the lights on. So it gets delivered to the platform. It processes it. And as you can see in the simulator, the light is now on. OK, thank you for the demonstration. Now we take a look a little bit closer at how it works technically. You saw the demo application on the top and the device simulator below. So our message gets routed throughout the integration layer to the domain layer and to the core layer and then to the specific protocol adapter. To make the platform scalable, we use message cues between all those layers and that makes sure that multiple server instances can grab messages. One thing I'd like to point out is that the OpenSmartGrid platform is not a historian. So it doesn't store data. It just passes through commands. But it does store all the devices that are connected to the platform. So feel free to join the OpenSmartGrid platform, especially if your organization that manages a lot of devices. I think this could be an interesting project to look into and see if it's a feature or requirements. We try to be as open as possible. So we have extensive documentation. Feel free to connect your hardware or application and help to drive innovation. OK, thank you. Now it's time for questions. OK. What's it written in? It's written in Java. I'm interested in the protocol level of layer. Are you guys have multiple vendors, like multiple pieces of hardware? And are you writing individual drivers for each kind of device? Or do you have a box that you bring to your customers? Or how does that work? Can you reflect the question? OK, so the question is, how we do with protocol adapters? Because there are a lot of vendors out there. And how do we incorporate that? So for the public streetlight example, we did a tender for devices. And then a couple of device suppliers showed up. And then we had to adapt the protocol adapter to that specific device. But if you look at the smart metering, for example, and you take an implementation of the protocol as the protocol should be implemented, then it shouldn't be that hard to incorporate it in the platform. But for now, every device needs some attention, some adjustments to make it work. Are you going to open source any of that? There are some devices already. Can we open source the current implementation? We are already open sourced the ones that are available. How many devices do you imagine at the moment? And do you have the big server burn? And do you have all these devices? Currently, how many devices are connected to the platform right now? And do we use the platform? Yeah, we're still in the testing phase for that large rollout for the public street lights. And we're planning to have 20,000 devices connected. And I'm not so sure how many servers are needed for that. Do you know? No, no. But yeah, like I said, you can skill on. So if needed, then you can add more servers. Have you given any thought to providing data back to the owners at smart meters or the owners of elements in the grid? We will pose one question and a second question. Can you talk a bit about why you don't use the project in terms of this choice? OK, so the first question is, are we sharing data with other utilities or data consumers? Currently, at Leander, we have a program called Open Data. And that's a place where we share some information. All the information is shared with the market regulatory systems. So in the Netherlands, you have a power distribution operator that reads out all the smart meters. And you get a different party that produces and delivers the energy itself. So there's a mark mechanism in the Netherlands that makes sure that the data from that smart meter is going to that supplier or producer or consumer. The other question about the data historian, why is not a data historian part of the open smart grid platform? I think there are other solutions to store data and to process it and analyze it. And it really depends on the use case what's the best solution. So therefore, we did it included here. OK, yeah? You said the state of the art security. What does that mean? That was a clue. What does state of the art security mean? Well, we regularly test the implementation. We do certificates. We do signing. We have extensive user authorization model. So in case of the public lighting, we want to give a municipality access to a certain area. Of course, not somebody else there, municipality. And then that municipality can give access to a subcontractor. And that subcontractor can give access to another subcontractor. So there's a fine grain mechanism to authorize certain functions on certain devices. And whoever is running this software gets to control who gets which access. Or does it depend on the protocol to use who's actually kind of it? It depends who gets the side, who gets access. Is that something this software does? Or something that, as you say, for the smart meters, the utility decides and you haven't got any choice about that. So the question is, who makes the decision? Who's allowed to talk to which device? Well, it depends on the operator of the platform. In our case, we run it ourselves. But I hope so, so you can run your own. And then your own boss. If you decide to open source it, you mentioned innovation as a reason, how did that decision go in the company? So the question was, how did we open source it? And how did we convince the management to make it open source? Yeah, I'm personally one of the person that made that happen. So I was already a big fan of open source. So I thought, let's make it my work as well. So I started to give presentations to numerous departments about open source and why should you use it? I think we're owned by the society. We're a part of our government owned. And we have a monopoly. So in that sense, I think it's also fair to share our code, what we produce. And I also think it's a good way to collaborate with others. Because otherwise, you end up in a Vandalok in situation where the vendor kind of decides to a certain extent what you can do and what you can do. And that's not a world I see working well. And then specific to the open smart group platform, I noticed that the project was going on there. So I asked the guys, open smart group platform. I looked on GitHub, can't find it. So our open is open. And then they said, well, Sander, we need to talk. So I told them about open source and why you should do it, and et cetera. And then we went and attend OSCON. And then they said, OK, open source is the way to go and now we're here. Sorry to ask another question. You mentioned an island in the Netherlands where this is happening. What's it called? Pampus. It's a small island in the waters in Amsterdam. It used to be a German fort. And there's a restaurant on it. And they have their own solar panel and diesel generator. And that's kind of stuff. So they want to balance that out. So they got a programmable logic controller on that island. And this open smart group platform gives out precise access to that programmable logic controller. So it's just one controller. It's not like multiple houses, each with their own EMSs or something like that. Is there one controller in that specific island? Yes, yes, yeah, one controller. It's pretty small. More questions? Yeah, go ahead. I was wondering, OK, this is a system running on the server. This requires power. So what happens then, the power is installed immediately. Emergency sort of power gets to the system itself. Because we have some sort of a loop there, right? So the question is what happened if there's a power outage? Well, that's our business. So first of all, we got all the data senders, backups, et cetera, et cetera. We got our private telecommunication network with also some uptime. And if you take a look at the open street lights, for example, the devices are smart enough to load switching schemes on it. So if the platform goes down or the telecom network goes down, then municipalities are not able to ad hoc switch their street lights. But the built-in scheme is still working. And by that way, it should work. You do not manage batteries back up on the server. I know that there are plans for a portable type. They have really big batteries and stuff. I read something in a book, and they arrived something like this, made about storage with batteries from Toshiba. You don't manage also these things inside the not part of the... So the question is, do we manage battery storage? Yeah, the battery storage can be added to the platform as well. 61-850 is one of the ruling protocols in the quote-unquote smart grid field and also supports batteries. And that Island in Amsterdam, Pampus, has also its own battery. And it's connected throughout the RTU for programmable logic controller. How much bandwidth is in full? There's smart metering data. It's a sensor. Any limits, sir? So the question is, how many bandwidth is there with the smart metering? I don't know, but it's not that much. At Allianna, we bought our own frequency and we built our own telecom network, CDMA, but it doesn't have a lot of bandwidth. But most smart meters only read six times a year. So, yeah, that should work. But I'm not an expert in this. Is there any kind of like rules and genetics that you know that you can program alternative lights on at a certain time? Easy, like a console like that? You don't need to put a rule in to turn these lights on at this time or turn these lights on at the same time? So the question is, is there a rule engine inside the platform? I know that there's a limited rule engine in the domain layer, but I don't know exactly the details. But in terms of that switching schedule for public lighting, which is also kind of rule, that can be transferred to the device via this platform. You mentioned this platform being used in a small island. Can you imagine how the use of this platform can be still up in the end, because that's not an example? So the question is, how to scale the platform? Yeah, well, all the layers consist of multiple servers. And when the servers get too busy, then you can start a new one, a new one, a new one, and scale them vertically, horizontally, horizontally. OK, we can take one last question. Last question there. Did you audit the development of Scratch, or did you use any already existing platform or code which were already available? So the question is, did we start from Scratch, or did we use some other code? From the protocol layer, I know that we're using open source libraries built by the Fraunhofer Institute. And we also give them some tasks to improve those libraries. And from the development point of view, we use Tomcat and Spring Framework, and more libraries to make it work. All right, thanks a lot.