Access More IoT Insights From Losant
A Comprehensive Overview of Digital Twin Model Capabilities
- A digital twin model defines a type, or class of physical entity where digital twins are derived.
- Its telemetry properties are an essential part of the IoT data flow from device to analytics.
- Digital twin models use virtual or calculated properties to derive additional IoT value.
Create Digital Twins with Losant Systems
Craig Baldwin: Hey, everybody. Thank you for joining us today on Losant’s Take a Deeper Dive Webinar Series. It’s now 1:02 p.m. Eastern, so we’re going to go ahead and get started. So, today speaking is myself, Craig Baldwin. I’m the partnerships director at Losant. We also have Eric Toperzer, product manager at Itron; Brandon Cannaday, who’s our chief product officer; and Kevin Niemiller, who’s our senior integration engineer. Today’s topic is going to be on our new feature release systems. And we’re going to use an example application from our partnership with Itron to show off how the system’s functionality works. Before we get any further, I want to provide a couple housekeeping items. First and foremost, today’s session is recorded. So if, for whatever reason, you need to leave early, or you’re afraid that you missed some of the content, don’t worry. We’ll send out the recording after the call, and it will be made available on YouTube as well. If you have questions about any of the content today, systems included, please use a couple different features within the Zoom webinar. You can use the Q&A feature or the chat function. We will be queueing all questions until the very end, and at that point, I’ll go ahead and moderate. It’s likely that we could run over the 30-minute time, so if you decide to leave, no problem. We’ll record all the questions and all the answers so that you can view them when you do have time. So, let’s do a quick review of Losant and our Enterprise IoT Platform. Losant is a cloud-based application enablement platform that’s comprised of five key components: Edge Computer, Devices and Data Sources, Data Visualization, Visual Workflow Engine, and User Experiences. Our partners and customers use these tools as the foundation for their IoT application and the visualization which they put in front of their end-users. Today, we’re going to touch on a feature which greatly enhances the capabilities of these components called Systems. These are just some of the customers we work with as well. Bosch, Verizon, Proctor & Gamble, Hewlett Packard Enterprise. Losant is a leader in the industrial and smart environment space. So, if these are use cases that you’re tackling from an IoT perspective, it’s worth checking out the platform and engaging with our team afterwards. So, let’s talk about an application that we partnered with the Itron team on, a methane detection solution. We’re lucky enough to have Eric with us from Itron, who’s going to say a few words about Itron and the methane detection solution which Losant partnered with them on.
Eric Toperzer: Thanks, Craig. Thanks for having me. My name’s Eric Toperzer and I’m with Itron’s technology enablement group. Our group works with partners to integrate Itron communications technology into different types of devices. Itron is a world leader in the internet of things, and we have a long history of delivering scalable network solutions to utility customers worldwide. AMI, or advanced metering infrastructure, is one of the first types of IoT applications. Our technology leverages highly reliable IPv6 networks to bring consumption, interval data, and sensor information from millions of different devices. In addition to the metering of electric, gas, and water, our portfolio of intelligent streetlights enables Itron to create a communications network building the foundation of any smart city. Itron, though the acquisition of Silver Spring Networks, has deployed an impressive 65 million IPv6 endpoints. These include metrology, streetlights, line sensors, and other types of IoT devices. In fact, 75% of the power in the United States touches Itron technology. Through our Developer program, we now have over 220 unique partners that are developing different types of solutions. One of the solutions that emerged from our Developer program addresses gas leak detection. The IoT infrastructure is a real problem, both in the US and abroad. Gas utilities own up to including the meter. So gas leaks can occur anywhere in the distribution network, and monitoring to detect leaks is a very high priority. Today, when somebody smells gas, they pick up the phone, they call the gas company and report a problem and the location. At Con Ed, this happens on the average of every eight minutes. Their goal is to have someone respond to a location within 30 minutes. To improve monitoring and response times, we worked with Con Edison and a company named New Cosmos, based in Osaka, Japan, to deliver an intelligent communicating methane detector. The methane detector leverages Itron’s Milli 5 communications module, and New Cosmos’s hot wire MEMS sensor. The methane detectors are installed in basements near the service entry point, 6-12 inches from the ceiling – because of course methane’s lighter than air. The device is 100% battery-powered, and alarms at 10% LEL. That stands for the lower explosive level. When a device alarms, it sends a message across the Itron communications network to the back office. The device also has an audible and visual alarm, similar to a residential smoke detector. In addition to the gas leak message, there’s a health check that occurs three times per day which provides device and battery health as well as a runtime indicator in hours. All the messages include a timestamp. We needed to have a dashboard to really monitor these devices, and we worked with Losant to develop a simple way for customers to track and monitor their devices. We’re using a dashboard for internal testing, demonstrations, and customer pilots. All right, let’s take a look at the dashboard. First, you can see we have a map that displays all devices based on GPS coordinates. We have devices in our offices you can see in Liberty Lake, in Santa Clara, and at Research Triangle Park. Green is good. That means that it’s healthy. Yellow means there’s either a health issue or a device has been offline. So that could be a battery issue, it could be the device did not communicate over a 24-hour period. And red indicates an alarm. We also track reachability to assure that each device completes at least one daily health check. If you scroll down the portal, you can see the unique identifier is MAC address. And that is the second to the last column. Each device has a device name. You can see the timestamp is indicated. And then we also track device health, battery health, and hours since powered up. And you can see the devices that are active and inactive.
Craig: Awesome. This is fantastic. Thank you, Eric, for that explanation. So, this has been a wonderful project for the Losant team to collaborate with Itron on. Not only have they been a fantastic partner, but, as you can see, this is a really amazing use of the Itron network, the New Cosmos technology, and in this case also Losant, to bring together a nice, life-changing solution for those who might have issues with gas leaks in their home. Now, at this point I’m sure you’re wondering how does this relate to systems, and how do systems work? It’s a relatively new feature for us. So, with that, I would like to hand it over to Brandon Cannaday, chief product officer, and he’s going to walk us through implementation and give more detail about the systems feature.
Brandon Cannaday: Excellent. Thank you, Craig, and thank you, Eric. That’s a good overview of that methane detection solution. So, I’m going to spend a few minutes in the second half of our 30-minute allocation really digging into the Losant side of how something like this was implemented. That way, if you’re joining us and you’re thinking about developing something similar, hopefully, some of these tidbits you can take away as part of your solution as well. I’m going to focus a lot of my conversation on a relatively new piece of functionality that we released called Systems. And it really is kind of our definition of a digital twin. And this Itron application was a really great fit for that capability because it is a highly distributed network of sensors. There’s a lot of sensors. They’re distributed all over the country. They need to be grouped by their customers, Itron’s utility customers, then maybe grouped by region, and then finally grouped by the end customer. So that digital twinning, the ability to create simplified models of complex distributed systems, is a really good fit for what Losant has called Systems. And, as I mentioned, it really is, first and foremost, a grouping mechanism. So we saw over and over again customers needing to create complex models of their physical world. So you might have your business on top. You might have your customers. Those customers could have regions. Those regions could have sites. And then, finally, the devices live at the very bottom. So how do you create this hierarchy to make sense of an environment like that? And that’s fairly standard. That grouping model, that grouping mechanism, is available in a lot of different IoT systems. However, what we did special, and to differentiate ourselves, is this data propagation mechanism. So, especially in the realm of Itron, where they’re generating methane alerts, you want to be able to see a system-level view into that environment. So, if I’m looking at a customer, a utility that’s an Itron customer, I can see are any of my methane detectors currently alerting. Or I can dig down if I’m got them deployed in individual regions. Is there a methane detector in a specific region alerting? So we layered on top of that a really sophisticated data propagation and aggregation layer. And what’s interesting about Itron’s example, and if you are a current Losant user, you may see the chart on the left and think it looks a little bit like our existing Experience Groups functionality. So, Experience Groups are a kind of a tenancy model. Itron’s application is a multi-tenant application. And it does a good job of using both of these at the same time. So I wanted to address first what the difference was between our new systems capability and our existing Experience Groups functionality. I’m going to do that first by switching and looking at the Experience Groups that are behind this Itron demo application that we’re showing. And Experience Groups are a device access mechanism. And they are the way that our customers create a tenancy model. In this case, Itron has four tenants – basically four customers – in this demo application that they use to show what’s going on. And this hierarchy is only one level deep. There’s really no need to have a deeply nested hierarchy. They’re not assigning users in different levels where they’re logging in and need to be able to see different devices beyond just the end customer that they do. However, if I now switch to the devices list – I’m going to switch to Systems – there’s a new System Explorer near the top – if I click that, we can see – after I collapse a couple of these other systems – there’s another layer of grouping, unrelated to device access, but very closely related to a logical organization of the devices. So the methane detectors on the far end, they are grouped by zip code, which is then a child of the actual tenant. So, Systems allow a different form of grouping. [Inaudible 00:12:55]. So that’s the major difference between an Experience Group and the grouping provided by Systems. If I quickly switch back to their dashboard, I want to now cover some of that data propagation. I’m looking at an overview dashboard; so, kind of a system view into my environment. And I see I have a number of devices currently alerting. So that is an example of that propagation. Of all the devices under me, under my system, how many are currently alerting? It’s a really nice high-level window into the data. If it’s zero, I know I don’t need to dig in anymore. If it’s anything but zero, like in this case one, I really need to figure out where that might be. So, to do that, we want to be able to roll up automatically all the devices that might be alerting within a system. So, first I’m going to look at an individual device. Nothing really special here. If you’re used to Losant, this will all look very familiar. The major change was, there is now a parent system, a field on all the devices. So any device can now be added as a child into a system. And that’s done through the parent field. So that’s how you start assigning devices to their parents. As part of this change, we also did move the attributes into their own tab. That allowed us to provide a more proper home. We’re starting to see devices with hundreds of attributes. We also added additional information as part of this release to attributes, including tags and description. But for this one, I really want to call out the gas alert attribute. So, this is the attribute that will be set to a one whenever this methane detector is currently detecting methane. It’s going to be a zero otherwise. So, in order to aggregate up all of the sensors within a system that are currently detecting methane, I have to sum all of the devices that currently have a gas alert attribute set to one. So, let me switch now to the actual system. In Losant, we implemented Systems as just another type of device. So if you’re already familiar with Devices, you’re going to be very comfortable with Systems. Just like all other types of devices, they can also have a parent. So this allows you to create that deeply nested hierarchy; basically, systems of systems, or subsystems. The major difference is how attributes are reported onto a system-type device. So, the methane detector device I just showed, that was a standalone device. The gas alert attribute is reported onto it, just like every device you’ve ever utilized within Losant. Systems, on the other hand, their attributes are calculated, or derived, by looking at all of its children. So, in this case, if I expand the gas alert attribute on the system, you can see it’s a lot more fields here, but essentially it’s setting up a calculation. So it’s going to do a sum. You can do many different aggregation types. In this case, I want to sum – I want to add together – the gas alert attribute of all of my children. So this will be periodically recalculated, and that’s controlled by the top here, the report interval. So every 15 seconds, this system will automatically recalculate the value of all of its children using these aggregations you set up. So, they’ve built in an automatic way to do these system-level views, this data propagation, from data at the lowest level of your system hierarchy all the way to the highest level. And then, if I switch back to the dashboard, that’s how we see aggregation data like this easily added to this dashboard. Like I said, system-type devices are used in an identical way as any other type of device. So once it has attributes, and its values are being calculated, you can utilize those attributes and those devices on dashboards like you would any other type of device. So, with that, I’m going to hand this back to Craig to continue this webinar.
Craig: Awesome, thank you Brandon. All right, everyone, give me one second to share my screen. So, there’s obviously a lot of information. And if you’ve been within the Losant platform, you know at this point in time we have some very big, powerful tools. But it takes a little education and training to understand how to use them. So we have a couple key resources available for you as you’re getting to understand Losant and using the tools. First and foremost is Losant Documentation or our Docs. You can find that at firstname.lastname@example.org. It is an amazingly thorough resource for referential information on the platform. We also have our Forums. So we have a really strong following of developers and customers and partners who are using Losant all the time, asking questions, answering those questions, and really solving a lot of the “how-to” problems with Losant in that community. That is a free community to all developers, to go in there and hopefully find some answers to some questions that you may not have to ask on your own, they’re already there for you. We also have Losant University. So, Losant University is video-based content which takes you through each of the features and components of Losant. This is hosted by Taron Foxworth, our head of education, and he does a fantastic job walking through our developers, partners, and customers through the features and components. And then, lastly, we have some hands-on tutorials at the blog. So I would encourage you to check out each of those resources if you’re getting used to or accommodating the Losant and building with the tools. One other thing I want to mention before we jump into questions. We have a couple Save the Dates for you. First and foremost, we’re going to be at IoT Tech Expo November 13th and 14th in Santa Clara. So, if you’re going to be there, we would love to see you. We’re going to be at booth 465; myself and a few other of the team members will be at the booth both days. So come on by. And then we also have another webinar coming around smart stadiums December 4th. Go ahead and mark that on your calendar. If you haven’t already signed up, you can do so at the same site that you signed up for this particular webinar. And I’m sure we’ll send you some email details on that. So, before we go any further, I want to take it to some of the questions that we received while we were on the webinar. The first one we actually received as, how do we get data from the methane detector to the Losant platform? Now, in the case of the current solution, Losant is primarily used for demos and pilots. But perhaps, Eric, if you’re able to, would you be willing to answer, at least as it relates to Losant, how we’re connecting data from the field to the Losant platform?
Eric: Sure. So, today we have a back-office system that’s based on an MQTT broker. And the methane detector essentially publishes topics to the broker, and then the Losant platform subscribes to those topics to pull them in.
Craig: Awesome. That’s simple enough. So, the next question that we had was related to Systems. And it is, how many children can a system have? Brandon, do you mind answering that one?
Brandon: Yeah, I’d love to. So, there’s really no limit to the number of children a system can have. They can have thousands. And we actually did a fair amount of engineering behind the scenes to support environments that large. Like I mentioned when I was going through the demo there, that aggregation, that automatic calculation, there’s a lot of work that went into making sure we could actually do that spanning many thousands of devices. So we added a lot of caching, a lot of better handling of device state data. And you did see all that. It benefited a lot of other areas in Losant as well. But there is really no practical limit to the number of children a system can have.
Craig: Awesome. Thanks, Brandon. So there’s a question around the Itron dashboard. And it said, I saw a count of inactive devices on the dashboard. Kevin, I know that you were a big part in helping to build out this particular solution. Could you give us an explanation of what does that actually mean and how that’s calculated?
Kevin Niemiller: Yeah, Craig, I can take that. So, the methane detector checks in every eight hours, reporting the device and battery health. Basically, letting us know that the detector is still working and connected. If the detector does not report at least one time in a 24-hour span, then it’s considered inactive. So, in the workflow engine, I’m using an inactivity trigger node, which makes it very easy to track if a device has not reported its state in some configurable amount of time. So, in this case, 24 hours.
Craig: Awesome. Thanks, Kevin. So, it looks like we have one more question that came in pretty late. But it’s something that I actually think a lot about as well when I’m working with Losant and explaining Losant to customers. With the new Systems feature, Brandon, do you want to talk about maybe a core difference between Experience Groups and Systems, and maybe how they could be used in tandem or not?
Brandon: Yeah, happy to. I covered it very briefly. But the core difference is Experience Groups are for access control and Systems is for logical grouping. So, putting devices in a system doesn’t imply any kind of access control. It doesn’t… Just because I added a methane detector into a zip code doesn’t mean one of my Experience users now immediately and all of a sudden can get access to that data. Experience Groups are that mechanism. So if you want your Experience users to be associated with those devices, that’s where Experience Groups come in. And a lot of times those structures can be very similar. But what we’ve found is there are a lot of times where they’re very different. So we didn’t want to combine the two concepts into one structure. And you’ll find that done fairly often in a lot of other digital twin features out in the world, where those two concepts are combined together. There’s a lot of cases where that’s a little limiting. You want your logical grouping to be much different than your access control. So that’s kind of the core difference between the two.
Craig: Awesome. Thank you, Brandon. So, with that, I would encourage you to check out the resources that we have on the screen right now. You can also reach out to myself or any of the Losant team at our website, losant.com. We thank you for joining us today and hope you come back and join us for the smart city webinar in a couple weeks. Thanks, everyone.