Hey, good day good evening everyone whatever the case may be. Thanks for joining this webinar on how to make building infrastructure infrastructure smarter with Laura Wynn, it's brought to you by the law Alliance and members of the Smart Building work group will be participating and presenting to you today. With that will just jump right into a few high housekeeping notes here. I won't read through all of these, but an on demand version of the webcast will be available in the slides will be available for downloading. Please take note that if you do have questions to submit them through the Q&A box at the bottom of your screen, we will answer the questions at the end of the webcast. And if you have any delays or issues with the pages refreshing, push F5 and that will usually solve the problem and you can kind of quickly look at the other notes there. So let's meet the speakers on yours truly. Barb Miller. I've been chairing this smart buildings work group in the Laurel Alliance. I'm also director of Laura Business Development at Centex, who is a semiconductor chip manufacturer and provides Laura chips on upon which the Lora Wan protocol from the Laura Lliance runs. Also joining me. Today is Frederick Gallo. He's the director of marketing from Ng Vertus. And he's going to be talking a little bit about how Laura has been used to create value for businesses through HVAC optimization. Dan Kwan, vice president of Strategic Development and multitech. And he's going to talk about how Apple, what application owners must take into account when deploying Laura when applications and smart buildings. David Chirino, who's the IT? Solution sales manners from Renaissance he's going to talk about how you confuse Laura Wan into existing building management systems. And Seth Taylor, who's CTO and cofounder of Kairos. We'll talk about how to mitigate risk getting using real time data collected by Lora Wan devices, so it should be a very interesting webinar, and we look forward to their presentations. So a couple intro slides for people that are not overly familiar with Laura Wynn. It is a major component as to why buildings are getting smarter and I don't think there's any doubt that the industry is moving towards smarter buildings. So why is Laura Land a deal for this? For one, it offers a fantastic power consumption, which is great for battery powered devices that have to be placed in hard to reach locations. Quickest way to kill ROI on a project is to have to go replace batteries all the time. Human intervention is always the most expensive part of any project and so long battery powered devices, life devices or ideal for collecting data. It isn't a standard within ITU now and is a product of the nonprofit Rural Alliance and is such as an open nonproprietary standard. Fantastic coverage and range from single gateway. Many buildings can be covered with a single gateway, extremely good noise, interference characteristics and can even cover outside of buildings very easily. The architecture is inherently redundant, so if you are the data you're collecting is very important, you automatically get redundancy by deploying multiple gateways and there's a wide net ecosystem of devices. Gateways didn't developed over the last five to seven years by members of the Lower Alliance and those that are not members of the Laurel Alliance as well. At the kind of the top of everybody's agenda corporately these days is. ESG goals lots of social pressures and investment pressures, but also the realization that it's just good business these days so and and it can save companies money. So monitoring and controlling things remotely is a perfect use case for IO T. In many cases you have to prove compliance with regulatory requirements and to do that you need to collect data and you combine the fact that we've got these fantastic wireless protocols with long battery life. Now you combine that with cloud computing and advanced data analytics and you know the ability to analyze data, collect data and utilize that data is easier now and more cost effective than at any time in history. So quickly I will review how you could use Lora Wan in, you know, sort of an existing building automation environment. The difference between these two drawings here I won't go into great detail, but essentially the left hand side of the drawing shows how you can use traditional Bacnet devices and carry those over a Laura when network wirelessly. The right hand of the join shows how you would use Laura Wan enabled devices and then integrate. That data into a Bacnet or other building automation system. Today, we're gonna mostly be talking about the right hand side of the the drawing here, but you you can certainly do the left hand side as well. And with that, I'll turn it over to Frederick as our first speaker and Frederick take it away. Thank you Byron, for for the introduction. My name is Harry gave you. I'm CMO of Ng virtuous. We are specialized on smart building systems, mainly regarding energy efficiency. First, I just wanted to give a maybe a business feedback and background around around smart building because. I I think we we are we are at kind of 10.4 for the moment regarding a smart building industry and basically I just wanted to stimulate the way that now technology is able to create value for the customer while just enabling just new business model for for them. If we look back here at the smart building challenges what we are and what we had to face with was first the technical complexity. We have so many challenges to face regarding the IT regarding the data, collect infrastructure and stuff like that. So that was my first point. How we could deal with the technical complexity. The second point we had to face was just the operational issues. It's regarding the deployment the way we could just put the IT. The way to put the gateways. All the wire we had to deploy in the smart building so we had so many challenges to to face and there were also in the operating and maintenance stage so it was really a big deal for for everybody to face with that challenges. And the Third Point. I mean, it's the most important. What was the business model? We had some cost issue to face and basically a lot of CapEx to for for the business model. A lot of OpEx. And well, if I want to summarize for a long time, we were just like we were just providing great use cases for everybody. And it was a shiny period. Everybody was wow we are able to to provide great use cases. But the problem was the business model. Most of the time we were just we're just in front of the lack of. Of performance for the business model and the return on investment was just not easy to find. So who was really, really to pay for for for that smart building solution so. I just want to test him. When I was a product we have which is called virtue of control. Basically digital solution mixing IRC, cloud predictive and machine learning. We which enables and optimize all the systems behavior. We are providing first assistance that collect the the the real use of the building, so we have quite a lot of of IT deployed in the building. Basically to monitor occupation, temperature, air quality and everything we are collecting gathering all that that are in the cloud. Here we have a proprietary artificial AI predictive and and model and machine learning systems. That's our mixing, collecting, crossing the data and giving back the the optimizing instruction in order to control all the adrac systems and. If we if we take a closer look to to the installation principle, what we can see is that we are basically trying to optimize both the itching, production and also the temperature regulation for room bathroom. So we we are quite using a lot of IO T, so it was really important to find the best technical solution for us and Laura gave us a lot of great value for. For that we are using two kind of senses. The first one are. Has to collect the data OK. As I said before, we are trying to get all the temperature, quality, occupation. This is mainly the data we are gathering and using all of that data. It's on the left of the slide. Just through the gateway sent to the back end and the cloud and then went going back to the connected the objects which basically are actuators that are optimizing the way that editing and cooling are distributed within the building. This is the first the first part of the solution and the second one is just more dedicated to the production of itching and cooling. And basically we are just trying to work with. With the standard of the business and smart building industry, basically Modbus and Bacnet, maybe, but this is a bit more widespread here in Europe. I don't know that we are trying to work with that with that 2. To kind of of protocol in order to to optimize the production and basically what we are seeing at the moment is just the way that this solution is nowadays. Deployed on more than 300 buildings at the moment and the first. The first point I want to stretch is the reliability of of the solution. And the protocol. Lots of value, and it's also the the the way the the best. The best solution in order to have an industrial deployment nowadays for for the smart building. The second point is of course the efficiency. Regarding especially energy savings. Well, at the moment energy, especially in Europe, is just something very important as the price are rising up and it's important to deliver solutions that give value for the customer in order to reduce drastically their energy consumption. And regarding the 300 building we are already. She my thing we are able to deliver an average of less 25% for for energy savings, which means a lot of value for the customer at the moment. And of course we are also providing a value regarding the the carbonized journey as we also reduce the CO2 emission for for their buildings. Third points is the way as we are not only providing solution, but we also operating solution and something very important as we are very very careful with the the way we can optimize. Of course the life of the solution and in operation and maintenance perspective it's really important for us to have very few gateway to take to deal with and this is something very important. We'll see after that it's also has a financial impact, of course, but on operation and maintenance perspective, it's very important as we are able to to deploy quite easily and quite fast. And it's something very important for us and during the lifetime of the product. It's also easier for us to to have relabel hardware, and it's it's something that's very important for for us, so it's something we have to stress the way we can. Easily deploy and operate the the whole solution. And the first point I want to share with you, and I think it's the most important because I'm not technical guy. My point is, is just to to testimoni the fact that sometimes technology enables for us new business model for our customer and what we've seen reducing the number of gateway, simplifying operation and maintenance, we were just able to have much more attractive financial model for our customer. And basically reducing the CapEx, improving return on investment was just key for the success of the solution, and I think it's something important at the moment. That's why in my introduction I was just talking about maybe a kind of turnpoint. The fact is not what the use case we were able to do because we are able to do a lot of use case since a long time, but what seems to be very important for me on more business perspective. The way that now we can also propose to the customer attractive. Financial, motor, and well, Byron. That was my point. Very good, thank you Frederick. Interesting to see real life real life use cases with the real life returns. We'll move on now to Dan Quant from Multitech Multitech say long time member and supporter of the Lower alliance. Really appreciate that Daniel and just to hear what you have to say. Yeah, thanks Byron. Founding member back in 2015. It's it's been a long journey and today I'd like to take a few minutes to detail how the success of Laura when is in part due to the flexibility of how Laura Wan network can be operated and deployed to best Meet the needs of the application. The network agility of Laura Wan has a big impact on the performance. The business model of an application as Frederick highlighted earlier, not to mention the return on investment and the ongoing financial payoff for the entity paying. The the basics right in any Laura when application just like a cellular or an Ethernet network, you provide the end nodes, likely a capital expense and you need to be able to retrieve the data into your analytics platform. Your business system, like an ERP or even perhaps a a control system. So these are the basics with Laura. When the end nodes, perhaps sensors and. How are you going to get that data into your platform? So the key decisions that have an impact to the performance, the business model, and the financial payoff include. The model of how to achieve this so is that going to be a sensor to cloud model? Is it going to be a sensor to a control on Prem control system? And are you better off using a public carrier? Does your application perhaps dictate a private network investment? And how do you? Architect the network and more centralized approach, or perhaps more distributed. So let's have a little look at some of those options, should we so so sensor to cloud right? Very easy model and being used extensively in the industry today. Essentially Laura Wan sensor into a gateway into a cloud based platform and this is the quickest way to scale. It's simple to gather access. Process, visualize and analyze data. It all comes up to a central repository where you can do all of these things with your data. There's no custom network or system integration. It could be just as simple as cable. Tying a sensor onto a motor or a generator, and and then seeing data appear in your application within a couple of minutes. And the way in which you pick up your data from the application server is likely a standard Internet Protocol like MQTT HTTP. So so again doesn't require any OT skill sets, and this is ideal for sensor harvesting applications like condition based monitoring of motors and pumps and out of spec alerts and around environmental conditions, alarms and updates. And the hate of something goes above a certain level, or perhaps below a level. Where where said to on Prem systems have a lot of advantages is where you don't want that data to ever leave the building. Perhaps it's very secure and you wanna keep it on Prem. You want to be able to maybe lower your OpEx costs so that you're not running up costs for cloud based compute and storage and the backhaul costs to get the data up there and back. And perhaps you want a more resilient approach whereby you're define the network. In order to to make sure that you have redundancy, maybe and. And this is ideal for control systems. Typically closed loop control applications like lighting, heating, ventilation, systems, access control, security systems, all the types of applications where you want that data to remain on Prem and feed directly into that on Prem control system. So so now, how to decide what kind of network you want here? And remember you always supply the end nodes, you're the one pulling the data out of that network. If you go with a public carrier, maybe you have coverage around you, so it's very simple to do that. Maybe you don't have coverage quite where you want it, so you can perhaps even invest in some gateways and you can take those gateways and subscribe. To a public network server service and you can configure your gateways to pack it forward in there, and by doing so you've essentially increased the reach and the capacity of that public network to better service your own end nodes. So let's look at some of those advantages, so obviously there's a low CapEx expense. Maybe you you use your own gateways, maybe you don't, but you don't have to spend too much money building out a network. The network is there for you. You get great mobility if you're trying to track assets moving between buildings across a whole country that's perhaps covered by Laura Wan network, France being a good example of that, and then you have full nationwide mobility and you have that speed of deployment a little bit like the sensor to cloud model the networks all there is just about connecting assets, pulling your data off in a few minutes. The disadvantages are that OpEx cost can eat you alive and those ongoing fees per device. So million devices on the network you buy another one, then that's a million and one devices that have an ongoing OpEx cost, and you know coverage limitations may. And be an issue, although with Larry you have the ability to bring your own gateway model and probably not always the greatest approach for integration and control of local systems. A private network, on the other hand, provides you that lowest OpEx cost. You're not paying per end point for you know a million one devices or something. You build the network for the capacity that you need, and and really that's your cost. The initial build out cost and the cost. The maintenance of that network that you've put in. You get that data privacy and protection because you've built the network. You get a deterministic performance exactly where you need it. For the application that you're trying to service, and with that comes a great deal of control and resiliency that you can put in place. Of course the disadvantages are there are initial build out costs, so if it's a few sensors that you're trying to connect, this is going to be a high CapEx expense. But if you have a number of sensors in a facility, perhaps you'll see a return on investment in maybe as little as 9 to 18 months. And particularly if your assets are are clustered in that environment, which is a key disadvantage here? If your assets are scattered all over a region, a county, a state, a country, and then then yeah, a public network provides you that greater nationwide coverage. So now let's have a little look about a private network. Remember, you're always providing the end nodes, you're retrieving the data. You're definitely in this model going to have to provide your own gateways, but you're also going to have to provide your own Laura when network server. Maybe that's a public or private cloud. Maybe it's on Prem, but but that's the real addition here. You're now having to take control of that core network element, the network server. So let's have a little look at that model quickly. So end nodes like Kairos water sensor, which you're going to hear about in a second when one of those. And nodes those sensors first join the network. It does a join request that goes into the gateway. All of that messaging is sent up to a centralized network server that's typically in a public cloud, but could be on Prem in a building as well. And and if you're a sensor in that network, if you're registered for that network then you'll get a an accept to come back. And now in blue you can see how the payload now goes into the gateway. And there's something to be said, and that payload is also pushed up to a cloud or on Prem network server, and that data is routed to the application server, which is where you pick out your data and you send it to your building management system or your Azure Cloud, or Amazon or wherever you're sending your data. So advantages is that simple integration. You don't have to manage too much about how the network server is working and performing, you just need to be able to capture the data in the gateway and push it to the network server and then pick it up in the application server into your your platform. So great network device management or built in low maintenance fast onboarding, but you have no edge intelligence or decision making down at. At the edge and and of course you got the OpEx costs of now. Having a network server and you're having increased Wan backhaul costs and and and typically you know if you're in anywhere of a slightly built up environment. You're typically going to be servicing maybe 10% of your own sensors, and you're going to be back hauling up to 9095% of other sensors that are in networks around you. Which, once they get into the network server, are disqualified because they're they're nothing to do with your network, so that's quite a lot of data being pushed back on the backhaul. That's essentially garbage, and so you know point to bear in mind you're you're paying for that backhaul cost. And and you may well be on shared network resources with. Attention with others. But this is ideal for wide area networks and it's ideal for sensor to cloud applications like occupancy detection in order to optimise where in the office, perhaps you you want to clean more based on on foot traffic. Lastly, and let's have a little look at distributed network architecture and so, again, sensors applications. They join the network. This time the network server in this example is distributed inside the gateway and so now we can have whitelists and blacklists of the sensors on these networks. And we're not backhauling anything that isn't already part of this network. Any of that garbage data from other sensors on other networks is immediately. Removed and if that sensor is part of this network then it's provided a unique set of keys so it's very securely protected at the network and the application layer, and that data is served up to the application server into a custom application that is retrieving that data and pumping that data directly into a building or facility management system, perhaps using a native protocol like Modbus, Bacnet, or MQTT. So advantages is resiliency, privacy of data, and the security of that data. Because it never leaves the premise. You get the full compatibility with the Laura Warren ecosystem. You get the edge intelligence that provides you that direct and native integration to a building management system with those reduced when backhaul costs along with zero touch network deployment and and end point authentication. And and joining into the network and this kind of architecture is ideal for connected clustered assets on a central control system. And the kind of applications like lighting control and access control systems. Right back to you, Byron. Thanks Dan, that was extremely important information. I know when I talked to people there's sometimes misunderstanding about what what Laura Wynn is and what it isn't, and pointing out that you know you can go. You know, from completely public network access with cloud based storage, you know outsourcing everything to keeping everything on Prem is a very important point you can, you know, own your own network, do all the processing on Prem all that. Kind of stuff. Great great points to be made, so David, we just heard from Daniel all the different considerations one must take into account when they're looking at deploying some wireless sensors based on Laura Wan. What about somebody that's got an existing building infrastructure or is familiar with, you know, more traditional building automation protocols? How would they integrate those integrate? You know, new Laura Wynne based devices into that kind of. You know environment. And I think you're gonna tell us about that, yeah, and that's a great question though. Yeah, and thank you for the introduction. So my name is David Chirino. I'm with the industrial Edge computing division of Renaissance electronics, and we'll get right into some of those more specific building automation or building management system applications here. So let's start by. Taking a quick look at really what that traditional Laura Wan architecture looks like in a smart building, and Daniel did a really good job of outlining how these things tie together. So he mentioned the Lauren network servers. That's the area in which the Lora sensor data is being processed. Now that data is being received from that Lorawan gateway within that building, and that data can be shared with various IoT. Cloud hubs or cloud applications? But if you look at the smart building architecture, you're building management system is isolated from the rest of that data. So you're taking a lot of very valuable data from these loan sensors. You're pushing that into the cloud. You're doing a lot of analysis, you've got data. Over time, you can start making some decisions, so we call those. I hate using the term, but actionable insights, right? So the action required from one of these insights is now manual. Though it requires some human intervention, you've got to get a report handed to somebody. Give them an idea of what this data now says we need to do, and you need to go make some changes to actually create the outcome that you're looking for. So that's one of the struggles that we have with a lot of IoT deployments. Is that we really have trouble getting to those outcomes, and that's really the reason that we're making these deployments because there's a business outcome that we need to achieve. So one way we can start to address that. Is by adding some edge intelligence at the building that can help manage this data a little bit better so our edge device is called the smart server IoT. And one thing that we've done that's quite unique is we've embedded a Lorawan network server into the edge. So that doesn't mean you can't use a a Lorawan network server in the cloud, because like I just said, we're creating a lot of very valuable insights with these cloud applications. But what we don't have is that local BMS support so. This might look pretty familiar to some of the network architectures that the Daniel showed, but what we can see here is that we have that centralized and decentralized approach, kind of as a hybrid. So you really get to choose the best options that work for your particular situation. So we're allowing the the LAWAND network server in the cloud and at the edge to coexist, so this allows through the use of the smart server IoT real time sensor data to be shared via Bacnet, modbus or whatever the appropriate OT network protocol to be shared directly with the existing building management system. So this removes that. That manual piece that we're we're needing to, you know, find a way to address so we can have the edge intelligence sitting at the smart server. It can be sitting at the BMS, or both. So we can now program in some actions that we can take to actually achieve these outcomes that we want to get to. So. You look at the arrows here. These are bidirectional, so I want to. I want to emphasize this a little bit, so not only can we send data. To the BMS or receive data from the cloud, we can send data to the cloud. And pull data from it. Meaning if there's a deployment in your building, that's cloud based, only. That information is now accessible to whatever your on Prem OT systems are. And if that out system is, say, Bacnet, for instance, we can at the edge see everything that's going on on that system, so if you don't have support to actually do your intelligence at the building management system or whatever OT system that is that can happen within the smart server. So you can see how this starts to solve the problem where now we have the ability to really just take that last step and create the action that these insights have then developed. So to really kind of sum this up from more of a business standpoint, you know what we've been doing is defining our issues. Measuring these data points that are creating the insights for us. So we're analyzing that data in the cloud. And traditionally, you know, we're we're sending a report, you know a report might give an action to say, you know, we need to adjust set points where we have poor indoor air quality, or we have a leak. You know that that's a manual process right now, so you know, we're gonna put another step in place here, which is really improve it. And do this in an automated way. So that's where this solution allows. All these IoT devices to then become more autonomous and actually drive. The outcomes that you need. Reporting is still important because that becomes our control, so we need to, you know, take action and then decide hey did that work. How well did it work and do we need to make any adjustments or maybe start defining or measuring other things? So you know a lot of people will recognize these steps you know, as really this is your 6 Sigma approach for continuous improvement. So at the end of the day, what we're all looking for is achieving a business goal. So using this kind of approach with this hybrid technology allows you to do things that are Byron stressed at the beginning. Meet your ESG goals, reduce your risk, and have an actual bottom line benefit to your business by using IoT. So I hope that gave some valuable insight. Next, we've got Seth, so I'll take that back over to you, Byron. Alright thanks, yeah I'd love that ending slide and one of my favorite sayings I use frequently the spaces that which can be measured can be improved so you know, if you're not actually collecting the data and knowing where you stand, you can't do anything about it. You can't approve it, so and that's that's what IT is all about is collecting data, lots of data from lots of different things. OK, so we're we're kind of we started here Seth with the with Frederick showing how they're able to use Laura Wan in a a certain way for to improve energy efficiency, reduce carbon emissions, provide a good ROI on you, know, reduced energy costs for a customer. We heard from Dan and David, you know the considerations and how to implement these systems in the built environment, and we'll end. Here with you, who I think is going to show, highlight a alternative way that all this data can be used in the built environment to make the workplace safer and more efficient. So go ahead and take away Seth. Thanks Byron, and as we've been talking about on this on our webinar here, the Lorawan network has a wide and expanding variety of sensors that are becoming available, making it simpler and more cost effective to blanket a building with sensors and get that real time data across the building, or maybe even a portfolio of buildings that can reduce our exposure to risk. There are things like newer equipment that can be self diagnostic and give us feedback. But there's also a growth. A large stock of legacy equipment that cannot be or is too costly to retrofit and bring into the fold of of sensors that we have nowadays. There's also new construction, where it's actually more effective nowadays to put in the wireless sensors because they're cheaper and easier to install rather than running wire everywhere. And we can take this wide array of sensors that are no really easy to employ, low cost and get new telemetry, fill in the gaps where we're missing telemetry data from our buildings, and create new capabilities that can interface with old systems like what David was saying with the smart server IO T. And and give us new ways to automate and reduce the risk in our building. So whether it's from a capital outlay or ongoing maintenance cost, it hasn't been easier net. It hasn't been easier than now to execute using Laura when Byron mentioned it. That sensors now last maybe up to 10 years or beyond because of the efficiencies we have with the lower band technology. We're sending bits of information temperature. Turn off open. close that kind of information and is overkill to send this over something like a Wi-Fi network. That's high bandwidth and you'd have to blink at the building with multiple more of routers than you would using something like a Laura Wayne Gateway. Umm? Then, once we're able to blanket the building now with these sensors across, you know the spectrum of what we need to measure. We have to share those insights with our teams and there's. Multiple applications in the Lawan universe that allow us to share information in real time with like maintenance teams, tenants, building operators, whoever needs to know and and achieve some sort of escalation path that allows us to react in real time before something that would be a catastrophe in the building. Just it becomes an inconvenience. And when we can introduce things like machine endpoints to what Frederick was saying earlier, we can start to automate and and even start to to do things we just had to leak, which I will get to speak about in a minute, detect a leak, we could react and shut off valves or pumps and prevent further damage from. Cascading through a building. So Kairos is a leak detection and water control company, and one of the one of our products is a league detection membrane and leak detection itself. Lens is a very great use, is a great use case for Lora Wan because it is such a small amount of data and in order to get the full benefit you want to be able to put these sensors everywhere, so across boilers, chillers, pump rooms in units to detect any. Early detection of leaks around planets or fixtures. We want to be able to do that. Kind of on a whole scale, and the other reason this is a great application for Laura Lynn is that across the US, annual claims are about $20 billion annually. That's a lot of money, and if you compound that with the growing cost of water as a utility, and the fact that water itself is both consumes electricity and gas anyway, and most buildings where it needs to be pumped needs to be heated, it needs to be treated throughout the building. It is a growing concern. In our case we've we had an example where we were wooing a client in California and we sent them a pilot system to test, but before they could even get that installed. They had a leak in one of their rises that led to hundreds of thousands of damage and immediately prompted them to go and install our system across their property, which was why they needed to use the law of energy to get across because it was too disparate in order to be able to retrieve that sensor and signal information remotely. So when they did it install, it was actually a few months later, this is. Perfect use case, they had another flood that they were able to get on site immediately and remedy, so I've given the example of leak detection, but you know there's many other sensors that you could put in the scenario, especially environmental sensors where you can see the same use case and the same return. So kind of to summarize here. There there's a way to increase your building efficiency. And actually, there's a McKinsey and Company study that claims there's a 6 to 9% increase in no. I from simply installing an IO T system, kind of for the reasons we've been talking about. There's new types of automation that are available when you're collecting more information from your from your building, and one example is you know, adjusting light and HVAC schedules based on occupancy. And anytime you can take your operations from being reactive in nature to being preventive or even predictive using machine learning. You're able to eliminate unwanted downtime or unscheduled downtime. Overall, increase the efficiency of the building. You can also, as Byron alluded to you can increase auditing and tracking efforts with ESG. There's a Black Rock survey that says 53% of ESG investors are finding that there's a lack of. Quality data and availability of the data that is kind of holding them back as being a barrier to adopting sustainable investing. You can reduce your MRO costs. We've kind of been arguing that the this this whole webinar is that you can minimize damages by just reacting a lot faster or even automating things within your building. And finally, insurance costs. We've been working with insurers to to quantify and get data on how they can offer new structures of premiums and deductibles for their customers. And even if you're self insured, that's real money. That comes out of your pocket that you're prepared to pay for events that you could easily mitigate or reduce. Using this a new sensor network within your build. And with that I'll send everything back over the tea barn. Oops, all right. Thank you Seth. And thanks to everybody on. I'm going to thank you on behalf of the audience for keeping it short and sweet and to the point. You know how attention spans are these days, so you know. Thanks for getting the the key messages out there in in a timely fashion. Everybody you know continue to put your questions and answers in the in the Q&A box now. And I do want before we get to the questions and answers. I do wanna point out the upcoming Laura Wynn World Expo. If you you know, there is no better place to, you know, learn everything about Laura Wynn. If that's something of interest to you coming up in in Paris, July 6th and 7th, you can scan the QR code there, or go to the Laura Alliance website and get more information. It's going to be 2 days of you know. Lots of information. Many people in the ecosystem will be there and you can interact and ask questions. Meet people when I'm one directly. So with that, give us a few minutes to scan the questions that have come in and we will begin the Q&A. OK, let's get on with the questions and answers here. That's say I've done a few of these webinars and we have some really good questions today. Excellent, excellent job. So I'll just kind of get it rolling here, so I think we'll start here with one that's specifically directed to Frederick, which is does virtous use a connection from the Laura Gateway directly to building control systems? Or does all data flow through the cloud? Well, actually. Solution is providing an optimizing efficiency of HVAC systems through the. Artificial intelligence, predictive model and stuff like that. So basically we are the colleagues. Some of the payload locally, but all the data are going to the cloud and send back later with the actuation order for for the IDRAC. Yeah. OK. I I'm going to. I'm going to throw one out here about sort of involving public and private networks, so I'm going to kind of combine two questions with the distributed network server where the gateway has the gateway, has the network server in it, does that mean we have to log? In or input each independent gateway for network server admins separately. Instead of a centralized cloud network server. Or are these edge gateways also controlled from a centralized point? And I'll kind of ask a a corollary question to that. But Dan, do you wanna address that first? Yeah, sure. Distributed architecture doesn't necessarily have to run the network server in the gateway. It could be locally in the IT room connected to a number of gateways in that facility, but it's a good question Jose. And yeah, in in in a simple configuration where perhaps you run the network server in the gateway, maybe you're doing a pop and a trial and then yeah, every time you want to update how that application is reporting. Change whitelists blacklists of endpoints you physically need to log into that gateway to access the network so that to to make those changes. However, there are ways in which you can centralise all of the management and, and this is really idealized. You you get your cake and eat it because you have all of the user data distributed at the edge. Connecting Laura Wayne sensors into I don't know back net. Building management system and but then you centralise all your control of these networks with traffic policy, security policy and you can service endpoint requests for unique keys and and rekeying of those devices. All of this can be done centrally for one network or a a whole group of networks into a common account. So in a simple sense. You you you have to distribute everything. But for scalability and you you only distribute the user data and you centralized control. OK. Umm? Great, so kind of a keeping with the private network theme. We have a question here from Steve and the question is is a private network the best way to achieve closed loop control with Laura Wan? David, I'll throw that one to you and Steve if we don't understand the correct question correctly. If you want to elaborate in the Q&A, we'll we'll try and address it better if if we don't get it the first time. So David, do you have any thoughts on that? Yeah, no to me closed loop control is, you know you're taking an input, you know from the device and you're you're creating, you know a set point change you're running it through a PID loop and that needs to be fairly quick, so that's not typically something that you wouldn't want to do from the cloud. You know we're not going to command a chilled water valve. Therese to reset a supplier temperature on air handler from the cloud that needs to happen at the edge. So with the private network you've really got the real time data so you're not relying on the cloud and you don't have that latency. So yes, definitely the private network is what you want if you're going to actually be using this as a supplement to your building automation system. OK, cool. Let's see another one here. For Frederick, I believe this came in when you were talking so a question about the statement made of 300 buildings optimized. This is from Jose. Can you go over briefly what optimize means? What went into optimizing a building? Thank you Joseph for for the question indeed. What do we mean when we say optimizing the address system of the building where basically you have a traditional behavior and performance level for from a BMS and what we're providing is the power of the cloud, the power of our telligence in artificial intelligence, predictive model machine learning in order to. Cross additional data and to really send comment to the EDVAC in order to deliver the proper energy in order to secure the comfort. So basically when we see optimizing we are talking about energy efficiency. OK, and in average regarding the 300 buildings we we've been equipped with the solution we are on average optimization of 25%. OK OK good. Well, we'll just keep rolling here. I wanna make sure we get as many of these in as we can. Seth, one from Gabriel here. How does Cairo sensor data integrate into the BMS? Is it a silo application? API raw data? Can you elaborate on how your architecture works? Yeah, so they're. They're actually multiple ways that we can do that, and we've been working with Renaissance and using their smart server SMTP to actually, they're they're running a an LS locally right there, and so all of our data can can go into that LS you broken up and distributed to the BMS through that method as well. Or that that would be a preferred method here. But we have API's designed and developed specifically to deliver the data in real time. Yeah, but again that would be you would be able to use that in sort of a closed loop setting where we are working and putting an application on the smart server out as well. Who that could could run that. Some of our cloud functions locally as well. Does that answer the question? It seems to Gabriel if if you wanna. If that didn't, please just add in the in the Q&A box here and we'll we'll revisit it. So. Here is 1 from Francisco. What protocols are recommended for the back end? Are you using Laura just for the sensor information slash collection? David, you wanna you wanna take a first stab at that one? Sure, yeah, you know, for the the sensor data, Laura really is the preferred way and I think we we covered a lot of reasons why. It's very easy, inexpensive to deploy, very low cost, and very robust. So getting getting the data is just the first step. So we do use Laura for that on the back end side, there's a lot of different systems that could be in a building. There could be a lot of different cloud environments that maybe like their data in a certain way. So you know from the smart server perspective there's a lot of options on how you can push that data out in the back end. We've used, you know modbus for SCADA systems, Bacnet for building automation systems, and then we've also, you know, needed to go and do some ERP systems, and we can just use an MQTT API that we have on board to do that so. That that answer that question really is it depends on you know what that system is that you're trying to connect to, but there's a lot of flexibility there, and being able to connect to most of what's out there. OK Dan, if I can also add to that. One of the the the question here was what protocols are recommended for the back end? Well, in a sense. That depends on your back end, doesn't it? As David just said, maybe SCADA system uses modbus production. Piece of equipment uses OPC UA building management systems actually use all of these protocols and back connect and and others too. And so it's really that back end that dictates the protocol that gets used and this is where the disconnect comes in. We're collecting data off of sensors that are often battery powered in awkward to reach places. And then limited to maybe no more than 11 bytes in in the US. And and how do we now integrate that data into a back end that's expecting to see modbus OPC UA or or Bacnet? And so where do you now do that conversion? In some instances you can literally do this on a sensor here. A basic modbus implementation can be done at the sensor level. It's designed essentially for a constrained. Interface, but other protocols like OPC UA and and Bacnet. For example, there's no way that those protocols are running on a constrained interface, so now that integration needs to be done north of the network server, and so This is why I highlighted how these internal closed loop control systems how how doing this on Prem makes a lot of sense, because sending all of that data up into a cloud to then manipulate that Laura. And data into a format like Modbus to bring it all the way back down into the building. And architecturally just isn't particularly efficient, so so really it just depends on your back end and there are many protocols out there that are phenomenally successful and they've been deployed all around the world. Building management systems have used most of them. Yeah, and there's the number of products on the market now. You know, one of which is the one David spoke about from Renaissance that that make that integration much simpler than it was. Maybe even two years ago. So yes, and just as a little tidbit as just because a little tidbit here that's very relevant, and I I lead our industrial work group, and I submitted a proposal for consideration by the Law Alliance Road Map Committee and to to address integration and best practices for a number of these protocols so that we don't have to keep reinventing the wheel every time we want to into integrate Laura to these. Their back end protocols. OK, ready. Yeah, yeah, so I'm gonna try and squeeze two more questions in here really quickly Seth this is. This is one for you. You know when you talk about leak detection, sometimes you know it's a little bit hard to prove a negative. In other words, if they haven't had a leak, they don't know what the consequences would be. What you know? How do you talk to your customers? What would you tell people to consider when they're looking at whether or not there's a return for deploying a leak detection system, such as SHIRO'S offers? Yeah, and and we do get that question a lot and I think early on we were trying to to sell leak detection. It was difficult because a lot of the operators that we were going to didn't there there maintenance and repair budgets weren't really categorized by this is, you know this was leaked. This was organic growth. This was whatever so it was hard to break that out and go back to them and say, well, here's what we're going to save, but over time as we've started to deploy. We've been able to compound reduced organic growth claims reduced having to go in and and just gut a unit or several units that are maybe in a in a vertical stack, and so the easiest way to look at it now is you know you. We go in and we say, well, let's go and look at how many apartments or units you've had to renovate due to. Organic growth, or, you know, water, water, other water issues and it it very quickly comes out to when we when we say we're going. Contract out a system. And they go in and actually look at the number of units that they've had issues with over like the last year, it's usually multiples. Our system is multiples less than all the growth claims that growth or damage claims that they they can attribute to water related issues, so I think. Long winded answer to say. It usually we we know it's months we know that the payback period for installing a leak detection system and and you could even apply this to other sensors as well, but for us it it's not going to be years it is. It is 8 to 12 months that we're seeing payback for just monitoring and early detection of leaks. One way to answer there you go. OK, OK, great and we got one question here Dan. In 30 seconds if you can a question about the basically security you know. Are there any concerns things to keep in mind when Edge devices are compromised, AKA physical unauthorized access as opposed to centralized cloud data? He's trying to compare the Edge Gateway security versus cloud security. Yeah yeah, I see that the two types of main attack vectors, the man in the middle attacking over the air interface and then of course the the physical access to devices and sensors. So bear in mind that these private networks are inside private facilities with, you know, gated entrance and and card key access. Not to say it's impossible to tamper with the hardware. Of course it is, but you know these are. Secure environments typically it's not like the general public just walking past so, so there is a level of overall security there, and the actual security of the sensors to the gateway to the network server. This is all baked into the Laura when specs and it's highly secure, so that man in the middle attack is not there. Unique keys for example being used the gateways have to have you know passwords. They have to be unique passwords. They're not the same passwords. Across a fleet of gateways and the cloud based platforms that centrally manage these distributed architectures are all tested against stock to do compliance, so so it's really much the same if you've got physical access. It's it's for sure more difficult to prevent intrusion. Not impossible, but but you need that physical access from a man in the middle perspective. It's no different than a cloud based architecture. OK, well we've gone a couple of minutes over, so I'm going to wrap things up here. I want to thank all the the people who've listened online to the webinar. Also, for the great questions. Thank you to the panelists and thank you for the Laura Alliance for hosting this and and putting it on so we will be having another webinar and smart buildings in the in the early fall. So please please look out for that information coming forth on that. Thanks again for joining. _1656848592703

Now available on-demand!

Risk management and Environmental, Social & Governance goals are at the top of every corporate agenda, including those who manage buildings as a core part of their business. Join LoRa Alliance members Renesas, MultiTech, Kairos and Engie as they discuss how LoRaWAN technology is being used to reduce risk and significantly improve energy performance within the built environment. 

In this webinar, you will learn: 

Audience: Building Owners, Facility Management Companies, Insurance and risk management professionals, BMS System vendors, software application developers, and more!