[0:00] Mr. Jotham Kildea ICONICS Solution Sales Engineering Supervisor
A little bit more on the mobile experience. So, everything we talked about thus far is pretty much getting information out to the worker. I wanted to spend a bit of time talking about how the workers out there, they see something come in, so what do they do about it? When I look at the value proposition of why you have a connected remote worker, one of the big benefits is going to be extending the reach of the existing system. If you've already got a SCADA system that is being used, it's being configured in operations. That's great for the person in the control room. Without a remote connected worker, you're totally blind once you leave the control room. So, taking that information that would be valuable in a control room, bringing it to anybody that's out in the field, that's obvious a simple example. Also, for that real time feedback, there's a lot of value and insight that somebody out in the field can provide over to someone in the control room in certain situations. You want to make sure that that information is fed back into the system. So, it's not just captured out in the field and never left there. You actually incorporate this into your full dataset. Capture wherever they are.
[1:30]
And then something interesting to do is curating the experience. So, if you're a remote worker, it's not necessarily appropriate to see the same things at all locations. There might be situations that you want to curate a worker experience. Okay, you're at a site, it knows you are at the site, so let's bring up the site appropriate information. I shouldn't have to spend a lot of time figuring out IO 's. Look at the analogy of oil and gas applications. There are a lot of pump jacks, a lot of wells out in the field. It could just be a tedious process to scroll through your list of pumps and find the right one that you're at. And if you click on it, you hope you didn't pick the wrong one because you're getting wrong information. So, if there's some way you could say, “Hey, you pulled up to the site; it knows you're within 20 meters of that well, here's the dashboard for that site.” That's a lot of value that saves people time; that avoids mistakes. They're not looking at the wrong data, so there are a lot of benefits that can be gained there.
[2:26]
And then also the connectivity with other workers. Again, something that comes up since COVID is how you make sure people are not totally cut off, that they still know what's going on. They don't see their coworkers face to face as often anymore, but they don't miss out on information. They don't miss out on Intel insights that are going between people. So, I use this example: it’s a clear example of how sometimes there's enormous value to being on site versus being in the control room. It's anathema to what we do because we do a lot of SCADA applications that are about building those dashboards. But there's just some things that being on site is better, right? Diagnosing a situation: if something's going wrong out in the field, you don't know. In the control room, you might see a SCADA system that just says, “Hey, here are the stats. There's something kind of wrong, but not sure what.” If you're on site, it might be blatantly obvious what's going wrong. You don't need a SCADA system to walk on site and say, “Oh, yeah, that's not supposed to do that.” So there's value to the fact that somebody that's a remote worker that's on site can immediately capture that what's going on right now. They can also hopefully correlate it to what was happening. So, you see as a problem now, but how long has that been a problem. If I can pull up my system, and quickly, at a glance, say, “Oh, this happened last night at 9pm. And ever since then something has been wrong.” That's going to give you more context to what you need to do to fix what's going on in the system. Also, getting that information back, as I said, we want to make sure that the remote workers are feeding data into the system just as much as they're receiving data from the system. So, they can keep the team informed if they see something like that which should be something that can be easily captured into the system quickly. So that information is not lost, and they know what's going on.
[4:25]
So, a big part of that is going to be acknowledgement. I'm going to talk about this in a bit more detail. The reason I use the term acknowledgement is that it comes from the OPC alarm events specification, is that it is a very standard feature of what an alarm event can handle. It's common across a lot of different things like BACnet and SNMP as well. That an acknowledgment just simply means that some user has chosen to acknowledge that something has happened. What that means to acknowledge something will depend from company to company and system to system. This is again an example of where process and how people handle it can be as important as the actual technical specification because what acknowledgement might mean to one company might mean. For one it might mean dismiss this alarm. For another one, it might be acknowledgement which means that I am taking personal responsibility. I Jotham have seen this and have said, “This is my responsibility from here on out.” There are very different ways of handling the same type of alarm. Again, it depends on what is the corporate procedure, what is the practice and policy of how you handle acknowledgement. I'm tired of saying acknowledgement, so we also call ACH. So, an ACH is just shorthand for acknowledgement. Like I said, it could be anything. It could be, “I'm taking ownership of this.” It could be, “Sure, I’ll dismiss it.” It might be more of a multi-step alarm management, alarm management versus work order management. These have a lot of commonalities and similarities, but there are distinctions as far as how people handle those. So, ACH might mean something different to somebody depending on the different app or application. ACH is a common one because it's using the standard. But there are a lot of other ways to do this.
[6:12]
In general, just to point out that this is one of the quickest and easiest tools to enable something that's remote as a way of just taking action and decision making on what goes on an alarm. Again, depending on the process, it might be appropriate for somebody to look at something and say, “Yes, that's a problem. But I'm not taking responsibility for it. So, I'm not going to ask about it. Maybe I'll send it to the next user.” That's a certainly valid approach. Or maybe they do want to take the approach of acknowledgement, and say, “I'm going to take ownership of this.” It really depends on other things to look at, along with that is saying it ACH happens or say just an event happens.”
[6:50]
You should consider what else you want to integrate into the system to keep everything appraised. You don't want to have discrepancies in your data that one system is ahead of the curve knows a lot while others don't know a lot and out of sync. So, what else can we integrate? Can we do CMMS systems? Can we do integration to other people? These are all things that are going to have a lot of benefit to a remote worker over and above something that would be in operations in a controlled environment. In particular things on maps and notifications. Some of the interesting things we've been looking at and projects I wanted to highlight were geofencing or geolocation. So, this is kind of an amalgamation of different ideas. One is tracking where people and assets are. So, we have good identity of the person that is here. This might be based on truck-based information. I know this fleet vehicle as at this location, a geofence is defining a region around something and saying, “I want to be notified when somebody enters or leaves. That is a simple example. I want to be notified when somebody is there because they shouldn't be there. It's a controlled environment. And I need to make sure that I know who's at a site at any given time.” A positive reason to use a geofence would be to say, “Hey, this goes back to the oil and gas analogy, there's a pump out in the field. It's got some low priority, but things need to be fixed. But it's not worth sending somebody 20 miles one way to go out and have a look at it; it can wait.” But if somebody's driving by, it might be worth the swing by and have a look. So, a geofence is a great opportunity to say, “Let me define a scope of how far an alarm notification can reach? How important is this? Should there be somebody getting sent this regardless of where they are?” Or should I maybe scale it down to say, “Yeah, I want you to be informed of it if you're within a mile, but if not, it can wait. Or it'll be on the queue. But it's not going to be a high priority.” Those are the types of optimizations you can get to with some things like this and plays directly into remote workers because by and large, this is based on people that are mobile who are perhaps in transit. They're not always going to be at a fixed known location.
[9:09]
Another thing I want to touch on is what is the right approach, and there's not one answer. What is the right approach to enabling those remote workers? Is it one app that does everything? Or are there multiple apps that each do their respective things? There's pros and cons to each. And I'll be honest, it's like I said, it's not an easy answer to solve. One app does give you the advantage of there's less context switching. We'll see this in the demo that there are things where if I can jump from one thing to the next, it's the exact same UI, the exact same format, there's no load time, as a worker, that's nice. That's really seamless. I have all of my data in one spot. It is admittedly more to design. If you're designing one app that can do everything. Well. It has to do everything has a lot more integration to do and It's also might be a bit more work as far as linking all those things. As I said, there are a lot of islands out there, so how do you connect them all together and is it really efficiently? Not everything exposes all of its data. The flip side, multiple apps in here I'm talking about, “Okay, I'm out there. I've got my alarm acknowledgment app. I've got my work order app. I've got my Team's app. I've got my remote expert app. I've got all these different things going on, all of these tools that I can use.” But individual apps, as I said, are pretty easy to get going. Everybody out there has an app, ICONICS included. But it's going to be optimized towards its respective use. But just the opposite of the single app, it's not going to have a tight integration. There's going to be some things that you might provide more context: switching for a user say, “Oh, I figured something out. Okay, hold on. I have to keep that in mind because I have to jump over this other app, find somebody in contact them.” You want to find a sweet spot where to share the information you need to share, but not make the users waste time just rummaging through data to find what they have to do next. Right. So, I don't have a prescriptive answer for you. Just something to think about. If you're deploying a project, to keep that in mind of what do you want the user experience to be like and does that fit with what you think is efficient for your users?
[11:22]
Security. So, the security comes in in a few different places. When we talk about this remote connected as far as ICONICS is concerned, I just jotted down a few notes of things I wanted to convey that are important to think about. So, when you're looking at the mobile user interfaces, so mobile HMI, web HMI, these are technologies from ICONICS that deploy to the remote devices. Best practices, definitely think about. There's a lot of things out there, definitely make sure to use HTTPS encryption for the messaging. Not all that hard to set up. There are definitely tutorials on it and how to do it. It's a good idea. You want to make sure you're using an encrypted pathway for anything you're sending out. Online for sure. If you're familiar with the encryption, we can use self-signed or CA signed certificates authority signed certificates. If you really know what you're doing self-signs, okay. Typically, by default, I'd recommend CA signed for standard applications. And also look at using DMZs. So, when you're deploying an iconic system, pretty straightforward to modularize it and make a dedicated web server versus your back-end server. That web server might appropriately be in a DMZ in a lot of situations. And that totally fits well with our architecture of what we typically deploy something to think about. Let's see other things on third parties. So, as I mentioned, integrating to other things, you're not always going to be within the iconic scope. So how do you make sure that you're secure on that communication? So REST and OPC UA, I think would be the kind of the most common interfaces that you'd use for third party here. I'm thinking of things like a work order system and ERP system. These are the more common protocols you might use. Both of them have good options for HTTPS and SSL encryption on that messaging, definitely use that make use of that. That's a good idea.
[13:33]
And yeah, definitely watch out for things that use basic authentication. That's where general rule of thumb, if you look at the message that's being sent for a URL you're connecting to, if your password or your login account is in plain text in there, that's an old technology, don't use that place. Definitely use some things that do full and end encryption on that. And then also think this is not just a technology but think about what you are exposing. There are a lot of things that you can throttle in and out like what sort of data might be exposed via these API's. Not saying make it difficult for that third party to get data. But don't expose more than you have to; it's just good practice that you're exposing the things that are appropriate for that level of communication. And also think about things that are coming from third parties, right. So, I was talking about different integrations as a lot of other systems that we bring into a remote worker environment; make sure that those are encrypted as well. Same thing. Also, if you're sending data out because we're talking about worker location, we're talking about worker information, their emails, their phone numbers, their availability, definitely think about GDPR requirements and constraints. I know that's technically a European constraint, but it's been pretty broadly adopted in the US just by default anyway. There are considerations for it within our applications to make sure that the deployment can be GDPR compliant. Make sure you think about it before you have any exposure of data that's not sending out private information.
[15:12]
So, what would you measure as success with deploying mobile application? The kind of a things to think about if you're deploying a mobile remote worker application, ideally don't interfere with the normal work, right? If somebody is, by and large in the industry, if somebody is out in the field, they're out in the field because they need to go do work that probably involves their hands. If it was something that could be done electronically, they could do it remotely, right. So, if you're out in the field, you’re probably out there to do some work. You don't want to have a technology that requires them to be constantly switching between “Okay, hold the tools and equipment. I have to put these down, go over here and look at my mobile device.” Something really needs to be adaptive to them and also that is not bothersome, right. When we talk about notifications. Step one is “Cool, I can send a notification?” Step two is “Okay, I really only want some notifications. You don't want to be told everything”. So how do you dial in? What's the appropriate amount of information, so I'm not just distracting folks all day long with what's going wrong. Also, things that can be accessed quickly, we talked a little bit about the geolocation awareness. Can I send information appropriate to somebody in a correct location? I don't necessarily need to be informed of something that is going wrong in the other state. If I'm not responsible for that state, definitely this needs to be filtered out. And also, I need to make sure that what I can get to is just one or two clicks away. And also, it’s definitely important to think about, if I want the data flow to be in both directions. As I said, there are a lot of benefits to getting information from the remote worker, just as it is to inform the remote worker. So, you need to think about how they would put information into the system. How are they contributing their knowledge to the overall monitoring of equipment, and of course, security. Please don't forget security. It’s not something you need to be afraid of, just need to know that it's something you should consider going into a solution. Particularly because most of these technologies are internet exposed today. Just know it's there and be ready to think about it.