[0:00] Mr. Jotham Kildea ICONICS Solution Sales Supervisor
All right, thanks for joining for session today. We're going to be talking about “Rethinking Solutions for Your Connected Workforce”. For those of you online, there are two sessions. This is one. So we’re glad you could join us. Today, this session has two presenters. I’m Jotham Kildea, a Solution Sales Engineering Supervisor with ICONICS. I head up the team in the US. I've also got a colleague, Josh Obal who will be helping out with some of the demos and some of the technical aspects. He's a Senior Software Engineer with ICONICS. We're happy to be here. Just as a quick note for folks on the Attendee Hub, if you're joining virtually, please do enter questions. I do want to have time at the end of the session for questions if you have them. Megan Courtney is going to help out reviewing them. And we'll look at those at the end. Feel free to type those in as you as you think of them as we go along.
[0:57]
So, what we're going to cover today, I’ll give you a quick overview of what we kind of see is the current situation, the current environment in this space of how you connect and facilitate remote work. This is going to get into some of the things that we do particularly around notification dispatch, which is one of the technologies we use for sending messages and notifications out to the field and keeping those people connected. Also looking at some of the mobility solutions that are available. What do you want to think about when you're designing and deploying a mobile solution to a remote workforce? We’ve got a couple of great demos set up with some real applications. We’ve got some stuff that we've put together with the engineering team that we will go through, along with that last speaker, Shane Stevens, who's at Impact Automation and Control. He's going to be talking about ICONICS’ application at Lake Cities Municipality Utility Authority. I know Ted mentioned a little bit about it earlier this morning. So, we'll see that in a bit more detail.
[1:53]
And as I mentioned, questions, definitely let us know what you think. So, I said a bit of an overview of what the situation is as we see it; this is not authoritative. This is just some kind of compiled thoughts that I've put together over the years of working with these types of applications. So, here are some things that we have to watch out for. A big one is folks feeling cut off or disconnected from the application when they're not in the office. This is definitely a very common thing where somebody says, “Oh, something's gone wrong. I'm aware of something's being wrong. I need to get to the office to figure out what's going on.” That's kind of a possible problem because you're limiting yourself to only being accessed to the system when you're in the office, which is, of course, not always the case. This also causes a lot more back and forth where somebody is out in the field or in a factory. They're out to the site, so they have to go back to a system to check what’s going on then go back to the site. It’s a repeated back and forth in order to diagnose a problem. Ideally, you want to minimize trips. You want to be able to have something that you can take care of on the fly.
[2:58]
I'd say that this one above all of the other topics is something that is already being shoved in everyone's faces, especially with COVID. Previously they kind of put up with the fact that they had to have this dual mode of being remote and in person. With COVID, in a lot of situations that in-person is no longer an option. People have to be functional and active remote. And it's really driven that need for change and for having a solution for that.
[3:24]
Other things that we see: there is still today a lot of what we call islands of automation. This is where you’ve got a lot of different applications and systems that go into a solution like SCADA. We know that very well. CMMS systems for work order management, work order management systems, product management systems, all these different things that definitely have a purpose and a role, but frequently are not connected. They're islands; they're disconnected. They're not talking to one another. Any sort of transfer of data from these systems is, by and large, a fairly manual process that somebody has to transact. That's what we mean when we talk about an island of automation. This is something that, of course, we want to work to solve and improve.
[4:09]
How do you automate the flow between these systems? It still continues to be a problem today. So definitely we're going to talk about a bit today. And then there are also things about security. Right? I don't need to belabor the point. There are a lot of things going on right now as far as cybersecurity, particularly in SCADA systems, particularly in these remote worker situations. Just generally, the questions that we see is, “Where do we start?” The applications we interact with, traditionally had been in an air gap solution that they just said, “Hey, we're shut off from the world. We've got our own little network; we don't talk to anything.” Increasingly, that's not really a viable solution. And it doesn't take advantage of any of the new technologies out there today. So, a lot of the people that came from the model of “I can just shut myself off and I'm safe”, they have to reevaluate and say, “Well okay; maybe that's not going to work? Where do I start?”
[5:03]
Also, the need to do things about risk factors. Once you've decided to start, you have this concern of, “Well, where are my threats? What's the thing I need to secure the most? What do I need to be aware of?” It's kind of a rapid learning process to try to figure that out. Another thing that we see is that people come into it thinking that cybersecurity is something that they can purchase, or implement, or just deploy some piece of software, and they're safe. A lot of things that have to do with cybersecurity are training and procedures as much as they are software and hardware solutions. So how do you teach people to be safe? How do you implement good practices that make sure that what you deploy is secure? And then the always the big question of “What are you overlooking? What is the biggest risk you hadn't thought of before?” So, these are the types of things that people are very conscious of, as far as I see in space, and something we want to talk a bit about today. So, with that, I'm going to jump into a little bit more in detail on what I was talking about as far as notification dispatch.
[6:19]
So, notification dispatch. I'm going to give you a high-level summary of what I think the goal you might want to achieve with this is, and then we're going to unpack that a bit more and look at “Well okay, how do you actually build that? What do you put together? What are the pieces you want to think about?” So, when we talk about notification dispatch, very simply, this is connecting to an alarm infrastructure. What do you have today that is an alarm or an event? Something you need to notify people about. How do you connect to that? How do you grab that information? Bringing in other systems, all those third-party islands? How do you bridge that gap and bring them in? What can you do to integrate all those different systems so that the actions you take are going to be globally applicable across your organization? And then what can you do? So, making smart choices about who you notify and how and when talking about tracking that effort application? So, when people are being notified, you have an audit log of that? What can you do to facilitate people being more effective once they have that information? These are all the things that we're trying to achieve when we talk about an automated dispatch system. There's a lot that can go into the interconnections between these different systems.
[7:34]
So, I want as much as possible to try to make it simple and approachable for you guys. So, an event; who knows what that is? That could be something broke, an alarm was tripped, there's a trespass alarm, a door was left open, something's running too hot, too cold, whatever - something happened. Let's just say you want to tell people that that happened. Take a workflow. This is where you have decision logic that says, “Okay, something's happened. I need to tell people, ‘”Who do I tell? How do I tell them? Where do I find them? Where do I find the information to notify them of?” That's the workflow. That's the logic that that builds that. Then you've got the notification. How do you get that to them? What's the last leg of the journey? You've decided who to contact? And how? What actually makes that happen? Is that the question? And then of course, the recipient. What do they see? What how do they respond? This is a hybrid of technology, as well as behavior and practices that we talked about.
[8:31]
So, I think for most applications, the part that's the least obvious of what the heck that is, is going to be the dispatch workflow. So, to give you a little bit more detail on that. When we talk about this, this is in ICONICS lingo, a workflow is something that you see like in the screenshot here where there's some action that's triggered it, and you can have whatever you want to happen from there. So, in this case, a simple scenario of notifying somebody. You first look up how to contact them, how to find their phone numbers. And how do you get that information and then link it up to decisions about how you filter out who's the most appropriate person to notify first and how all that stuff is encapsulated in the workflow? This is kind of the core thought process that goes into our deployment of notifications to work this out in the field. So that's what we talked about when we talked about the dispatch workflow.
[9:35]
The other thing I wanted to look into a little bit more detail is the events. I was very brief on what an event is earlier, but an event in the ICONICS terminology would most commonly be something like an alarm from Alarm Work Server, from Hyper Alarm. It could be a fault from our fault detection diagnostics engine, or it could be a trigger, could be something from our data protocols. So BACnet and SNMP and OPC UA all have a standard for what is an alarm versus a data stream. So, any of those things could be a justifiable reason to trigger an event. That's what we talked about. We talked about event sources. Okay, so put that into the picture. Next, I want to talk a bit about the notification, how does that go out? In reality, there are several different technologies. These will sound pretty familiar to you when we talk about them. When we think about this, I would say where the industry is really leading towards is VOIP based technologies. These are things that you can access over an internet-based protocol. And, increasingly, these are being provided as some sort of SAS service from some company that says, “Hey, send us a message’ Send us who you want to send it to. And we'll take care of the rest.” We particularly like those because we understand cellular technologies. As a consumer, I don't know much about cellular technologies as far as sending people text messages when it's actually being sent over the wire. So, we use those services. They really know that industry very well making it very easy to abstract that complexity and to silo it from something you have to worry about. Definitely something we've broadly adopted in a lot of our applications. In a little bit more detail. There are several out there. These I would say find like the best-in-class options. You can see the options here. We talk about simple things like email, a standard thing, you’ve been doing that for decades. Now when something happens, you send somebody an email. A lot of different services can do that. We can absolutely do it directly to your existing email server. You might also consider some of these services like Twilio, Avantage, or SendGrid because they have a lot more dedicated bandwidth for deploying emails in scale at high availability, reliance, and robustness that you can definitely take advantage of if that's a concern. SMS is another classic example; you'll see this in the demo. That just means, “Hey, something's gone wrong. Send somebody a text message to let them know and give them a short little snippet of detail about what's gone wrong and maybe give them an opportunity to respond to that.” That's going to be an SMS message again. VOIP technology is by and large these days. Same thing goes for voice. So, this is a text to speech. Somebody gets a phone call now that they answer. They get some pre-generated or dynamically generated text to speak smashes, and it explains the problem. Again, they have an opportunity to respond and react and address it. But just a different format really depends on the use case, on how people prefer to decide between those. Which one's best for them. Do you want to see something? Then it's a text message. It's a quick little glance. You can see something, but it can easily be forgotten. A phone call? You have to pick it up the phone and actually listen to something that's being addressed to you. So, a little bit more of a break from your schedule, but that's sometimes what you want. You want to have get people's attention. So, depends on the right approach for the solution. And then WhatsApp. It's actually a category of a few different technologies. But What's App is the most common. For an idea of the traditional kind of the hardware-based systems that you've merged to via VOIP. WhatsApp has always been an IP based solution. Again, sending a cryptic message to somebody really depends on what's the preferred method of notification within an organization. Some people might standardize on one thing, others might sound another. I'd say from our perspective, we don't want to force anybody into any one particular one. That's why we make these multiple options available. We looked at the market and said, “Hey, these are the best solutions that are out there. Let's make sure we can facilitate sending messages through these.” Some folks may prefer one or the other; it’s totally up to them.
[13:58]
So, taking this a little bit further: We said, “Okay, and when that happens, decide how to send it; decide which format gets sent. What does the worker see?” SMS messages look just like any other message. A phone call could be any other message. We can also leverage the MobileHMI which is a ICONICS app on the smartphone or tablet as a possible destination for that experience. Receiving messages to the MobileHMI app, also MobileHMI very importantly becomes a good platform for that bidirectional sharing of information. A worker that sees something on MobileHMI can see, of course, the alarms, all of the details and browse to other things. They can go beyond just seeing what was posted in an initial notification. So, this is definitely something we'd like to use on more robust implementations.
[14:47]
On that interface, what you see here is an example of how you might use this for notification dispatch. This is just a standard graphic within MobileHMI, so there's really nothing crazy going on there? We talked all this morning about how to build and deploy graphics. That's an example of what you'd see there. There's also some fun stuff that you can use that gets telemetry data from the device. So, if you go down this path of this, there's a way that you can take information about the worker, where they are, where they're, what their availability is, for signal strength, or whatever, and incorporate that into how you notify somebody, we'll get into that a little bit. But it's a cool, cool implementation of how you might use this a little bit further. So, talk to all about that.
[15:31]
Also, acknowledgement. So, if you're familiar with the concept of alarm acknowledgement, this just means that this is a way for the operator to respond back. It's no longer an outgoing message; this can be a bidirectional conversation, where the user can acknowledge what happened on an alarm. And that's facilitated through most of the technology we talked about, I mentioned SMS, voice, WhatsApp, all these things can receive a message and then receive a response from the user. So, it can be just a quick control of that system from the interface that they're using. As I mentioned, that's facilitated both via the MobileHMI app, as well as through a lot of those direct protocols.
[16:18]
So still building, still adding some complexity here. This, of course, at any point we're talking about, could be the solution that gets deployed. But I want to give you some ideas of where this could go beyond that as you grow and expand the complexity of it. Don't feel that all of these modules have to be deployed day one. I definitely recommend you kind of build to this approach over time. But it’s to get you thinking about some other things you could do in the workflow. There are other things, other fun things you can do to take advantage of information you might know about your workers, what their expertise is, or what their skills are, what their schedule is, what's who's available on off shift at different times, where they are kind of alluded to that with the app, all of these things in general, are you going to be coming from some other system. This is where we get into that “What can I do with my ERP system?” “What can I do with my CMMS system?” One of the things you can do is plug it into your dispatch to make more informed decisions about who do you contact. Don't contact the person who's on vacation. Don't contact the person who's off shift and not on call right now. But do contact the person who is on shift and happens to be a mile away from where the incidents happen. That's kind of the concept of what we're trying to do with all this information. All of these different things can be fed into the workflow. And end of the day you're trying to prioritize so that ideally you send the message to the person who's going to be the best to respond to it first, and most efficiently. Of course, you always have a backup plan of who else to contact if and else and whenever something goes wrong. But hopefully, if your workflow is well tuned, you can make sure you contact the right person at the right time immediately.
[18:03]
So, I mentioned that a lot of this comes from third party systems. You absolutely can configure pretty much all of what we talked about there for schedules, availability, location, all of that within a standard solution. But I would typically recommend for larger applications, especially for you look to “Do I already have this in a system somewhere else?” When I talk to a lot of applications that when we get into this discussion, I want to get these people notified. I want to make sure that they know what's going on. We find out well, they also have responsibilities while they're remote to interface to a work order system, or to interface to their corporate network and using Active Directory. So, we have this information about them in some capacity of what their availability is, where they are, what's going on.
[18:51]
My suggestion: don't reinvent the wheel. If you've got that configured, you've got that implemented. It’s best just to integrate it directly into the system. That's one of those connecting those islands’ opportunity to take what would be a normally a disconnected system and just jive it all together. So put that there; that's options over on the left of bringing all those different pieces together. That's really your best third-party integration opportunity.
[19:18]
Other things that you can do: This is not really impacting the ordinary flow of the system, but more of a design and reworking and making your system more efficient over time is the analytics that comes out of this. You see this in a few different ways. We've got this tool AnalytiX-BI, we really love using it now because it's really good for taking this just raw data and making some insights out of it. So, we take a lot of the system information of who was notified, how they're responding, how frequently do they respond, yes versus no to alarms. All of that information can be fed into tracking and analytics so that not only do you have a good audit log, but you also have the insights to say, “Alright, are there ways that I can more finely tuned my system in the future so that I'm doing a better job of notifying people and making sure that they're informed and can do their job?” So, again, the thing I want to stress here is that there is a lot of stuff you could do. Don't feel that that's all going to be a day one task. It's definitely going to be starting with that center column. Do I have a message there? Do I have an event? Do I decide what to do with it? Can I send it out to a user and can that user see it and hopefully respond to it? That's the core capability. You need to achieve everything else beyond that just iterative improvement optimizations and efficiencies.