As the host of this session, Spyros Sakellariadis, ICONICS Global Director of IoT Business Development goes over what ICONICS, the company and the software does and what changes have been made to the software and how these incorporate changes and updates to leverage IoT and specifically to make ICONICS work better for the customer. He explains that ICONICS is writing software that helps companies reduce their operating costs, be more efficient, reduce response times to incidents, and so on. ICONICS is writing software for a very specific, measurable target.

Video Transcript

[0:00] Spyros Sakellariadis, ICONICS Global Director of IoT Business Development

Well, welcome to the session this afternoon on IT and OT, Riding the Wave as, as Mark called it on IT, OT, IoT and the rest of them. My name is Spyros Sakellariadis. I work on IoT Business Development at ICONICS. And I'll go through some very high-level slides around what ICONICS does. And then what changes were we're making and how we leverage IoT, and specifically, to make ICONICS work better for the customer. In a lot of the other sessions, which you have either seen this morning, or you'll see through the live broadcasts, this one has a lot of detail on what we do. But what we do, and just to make sure that we're very clear at a top level, is we developed software. We're not an SI. We're not an OEM. We develop software which we license to people, and our software is used to automate monitoring and management of systems. But the important thing is what we do. We do this because we're writing software that helps companies reduce their operating costs, be more efficient, reduce response times to incidents, and so on. We're doing this software for a very specific, measurable target. This is a case of the energy consumption from January of 2012, if I remember correctly, through to the end of last December of the energy consumption of a building on the Microsoft premise. And the only thing that was done in December of 2012 was add ICONICS. Nothing else: no additional sensors, no changes of procedures. The only thing that was done was add the software. Before then energy costs were going up and up and up after that down, down, down, down, down. And that's true for the whole entire Microsoft campus. I can say that with some level of certainty because I created this graph while I was working for Microsoft. What do we do? We monitor devices and equipment. We monitor the environment. We monitor devices; it doesn't really matter whether it's a device in a building, like on the Microsoft campus, a manufacturing piece of equipment, an environmental piece of equipment. We monitor equipment to get the telemetry. And what do we do with that? The first thing we do is we display it. We’ve got to get the data, then we display it. This is a case. If you happened to be in the room exactly opposite, you'd be hearing a talk from the International Union of Operating Engineers. It'd be showing you this display. They're monitoring the real time data in their training facility. Or, in this case, we're monitoring the air quality in our offices in Foxborough. Again, the one case was manufacturing equipment - building equipment; this case, air quality, or operational efficiency. You've seen all these slides in other sessions. The point is quite simple. We get data; we display it in a way that's meaningful to the audience. Doesn't matter what industry it's in, doesn't matter what type of equipment, we have the tools to display the real time information. Now, why do you want to see that? Because you want to diagnose what's wrong or what's happened, what's inefficient. This is a case again from the IUOE where they're showing faults in that system that they just were displaying the real time data. A fault is just a set of data that is showing you that things are not the way they're supposed to be. It could be a very simple thing like the temperature is too high, and you're about to blow a gasket. It could be a very complicated thing where there are 15 different live data streams that are all in the wrong proportion. And it tells you that you're that the bulldozer is about to break down, and you need to get it in for maintenance long before your scheduled maintenance. Doesn't matter what are the rules that you're defining: whether they're very simple “if/then” statements or complex machine learning models detecting and diagnosing a fault is simply applying logic to that incoming data stream, which you saw. 


Here's a case of Mitsubishi: we're displaying an elevator. Unfortunately, someone happens to be stuck in the fourth elevator shaft. It's not necessarily that you're about to blow a gasket over here. It's that someone who's screaming, and they have claustrophobia, and they're stuck in the elevator shaft. Again, it's just a fault that we're detecting with our software. Now, you've displayed the collected data. You've displayed real time data. You've detected problems. We also historize it, where what we're showing is trends. Trends are useful because they can show you work. They can help you diagnose why you have a problem. But they can also show you that things are getting better, deteriorating, in the winter when you need to do something slightly different than in the summer. So we've got the displaying the real time data, diagnosing problems, and displaying the historical information. Now, that gets you to, what in various other sessions, was called the elevated word wisdom, we usually call insights. The point is you’ve got information about what is wrong. The next thing you've got to be able to do is fix it. Two ways of fixing it. One, you get onto a computer, and you change was called setpoint, or whatever you're going to do. The other way is you dispatch someone to go in a truck and get the dead rat out of the damper. Part of what's happening when you're looking at faults is hopefully, they're coded in such a way that they tell you what's a mechanical versus one that you can fix remotely. This is a case in the Microsoft technology centers where you can change the speed of a fan, an exhaust fan in a in a in a garage, for example, through the ICONICS software. So we've gone up; we've gone to command and control. And at the end, you're also empowering the frontline workers. This is a particular device is from a company called Real Ware, and we can see all the ICONICS screens and so on in the visor there. We've got a flashlight; we can talk backwards and forwards with the people in the remote office or back in the head office. This picture is from a great video of a guy wearing the hat in the pouring rain fixing thing on an oil rig. So, we've empowered him. And one of the last couple things we do is we raise alarms. A fault is a fault is a fault. We also sometimes want to do something relatively drastic, like send someone a message that says, “Guy get out there and fix this”. So, there's the alarming feature as well. And finally, we create reports. So that's a very, very high-level view of the sequence of things that we do. Before getting on to the IT portion. I just wanted to close this section with one slide that says, why is it that you, for example, save money with remote detection. And basically, the reason is this: ultimately, without remote detection, if a problem starts here, it goes undetected for a whole bunch of time, someone understand there’s a problem because a user sees that water is coming through the ceiling, someone runs over there checks it out, starts working on it and fixes it. So, you've wasted water and time for this whole period. Here is electricity. Let's say if something's going wrong with remote detection, you detect the problem early. You can work out what to do through your system. The labor is much shorter because maybe 80% of these can be fixed remotely. And you're done. And you saved time, you saved energy, you saved electricity, you saved water and so on. Alright, moving on. 


I'm going to steal a couple of slides here from Microsoft. Firstly, what is IT? How are we doing it? How are we doing it that is completely agnostic to what industry you are in? What part of the world you're in and so on? This is just one of the standard slides from the Microsoft Azure team. How is it you can do it without having just a manufacturing application or just a boating application? So how do you do that agnostic across industries and global? How do you do it leveraging all the latest technologies? And every week new ones come out there; whatever it is: 250 different discrete services in actual loan that you could use. So let's take a look a little bit at the history. This is the traditional situation where to use a technical term, you have things, and you've got something like a PLC that's getting data from the things using some sort of private network, getting it into your data center, where hopefully you're using ICONICS. And stuff is happening. That's the part I would call the Old World. The next stage is the IoT world. And the basic IoT world is you insert a gateway in the middle. So, all this is happening on the private network. You then go through a public network, to your application in the cloud. The difference between the pre IoT and the current IoT world is simply you're now bringing in the ability to go over the public network by adding a gateway in between. Now, the more exciting and latest developments is you're now adding edge computing. And in this case, here, we have this product called IoT WorX which adds the edge computing to the environment. You're still going through the public network. You're still going to the application in the cloud, but you've also enabled edge computing. And in the case of IoTWorX, not only are you doing edge computing, but you can deploy it from the cloud and so on which makes a lot of sense. So, moving on, what is edge computing for Microsoft? This is where we get into the pure IoT stuff. This is what Microsoft regards as IoT Edge as - it all runs on in this IoT Edge which runs on top of say Linux. It has a bunch of different containers. And ISVs can put software into these containers which then allow you to do all sorts of stuff. With respect to ICONICS, this is what we've done. We've created IoTWorX which runs in a container on IoT Edge. And we've got, for example, you heard about Takebishi Device Explorer which gives us additional protocols. So, these guys all get data from the devices. They talk through the rest of IoT Edge up to IoT Hub. It's beyond the scope of today's talk to go into a lot of details on this. But this is where we do the edge computing. We do a lot of edge computing here in ICONICS. And we can do edge computing by talking to other modules here. So, for example, we could be doing edge computing here with ICONICS, getting data from devices, running some types of analytics, then passing it to Azure Stream Analytics to do additional types of analytics before it heads up to Azure IoT Hub. Now, once you've done that, you also want to see what's happening. We have this product called KPIWorX which can look at the data that's coming off the devices. This is KPIWorX looking at the data there on the edge from the edge so you’re still, as it were on- premises. Now moving it up, we want to get this data to something called IoT Hub. This is what you saw before, IoTWorX which gets it up to IoT Hub. There are other types of devices coming out these days at high speed that the device itself can talk through a protocol like MQTT directly to IoT Hub. And then there are third parties, like you know, Mitsubishi elevators, or Lutron power switches, and so on, that all have their own web service. And we then can get it from that web service into IoT Hub.


The key is this thing here. All the data is aggregated here. And it's upgraded in such a way that our GENESIS64 subscribes to Azure IoT Hub. If you happen to be a serious Azure geek, you'll do all sorts of things with stream analytics and SQL Server or get it here to do some of the stuff with Azure Functions. You'll talk to Azure digital twins. And in fact, we've got a great session about our new products the next gen which works with Azure digital twins by Zhi Wei Li going on which you can look at later. But again, the basic thing is any data coming from the edge can go through several different paths. This one, this one, or this one and get the data up into Azure IoT Hub, where GENESIS64 gets the data from IoT Hub and does all the magic you heard about earlier. Now, that's a quick slide. If you're a pure Azure IT engineer, you can use a tool and look at the data coming into IoT Hub. If you're more of an ICONICS person, you can look at the exact same data in the ICONICS Data Explorer. As you see it is exact same thing. I don't know if you can read it. But there you see the data coming from this occupancy sensor. There you see the exact same data. So, the data then comes into thing, you could see it in KPIWorX down there. But once you are up in Azure and using GENESIS64, we have our graphics tool that allows you to create very sophisticated screens. Here's the screen of monitoring a Power Meter. It's coming up through the same channel through IoTWorX or GENESIS64, acting as a gateway into Azure IoT Hub, being displayed on a GraphWorX screen. So, it's again, now we're just back to visualizing in the cloud tying back to some of the stuff I showed you earlier. Here's a case of I talked to you earlier about showing faults. Here's a case of that same data now being analyzed by a bunch of fault rules and ICONICS giving you the alerts. Moving on: say you've done all that fantastic stuff, all the secret sauce, the magic in GENESIS64. What enterprises want to do is connect that to other things they have, whether it's dynamics or Maximo a service. Now Salesforce, their CMMS is or other tools like Power BI and teams and so on, we have these products that allow the connectivity from Genesis to other enterprise systems. One of the big complaints that we heard from a lot was companies was them not wanting to deploy a pure siloed application that didn't talk to anything else. So, this interoperability quotient of ICONICS is very important to us. And here's a case, so you know, that those are ICONICS faults now being displayed in Dynamics 365 Field Service. At which point, you can do your schedule optimization. You can decide who's going to go fix it, who's available. Maybe the fault is here, and you've got six people around the world that can fix it. The only one that's available happens to be in Paris which isn't going to help you today here. So how are you going to deal with that? So just to wrap this part up, there are essentially three different ways you could architect the solution. One is only on the edge, the legacy way as it were. The other is the basic IoT with a gateway that sends it to the cloud and all the work is done in the cloud. And then this third way of using edge compute plus the cloud. The advantages of moving from left to right are way more than I could fit onto the small slide. But that gives you the basic start.