 All right, everyone. Thank you so much for being there. We'll start right away. So my name is Frédéric Davien. Frédéric Davien, Fred, Blueberry, whatever suits you. And I'm the program manager for IoT and Edge Computing at the Eclipse Foundation. And with me is? I'm Shweta Nidodi. I'm a software engineer at Pacific Northwest. And yes, this morning, we'll have the pleasure. Well, it's technically the afternoon, right? So this afternoon, we'll have the pleasure to tell you a bit about Eclipse Voltron and how you can use that for digital building and as a generic energy management platform in your IoT projects. First, if we take a step back and think about IoT or even embedded systems development, there are a few characteristics when you have projects like that. Obviously, the lifespan of those things will be long because a digital building is not something that you will throw down after two years and start over again, right? Building is a long-term project. Typically, those projects are heterogeneous. Nobody in the market can give you all the sensors, software, and support that you need in a single step. So you will need to deal with various people. And obviously, IoT is about connectivity. There's always some sort of networking. But the defining characteristics of IoT digital building projects is that you have constraints. And power constraints are probably the most significant one. In fact, typically, your power budget will infer what kind of processing power you can have and vice versa. Sometimes, you will have to pick a lower power processor in order to fit the power envelope and vice versa. So power is important. And when we think about digital buildings, obviously, there are two big questions there. So first, how energy efficient it is because cooling, eating, ventilation, all of that is one of the big expenses that you have for any building and specifically for digital buildings. And obviously, looking forward, how will my digital or smart building will integrate with the smart grid? And we think we have a pretty good answer with Eclipse Voltron to both of those questions. And the whole point of the presentation is to show you why. So first, what is Voltron? So Voltron is really a software platform for distributed sensing and control applications. So this is not just about measuring stuff. This is about controlling stuff as well. Voltron, it's important to remark, is not a specific protocol. It's rather a platform that supports many of those protocols and will integrate with the VAVs and whatever if you are already in the digital building space. So whatever equipment you have to deal with, it will integrate with them. And specifically, it supports Modbus and Backnet as two of the leading things that you will find in the market. Voltron is an open source project, so completely open source, permissively licensed at the Eclipse Foundation. But it didn't start at the Eclipse Foundation. It is a project from the Pacific Northwest National Laboratory, so hence my co-presenter, Sweeter. And it's been contributed to the Eclipse Foundation last year, essentially. So we are quite happy to have it. And it's really, in our opinion at the Foundation, one of the core projects, one of the most important projects that we have. And an important thing is that Voltron runs on Linux. So you really need Linux to run Voltron. And there's every tight integration between it and the platform. All right. Now taking a step back, if you weren't aware that the Eclipse Foundation is doing something about IoT, you're not alone. I wasn't aware before starting this job. And an important thing about the Foundation is that, OK, we've got a bunch of metrics there, so it's not just about the IDE, if you weren't aware. We have a pretty good amount of other things that are going on. And specifically, our focus areas are obviously IDEs and tools, Cloud Native Java, we're the new home to Java Enterprise Edition, or it's called Jakarta EE now. But Automative and IoT are two of our utter pillars, and they are really, really strategic to us. And this is why a project like Voltron fits right in at the Foundation. In the IoT space, if we look just at our IoT community, we've got roughly 4 million 9-of-scode, 38 projects, a few hundred of contributors, so it's quite alive, I would say. And 14 member organizations, if you look at the toolkit, whatever IoT protocol you can dream of, we have libraries for that, and most of the times in several languages, so you can build on that, obviously. And looking at our membership, there are quite a few names there, and an important name here is the Linux Foundation. So we exchanged memberships between our two foundations recently, and the Linux Foundation, and specifically the Zephyr RTOS project, is a member of our IoT working group, so we're working together to build the open source Internet of Things. All right, so now getting back to Voltron, and this is Sweeta Stern to charm you. Thank you, Frederick. Frederick touched upon Voltron. It's an open source platform. It's for distributed sensing and control applications. It's highly scalable. The primary domain area for this platform is in smart buildings and smart grid domain, but it's not, the platform is not built only for that. It can be applied to other domain areas. It can be deployed on a single building or a multitude of buildings. The primary use areas of Voltron is in building efficiency applications that are looking to improve the performance of the building in terms of energy consumption, reduction in energy consumption, and so on. Building to grid integration applications that are looking to integrate distributed energy resources like solar panels, thermal storage units, battery storage units, and so on to provide ancillary services to the grid. Transactive control applications, applications that are looking to include buildings and the components within the buildings, like hedgeback units, lights, electrical vehicles that are connected to the buildings to participate in electricity market to provide services to the grid. So this is the Voltron ecosystem here. So the platform itself has built-in drivers to interface with different kinds of devices that are in the building and connected to the buildings. As I mentioned, there are thermal storage units, battery storage units, lights, and so on that can be interfaced with Voltron. And you have agents which use a specific application code. For example, applications such as intelligent light control that allows you to control the devices in the building to reduce the energy consumption and improve the performance of the building. Such agents can be connected to the platform and use the resources provided by the platform. There is also connectivity to the cloud for visualization and machine learning applications as well. So diving into the platform itself, the crux of the platform is the message bus, which is responsible for moving data from one end point to another. Then we have the driver framework. We also have the historian framework, which is responsible for storing data collected from these devices. Then we have a Voltron control status tool that allows you to quickly check the status of all the agents that are connected to the platform. It allows you to start and stop control the agents and also allows you to set configuration parameters for the devices or for the agents itself. Then the agents can all connect to a platform, and you can also have multiple instances of the platform, probably each individual platform deciding in a building, but all of them connecting to a central platform wherein you can have a centralized data collection point. And you can have a Voltron central agent deciding on that platform through which you can get a top level view of all the systems connected to it. Then we have a weather service agent that is connected to dark sky and gives weather information to agents that are needed. So diving into the message bus framework itself. As I said, message bus is responsible for moving data from one end point to another. Agents that want to connect to each other or communicate with each other can use the old Pub-Sub mechanism or can directly talk to the agents using remote procedure called mechanism. Earlier, Voltron was built with zero MQ. Last year, we made a move to use rabbit MQ. With this shift, it has brought in a lot of improvement. It's made it highly scalable. There are different, you can add different deployment scenarios now that rabbit MQ provides. With this, which it's very easy for you to move between message bus. The agent code is completely decoupled from the platform code. So changes to this shift is not changing the agent code at all. All agents that are connecting to this platform will use the message bus provided by the platform. But suppose there are multiple platforms in your setup. Some working on older versions of Voltron and some working on newer versions of Voltron. There is a compatibility layer that allows you to seamlessly communicate with each other. So this slide here briefly explained the slide where how that communication actually happens. So when the platform starts up, it connects to the rabbit MQ broker and creates a topic exchange. The exchange is responsible for moving data from one agent to another. And then you have agents connecting to the platform. An agent when it connects to the platform creates a queue and binds a queue to the exchange with a unique binding key. This unique binding key allows it to talk to any other agent and supposing there is an agent A that wants to connect to an agent B. Along with the message you have to send the binding key of agent B. The exchange knows where it has to route to looking at the binding key. It's the rabbit MQ principle. Then we have the historian framework. The framework allows you to easily configure different type of database depending on your needs. We have support for SQLite, MySQL, MongoDB, InfluxDB, CrateDB. Some of them have been implemented by the PNNL team and some of them contributed by the external community. It allows you to easily configure the different type of database that you need. We have APIs to store the data, retrieve the data and we also can configure the collection read. Data can also be sent to cloud services or it can be sent to other Voltron instances if needed. As I mentioned before, we have a driver framework that supports different kind of drivers. We have Backnet, Modbus, SCP-2, DMP-3, so you can connect different type of devices with Voltron. The configuration of drivers is very simple. There is one config file that allows you to provide the device address and so on and there's another config file where you can list out all the points, data points of the devices that you're interested in receiving and you can provide properties of the device, read, write or read only and the value type or the data type of the value associated with that point. It's pretty easy. The next thing that I want to touch upon is the security aspects of Voltron. Security is very important for Voltron community users. So we have both authentication and authorization. Agents that are connecting to the platform have to be authenticated by the platform. With zero MQ based Voltron, authentication is provided by Zap protocol and it's curve key based. With rabbit MQ based Voltron, we have moved to SSL based authentication. Either which way it has to be authenticated first. Then we have an authorization feature which restricts the access of the resources provided by the agent. Only agents that are allowed access can subscribe to or publish to certain topics. Similarly, only agents that are authorized to you call a remote procedure method on another agent can only do so. Then we have platform level security. We can configure the platform to alert, to trigger alerts based on the severity of the problem. Say supposing there is a device that is not reachable or a platform itself is not reachable, then alerts can be triggered to the admin that there's something going wrong. Then the security at the agent level itself. Role based access to agent capabilities and restricted access to config files. There's a suit of applications that the researchers in PNNL and outside are using. I will not explain them here, but if you need more information about this, I will, I can take it up offline. So let's go on and do some demo. So that was all about the different features provided by Voltron. I will just step through all of them as part of the configuration and the demo here. What I'm trying to do here is set up a local historian and a listener agent that is listening to everything on the message bus. And then you have a Voltron central agent that gives you an overview of the status of the platform and the agents connected to it. And then you have a master driver agent that you can configure to get the data of a device. In this case, it's a fake device. All of this can be established with easy config steps. This is a command line utility that we have provided to, if you want to set up some default agents that are already in the platform. You can write your own agents. And there are a lot of examples of how to write one in the source code. And if I understand well, the example you're giving there is using those virtual fake devices, which is something you can use once. Once you, if you know already the data format of whatever you will connect to, then obviously you can speed up development by using those fake devices and return the simple data you have. And at a later point in the development process, you can integrate that with the actual devices. And that's really a great time saver for the development team. The idea behind this is that for you to get comfortable with Voltron, these are some utility command tools that we have developed for you to easily start off with and then you can integrate them, integrate Voltron with actual devices. So here, as I said, there is backward compatibility with zero MQ. This, the step allows you to just set that up and we are going to make it web-enable so that we see the status of the agents and status of the data being scraped from the devices on the UI. I'm going to make this instance enabled with Voltron Central and then we provide some login credentials for the UI here. So what this is doing is it is installing a prepackage Voltron Central agent to run on the platform. Then this question here is asking about whether this needs to be controlled by a Voltron Central agent. You don't need to do it, but just for the demo purpose, I'm going to say yes. This is a unique name given to the Voltron instance and this name has to be unique if you are connecting multiple instances of Voltron together so that the messages can be routed properly. Yeah, and an important trait of the platform is that, yeah, it can be single server, multiple servers, and the agents can scale as well, which means you can run this on a server, but you can run this on an edge node or even something smaller than an edge node as long as it will support Linux. And that's one of the great strengths of Voltron, the fact that it is so flexible in the topology that you can use with it. Yes, exactly. So at PNNL, the researchers at PNNL have a campus deployment project where they have deployed Voltron on multiple buildings within the campus that and have them interfaced with all the building equipment. So, and some of them are installed in Raspberry Pi as simple as that. So it can be deployed in a normal virtual machine or in a normal box or in a small edge node as well. Here I'm configuring a platform historian. This historian here is by default, we have SQL historian as part of this tool, but you can configure other type of databases as well. I'm gonna skip this step because I'm going to show you how to configure a fake device for a master driver agent. A listener agent, as I said, will listen to everything on the bus just to see what's going on in the message bus. Okay, so we are all set. So I'm going to go ahead and start the platform. So this simple script here will start the platform for us. And the log below, I've just put it in debug mode, so it shows you what, that all the agents have been started and up and running. As I said, we have a command line tool with which you can see that all the agents that I just configured have been installed and are running. So I did an auto start set to true, that means it will run automatically. So you have a listener agent, you have an SQL historian agent for storing the data, then you have a VC and a Voltron Central Platform agent as well. So now I'll open the UI. This is an admin UI which allows you to authenticate agents connecting to the platform. The first thing that you will need is to set the password for the admin user, that is what I'm doing. And then you see here, you have a certificate request. So with RabbitMQ-based Voltron, the authentication is done using SSL certificates. So with Voltron Central, you have, comes with also a Voltron Central Platform agent which is responsible for collecting the status of all the agents connected to the platform and also the devices connected to the platform. And you need to approve, you can approve or disapprove the certificate request. So I'll go ahead and approve this request. So this is for a single platform, but if you have other platforms or other instances of Voltron trying to connect to this platform, then as part of the connection process, it sends a certificate signing request to the platform. And here, as an administrator, you can approve or deny such a request. The next step here is, I'll go ahead and actually log into the Voltron Central page. What is upcoming is that we are going to integrate the process of certificate signing request and Voltron Central together, which is what the users of Voltron asked for. We haven't done it. We're going to do that this year. So once we log into Voltron Central, in the platforms list, you can see all the platforms that are registered with this Voltron Central. If you have other platforms connected to it, then you'll have a longer list. And this gives you the same status as we saw in the command line. And you can also stop and start the platform from the VC. So now I will try to install a master driver agent and have that, before installation, I'll have that configured with a fake device. So I have some ready-made scripts to do that. So here, first thing that I will be doing, let me look at this, show you this. So this is, as I said, it's a fake device that we are trying to get the data out of. So that will have its own point list. These are some dummy points that we have set. Along with that, we have a state that shares whether it is read-only or read-write, and then data point associated with that. And then the other one is the, and after that is done, we have to configure the address of the device. Once that is done, we can go ahead and start the master driver. So what that does is periodically looks at the data of the device and publishes it on the message bus. So in this case, those fake devices are supplied with the platforms. But if I want to write my own driver or my own device descriptor that can stuff, typically what language would I be using? So if you want to configure different type of devices, it's all in a basic config file, which I forgot to show. But if you want to write your own drivers, then we have a driver framework format. You just have to use the same format. And there are some examples of how to do that. Just have to follow that and it's pretty easy. So here, this is a fake device, so it doesn't have all the IP address and other information. It just tells you what the publish rate is and so on. But I can point to a different location where we have some easy config files that allow you to configure the device information. Say for example, an RTU device here. So this driver config specifies the driver address, device address and the slave ID in term if you want to configure a Modbus device and the port number for that. And this is registry config points to the CSV containing a list of data points for that device. And these parameters here specify how it will be translated into a topic message. Okay, so I'm sorry, he just told me that we are running out of time. So I'm just going to run this real quick just to show you how the data is scraped from that. So here, if you see, the data is being collected, is being published on the message bus. So any agent can subscribe to this topic here, sorry. This topic here, I'm sorry, this topic here. Devices slash campus slash building slash unit. All, and then you can get the data associated with the device. I have scripts to control the fake device as well, but at this point we can stop and take any questions if you have. Yeah, and just we had a wrap up slide, so if you can bring that up. But essentially, as you can see, the platform is something that's really well built in the sense that it provides not only the basic features of energy monitoring and management, but development framework around it so you can have device support. And the way it's built is really, you decide of the ideal topology for whatever use case you have. So you could have energy monitoring agents, let's say on every floor of a specific building, for example, if you need that level of granularity and then a campus-wide agent that aggregates all of that, for example. And it's really powerful in that sense. Now getting back to our little slide there. So if you want to learn more about Voltron and overall Eclipse IoT, we've got a website for that. So iot.eclabs.org. I put the direct link as well in the slides and they are published, so you can access that on the conference website, but essentially there's a whole website just for Voltron with documentation, samples. All of this is open source, so please download, play with it, and let us know what you think. We've got an IoT newsletter and a Twitter account for Eclipse IoT where we discuss, well, Voltron and many other things, so please join us there. And if you want to learn more about Voltron and overall the Eclipse IoT ecosystem, we've got our own little conference in Germany in October, so please join us in Ludwigsberg. I will have the pleasure to present there and many other community members and commuters will be there, so please join us. And we've got a few minutes left, so if you have any questions, please go forward and ask them. No questions? I mean, come on, where are we that clear? That's impossible. Or maybe you're just angry, right? Well, if there are no questions, well, we'll be around for at least a few minutes. And well, thank you so much for attending. Have a nice end of conference, and well, thank you again. Thank you so much.