Developing a mobile app with the Forge IoT API

ALLAN O'LEARY: All right, welcome everyone. We better get kicked off. We've only got 30 minutes. So that's the good news, if you don't like the class, it will be over soon. Today with me, I've got Brian Sherman. He's a senior developer. And we both work on the Forge team developing IoT.

So a quick heads up on the class overview. Was anyone at the last Dev Con months ago we had in San Francisco? Excellent. So Brian and I did a more in-depth technical overview of the API. That class is probably still available online if you want to go back and do some review. But I did say at that class any months ago-- we should have played the clip to prove that I'm a liar-- that if anyone goes away and builds something with the API, I would come back in and show it next year. So that's where we're at.

So we're going to be talking about a real application of the API currently going into production. And what I want to get across in this class is understanding the real application of the IoT platform, understanding how the data flows through the system, use of the messaging and the mobile app as part of their overall solution, and also get you guys excited to start planning your own IoT solutions.

So the good news is we've got a customer using it. The bad news is they haven't quite made it to production yet. And they're very sensitive about their business model and copycats. I'm sure none of you would go out and build a competing system. But they're very sensitive and they asked us not to show any of the exact business model they're using and what it is that they're actually monitoring.

So I've anonymised a lot of the information we're going to go through here. So it is a somewhat fictional example built on what our customer's currently doing using an API. So unfortunately, there's no live demo. I'm not sure how exciting the live demo would be, watching me stand up here with a mobile phone and flick through screens. You can catch me in the hall doing that afterwards. So we're going to get through and basically just show you what they're doing with the API, rather than give you a live demo.

So it's based essentially on our service inspections so right now they're having to do frequent site inspections, visual inspections, people going out, switching off equipment, cordoning off the area, and sitting through and going through the ware points on the machine, different trouble spots that they traditionally have with the equipment.

So this is costly, in that it's man hours to have someone go out there. A lot of the time, maybe for no benefit. Quite frequently, there is nothing wrong with the machine. It's running as it should. But they need to go and check it still. So best case scenario, at the moment, they're losing money on productivity with the machine down. And they're losing man hours with someone having to go and visually inspect a machine that might actually have nothing wrong with it.

Worst case scenario, the machine breaks in between inspections. Someone forgets to do the inspection and we now have a very, very costly repair bill. Now there is a little bit of big brother in this inspection approach as well. They would never accuse anyone of deliberately doing damage, but they believe there's a lot of people that damage the machine, don't really want to report it, she'll be all right, keep the machine running, we'll fix it in a couple of months. So they were seeing issues where people were embarrassed, using the machine incorrectly, and weren't reporting damage.

That was the best and worst case. Their solution, the business model that they found here was fairly straightforward. They wanted to be able to understand when the machine requires inspection and make sure they get ahead of any issues. Of course, the best way to do that is to remotely monitor the machine. So they looked at some key performance indicators on the machine. We'll have a look at what those are as we go through the inspection piece.

But they started to layer this on top of our IoT platform. So this here is a Fusion Connect product. On the right-hand, your left-hand side, is the data ingestion. So these are some standard protocols, devices with sensors and gateways. So we collect the data on our device adapted layer, and we process it with some business logic in order to make some decisions. Is the machine behaving normally? Is the machine not behaving normally? It can be as simple as that.

And on the back end, we've got a mobile API. Which allows us to build, obviously, mobile applications. It also allows us to integrate with other business systems. So we can bring in information from ERP, customer management service ticket systems, and the like. So they've leveraged this mobile API on the right-hand side to build out as part of their overall solution the mobile application.

It's worth noting here-- it's worth noting here that they do have a full application they built on top of their product with a dashboard, and a series of reports, and other functionality. But they don't employ someone to sit in front of a screen and watch all day what activity is going on. So being able to connect with people on site, being able to alert them or drive them back to the application, or to do an inspection is a big piece of what actually makes this work.

So we set the application Fusion Connect. And the application that we're about to show you uses our Fusion Connect notifications. So it goes through triage to what's going on. Sends a text message, sends an email out to the tech on site.

Fusion Connect forms to get data in. Fusion Connect reports to get data out into the mobile application. So, super simple. I think you don't have to be a genius developer to figure out how to submit a form and pull information out via a report. And of course, we're using the Fusion Connect routines and business logic to triage the incoming data and decide what to do with it.

So these guys are going out to site. They're adding a simple device to each of the machines. And they're monitoring impacts and vibration. That's really all they are doing. Has someone hit the machine? Is something running off center? Are we seeing clunking on the machine at the back end? Again, not necessarily someone hitting it with a hammer, but it doesn't exclude that.

They've also put in the tampering and battery. So if someone goes and starts to fiddle with the device, moves it, we know. And also, we get a warning in the system if the battery starts to go low. So they can go out and replace the device. Make sure that we've got that up-time, they're not missing any information.

So this device goes out and it connects to Fusion Connect. During the set-up, they open up their mobile app. You can see I've-- not real app. I've obscured the company name and what they do. But initially, the tech goes out there. They've got a QR code on that device. They open up their mobile application, take a photo of the QR code.

It loads all the information about that specific device. And then they simply enter where they installed it. So it's usually already registered to a certain customer. They probably know the site. All they have to do is just put in the machine serial number they're monitoring.

So now we've connected that data to a machine in the system that we're going to monitor. Super simple, machine serial number, customer, and location. Usually we try to put in some-- north end of the factory, some other information, so the tech knows where to go and look at the machine. So that's the first use of the mobile application, just to set it up.

Now once we get into operation, our device sits there on the machine, monitoring. We have an incident, there's a high vibration, clunking, something sets it off. It sends a message to Fusion Connect. Here, we're actually using local area connections to a gateway which has cellular connection to our platform. So they have one gateway on every site, a couple if it's a very large site, that these devices connect to. And via cellular, we get the message.

So we triage that. We send a message out to the tech and he goes and starts his inspection. So if you look at a little bit of the details-- and as I said, no one's going to be sitting there, watching their monitor, waiting for something to break. We talked about that a lot. Doesn't happen all the time.

So the first thing we do is we send out a text message to whoever is currently working on that shift. So we have a register of which shift it currently is and who's on that shift. They'll get a text message. And it'll give them the machine ID and the machine location. Now this is something that we probably could have put inside the mobile application as well. We could have filed a notification inside the app. But this, for a lot of their customers, was the preferred method of getting the information.

So a quick text message with the location. And a few companies, a few of their customers, are also requiring a text message go to a manager. So the manager is on top of when the incident occurred. And they can start to track how long it was before Johnny on shift number one went and actually had a look at the machine.

So he goes to the machine. And now he's got his mobile application. We go back to our QR code screen. Take further QR code, scan that in. And it loads up all the machine information. So we're now focused on the right machine. We're ready to start our inspection.

And now, this really just becomes a very big form. We're going to go from page to page. It's going to ask him to do a few checks on some ware points to make sure the pads are visually OK, we have the right clearances. It's going to ask him to check the stock around the machine. So now, this turns into a wider safety inspection.

Is all the guarding in place? Is this a safe working environment? Is everything cleared away from the feeder on the start of the machine. So this turns into a mini audit of that machine. But we can be fairly confident that something has gone wrong because we've received a message that says the machine is behaving out of bounds.

So he can go through, he does these measurements, fills it all out. And when he gets to the end of the form, there is going to be some action which is requested of our user here. So worst case scenario, the bolts on the motor have fallen off, the coupling's snapped, we're going to have to turn that machine off and service it immediately.

We can get into an amber mode as well, where we say there's some worry here that's worth noting, but we've got about a month to fix this. So if we don't have the spares on site, if we need to get someone in with more technical expertise to fix it, we flag that in the system as needing some maintenance.

And basically, once it's flagged in the system, every day, or week, depending on which cycle you want, there's a message that goes out that says, hey, remember to come and complete the maintenance task on this specific machine. Eventually, if no one ever responds to it in for weeks, it gets escalated to a red alert, and everyone starts getting emails and text messages again that there's something wrong with the machine.

So we've got some logic in the background there to help with the remedial action. Green means I went and I had a look. Nothing, no problem there, don't seem to be seeing that-- can't hear that clunking noise, there's no vibration, we're good to go. There's also a false alarm here. The difference here being green, there was probably a legitimate reason, but it's actually OK. Blue is there was nothing wrong with the machine. Once we have three blue alerts or false alarms, we go out and we replace the device, put a new one on there.

Now as use as you'd imagine, it's probably fairly easy, once you get used to doing the inspections to make it look like it's not a red alert. They can go in and say, it's just a green, it's just a blue. In the background though, obviously, we're capturing who did the inspection. So we know when they got the message. We know when they went and looked at it, when they opened it up and started the inspection. We know when they finished the inspection and we know who it is.

So if you submit 20 blue false alarms in the space of a couple of months, you might not be sent out to do any more inspections. So this is a little bit of the smarts that goes along behind it. So really, really simple example there. How we doing for time? I want to make sure we got questions at the end.

15 minutes.

We got 15 minutes still? Good. So the example here, really, really basic. Now, we see we were still required to go in and configure the routines in the background. So there was a significant amount of time getting the logic and the data flow set up. But once we want to build that mobile app, super simple. It's really just I submit a form and request information of our query that we have set up. So just two calls to our API is essentially all you need to set up that mobile application.

The value, of course, is the data that we're getting in and out. That's what makes the app actually useful. It's a mixture of, obviously, the IoT data, the connected machine, and the visual inspections that we're doing. So the challenge is to find a business case in your own fields or with your customers you're working with. We need to define that business value really well, which is what this company did.

Straight away, they can go out to a customer site and say, we're going to cut down your inspections by half. You're going to have immediately 100% more up-time on the machines, 50% more up-time on your machines, and less time doing inspections. So, super simple value proposition. And the mobile app means that people are actually going to use it. They're not walking around with a laptop, seeing it off the shelf, too hard to do. The mobile app, everyone's got it, nice and easy to execute on.

So that brings us to what next. Does anyone at this stage have any questions about the mobile app you want to fire off? I explained that perfectly, excellent. I want to talk a little bit about what's next for IoT and Forge. So I think everyone, they've walked around today and set in some classes. If you were here in the cool apps being built in the class before this, you'll notice a lot of examples of people showing IoT data in large model viewer. It's pretty sexy, it's pretty cool. So this is, obviously, a big piece of the Forge service puzzle here.

So when we looked at our slide before, I showed you guys an overview of how the mobile API was being used by this customer to build a mobile app. We are also leveraging the infrastructure that we already have in place to build an IoT service that you guys will have access to. So moving forward, you'll see here we've taken the most common protocols, adapted types from our current infrastructure. We've got our data collection service in there. So we're ready to start receiving information.

And what we're going to build on the back of that is a Forge API. So a little bit different to what we had with our mobile API, where we've already got infrastructure that you've set up and you're now leveraging that with the forms and reports. With our Forge API, we're now going to allow you to get information and post information into the system without having to do a bunch of configuration.

So if you want to build a much more holistic solution on your own, we're going to provide you with a bunch of simple methods here to create an account, get account information, create device profiles, get a device profile, create the devices, and get the device information. So this is going to be a nice programmatic way for you to set up an application environment, very quickly and easily.

And then we use our get current and get historic data. So once you've finished building your account, it's going to start collecting data from the devices that you point at our service. You just then use get current data to see the most recent information.

So if we're looking at our example previously of the piping in the factory layout, to get the most recent data, it's going to start to flash those lights on there. It's just going to give us the readings for all those valves and points across your large model viewer model. Get historic data is also going to allow us to see the trend information. So we can have some historical points, go back and have a look at how our machine has behaved over time.

Now as we grow, we're going to see much tighter integrations with the Fusion and the BIM solutions. So using our IoT service to drive visual information into those. And of course, we're going to start coupling it with other Forge services. So everybody's favorite, large model viewer, great way to show IoT data.

We can start looking at building out different workflow engines in here to route that information, instead of just collecting it. We're going to have a look at messaging services in there. So we can start to send notifications out of the Forge service. IDX to build much richer applications, and of course something that's going to be super interesting in the future, is going to be analytics and artificial intelligence. So we've collected all our machine information, we've got the historic and current information. We can start to mine that and actually figure out trends, correlations, on machine performance.

So this is the next to come with our Forge IoT service. If you have questions about what next with Forge, if you need help getting up and running with applications, getting more information, we've got an email address there. You can also harass us after the class. I will be around for certainly today, and this afternoon, and most of the week, if you want to approach us with questions on the IT service.

Another interesting thing for those of you who might be starting IoT projects is we have a Discovery Tool Kit. This is essentially a gateway with some industry standard connection points. You can put in some basic sensors. You can connect it to a PLC unit. We've got RS 485, secure LAN, USB inputs on this thing. So you can connect it and start pumping information securely through our partner electric IMP into your own Fusion Correct free account.

So there's an email address there. You can apply for this. And we only have a limited supply of these. But we're looking for some interesting ideas. Some people that have got some projects on the go that you want to see real data from. So I would also encourage you to reach out and talk to us a little about that.

If you are going to be here for the rest of the week, we do have more information about Fusion Connect for you. So tomorrow morning, Brian and myself will be up early doing a class. Tomorrow afternoon, Lona, one of our product managers in the back there, is going to give you an overview of that discovery kit that we just talked about.

So if you are interested in discovery kit, that's probably one to go to. And building your first IoT project business case is on Wednesday. So that's really about justifying the expense of hooking up the machine and what you want to build with your project.

We do want your feedback. Make sure you fill in the forms. But just to end on a high note, I want Brian to just give you a little quick sneak peak of an application that we do have running now using the new Forge IoT service.

BRIAN SHERMAN: That's right, so the mobile API that Allan has been talking about from classes, what we've currently got in beta right now, we've got customers running on it. And the Forge API, as Allen said, is the future. We've currently got that an alpha, and we've got a demo for you that nobody outside this room has seen, as soon as we switch the screen over.

So what we've got here is an application that integrates a number of the different Forge APIs. We've got the data management API to store different 3D files. We've got model derivatives to give information about those models. And of course, we've got the large model viewer here.

So this application takes all of that-- and many examples of those APIs are available online already-- and we add the extra dimension, saying that perhaps somebody not only wants to see information about each of their models, but they want to track real-time information about the prototypes of that specific model.

So what we've done here is we've added an IoT component very easily. All it took was a couple of API calls to, as Allan said, create an account and configure what kind of data it's going to send, strips away all of the complexity of going into the Fusion Connect user interface and configuring an application. All that entire process is automated.

So after two API calls, your application is immediately ready to start receiving data. We've registered a couple of devices already that are actively sending data this account. And you can see that every second it's pinging Fusion Connect server to see what's the latest data and it's plotting it here on a trend. So a user can come in, see what's going on with all the real machines that are using this particular model they've mocked up.

Additionally, if they wanted to add another, register another machine, they can very simply submit a form here. And it's immediately available and Fusion Connect is ready to receive its data. So as Allan was saying, this strips away a lot of the complexity.

Fusion Connect by itself prides itself on being a very simple, rapid solution that helps you develop IoT solutions. And this takes that principle even further. With a couple of simple API calls, you can immediately integrate IoT with any application. Obviously, this here is not a mobile application, but the principle remains the same. So it allows you to get your IoT solution of the ground even faster. So this is coming right around the corner. Stay tuned on that.

ALLAN O'LEARY: Give you a minute, and you think you're the star of the show. That completes the development portion of the class. I think we've probably got someone butting up right against us at the bottom of the hour here. So we're going to have to finish up. But thank you, guys.

As I said, there's a bit of homework for you to follow up with. If you are interested, check out the dev kit. If you want to know what's coming with the service or want more information about how to use the API in its current form, reach out to us via that email address. And of course, we have last year's class, which goes through in much more technical detail what the API does. So thanks for coming in today.

BRIAN SHERMAN: Thanks, everyone.