How to Digitize Industrial Manufacturing with Azure IoT Edge, InfluxDB, and MAJiK

Session date: Aug 09, 2022 08:00am (Pacific Time)

MAJiK Systems are the creators of a cloud-based factory and manufacturing monitoring platform. Their Visual Factory solution helps their customers monitor, analyze, and optimize operations by providing real-time plant floor analytics. They aim to provide insights into root cause analysis of downtime, quality issues and other production slowdowns. Clients have seen reduction in equipment downtime of 35-45% and reductions of waste and scrap of 7-10%. Discover how MAJiK uses a time series data platform to continuously improve overall equipment effectiveness (OEE) within factories.

Join this webinar as Jared Evans dives into:

• MAJiK's approach to data-driven Industry 4.0 monitoring
• Industrial IoT best practices - including when to use specific protocols (Modbus, OPC-UA, MQTT, Ethernet/IP, or S7 TIA)
• How data from Programmable Logic Controllers (PLCs) can be integrated into InfluxDB - which helps process engineers monitor the telemetry of any automated process or production method

Click here for presentation

Watch the Webinar

Watch the webinar “How to Digitize Industrial Manufacturing with Azure IoT Edge, InfluxDB, and MAJiK” by filling out the form and clicking on the Watch Webinar button on the right. This will open the recording.

[et_pb_toggle _builder_version=”3.17.6” title=”Transcript” title_font_size=”26” border_width_all=”0px” border_width_bottom=”1px” module_class=”transcript-toggle” closed_toggle_background_color=”rgba(255,255,255,0)”]

Here is an unedited transcript of the webinar “How to Digitize Industrial Manufacturing with Azure IoT Edge, InfluxDB, and MAJiK”. This is provided for those who prefer to read than watch the webinar. Please note that the transcript is raw. We apologize for any transcribing errors.

Speakers:

• Caitlin Croft: Senior Manager, Customer and Community Marketing, InfluxData
• Jared Evans: Co-founder, MAJiK Systems Inc.

Caitlin Croft: 00:00:04.639 All right. I think we’re going to get started here. Hello, everyone, and welcome to today’s webinar. My name is Caitlin. And I’m joined today by Jared, who is joining us from MAJiK Systems. And we’ll be talking about how to digitalize industrial manufacturing using Azure, IoT Edge, InfluxDB, and MAJiK. Please post any questions you may have for Jared in the Q&A or in the chat, which you can find both at the bottom of your Zoom screen. We will take all of your questions at the end. Don’t be shy. I know Jared will be more than happy to expand on things that you’re interested in. Once again, this session is being recorded and will be made available for replay later today. And I just want to remind everyone to please be kind and respectful to all attendees and speakers. We want to make sure this is a fun, happy, safe place for all of our community. Without further ado, I’m going to hand things off to Jared.

Jared Evans: 00:01:07.409 Thanks so much, Caitlin. I really appreciate it. And thanks for the warm introduction there. So my company, Magic Systems, we focus on delivering actual factory information to decision makers in real-time, which is why we line up really well with InfluxDB and all the time series, data opportunities that it provides. Sorry, one second [inaudible]. Just a quick about me, so I’m the COO of MAJiK Systems. I focus a lot on our product management, customer delivery, and also partner enablement. In addition to that, I also am a member of both the MTConnect and OPC UA technical advisory groups. So those are two fairly prominent Industry 4.0 protocols that industry is trying to adopt. I really like working within those working groups and understanding, contributing to how to make industrial protocols easier to use and more ubiquitous. At the same time, a lot of what we, as a company, do is working outside of those bounds of those protocols because there’s a lot of legacy equipment. There’s a lot of different setups on the factory floor that don’t really fit in. [inaudible] Apple on an iPhone launch. And we are flying back and forth to China to be on-site with our contract manufacturers and understand what was actually happening on their production floor, what was causing quality issues that we were seeing back in California, what was causing us to not hit our production numbers that we had been promised and were counting on for lunch.

Jared Evans: 00:03:04.268 And as much as I love traveling to China and love understanding manufacturing processes there and seeing it firsthand, at the same time, I couldn’t help but think, “Man, this is a long flight for getting some data that’s probably the lowest [inaudible] rate in the history of data transfers.” So that’s where we started working through what we do with MAJiK Systems. And just as an overall overview of MAJiK Systems, we provide a number of different pieces of software within our overall manufacturing suite. We’re going to focus a lot on connectivity today with our IoTConnect software. We have a range of visualization tools that we’ve been developing since early on in the company’s life that are really focused on overall equipment effectiveness, which is a metric that a lot of people within manufacturing use to judge how well their equipment and their plants are running. That metric is a percentage. So you’d say, “Oh we’re running at 70% OEE or 80% OEE or 30% OEE.” And it’s actually made up of three sub metrics. One is availability of each piece of equipment, so how much it’s able to run versus not able to run, efficiency or productivity, which is if it’s supposed to be able to run at, say, 100 parts per minute during the time that it is running, and it’s only running at 60 parts per minute, that would be 60% efficiency, and then quality, so what percentage of good parts versus bad parts are you making.

Jared Evans: 00:04:56.502 So really, world-class OEE is sort of in the 80 to 90 percent range in a lot of cases, obviously dependent on the manufacturing process. There’s some that are much higher when they’re really automated. There are some that are lower, but they can absorb those costs within their business. But then a lot of manufacturers are stuck lower than that because they don’t have real-time data to make decisions on the plant floor. They can’t surface problems up and down their organization. So that’s what our visual line of software does. And we’ve used more traditional databases for that because we are collecting a lot of event data, like downtime events, production events, scrap, quality event, that type of thing. But we’ve been doing more and more with connecting to other systems and other pieces of software. And at the same time, we’ve been having our customers ask us a lot more about, “Hey, you’re already connected to that PLC, that programmable logic controller over there for that piece of equipment, we want time series data off of that as well. We want temperatures, pressures, vibration, all kinds of stuff, voltage, amperage, draw. And how can we get that? How can we use that to problem solve? How can we use that to do a statistical process control? How do we start enabling AI applications using that series data?” So that’s what really led us to InfluxDB and starting to explore it as a tool to capture and retain that data and help contextualize that data that our basic architecture with our relational databases can.

Jared Evans: 00:06:53.533 So I’ll get much more into that in a little bit. But first I wanted to sort of dive in deeper on PLCs, programmable logic controllers, themselves, as well as how we capture data off of the plant floor and all the difficulties that come with that because there is a lot in that space that can be challenging. And what we see is that’s one of the top impediments manufacturers have to actually start [inaudible]. So our IoTConnect software, which stands for industrial internet of things, connects software. It integrates directly with capital equipment and other plant floor assets to capture data from them in real-time. And we really used that as our starting point to get data to all of the other systems and software that we work with. And what we really try to tell our customers is we don’t want you to reinvent the wheel. Some people who are familiar with this space on the call may be saying, “Isn’t that just what a SCADA system does? Or isn’t that just what a MES does?” We do have an overlap of some of that functionality. Our IoTConnect software is meant to be an edge gateway, which can connect directly to PLCs using their native protocols to capture data from them. But also, if you already have a SCADA system, we’re not going to tell you, “Hey, rip out that SCADA system, and have us connect directly.” We’ll just connect to the SCADA system and pull that information in. Or if you already have, let’s say, a Historian with an SQL database on-site, we’ll just connect to that and pull the data.

Jared Evans: 00:08:53.182 So we’re really trying to be a flexible edge-to-cloud gateway for connecting to all your different plant floor assets. And we have connectivity out of the box for about 95% of controls and sensors in the market. And it’s something that I find really speeds up the time to actually getting an ROI out of these types of projects [with?] software. I’ve used a lot of these different software in past lives. And we’ve really designed it from the ground up to allow for speed and ease of use. You’ll get to see that and judge for yourself a little bit later when I do a demo. Before we dive into that though, I just wanted to give a little bit of our learning around working with industrial control systems and capturing data off of them because we’re not the only way to do that. And I think it’s really important for the entire group, and really, the entire world, to understand how we can start moving towards Industry 4.0 and that type of thing. So just to level set with that, a PLC, it’s an industrial control. It stands for programmable logic controller. It’s an industrial computer in the most basic sense that it monitors inputs and outputs. However, it’s actually not like a normal computer that you would use in your day-to-day. To get philosophical about it, they’re not actually [terrain complete?]. And also, they have a much faster scan rate and are much more robust to environmental factors than a normal computer.

Jared Evans: 00:10:53.068 And these things are really the unsung hero that runs all our modern industrial processes in our lives. They’re used to control automated manufacturing. They’re used in mining to control heavy equipment and ventilation and leaching processes. They’re used to control the pumping of oil and gas as well as refineries. They deliver our utilities. And they even keep our houses and buildings and offices cool by being used for temperature control and environmental controls and things like that. The history of PLCs is pretty interesting actually. Really, what they were meant to do was replace these old relay systems that were sort of that first wave of automation, the Industry 2.0, so to speak. So if you used to walk into factories, and sometimes, still, if you walk into older factories, you’d see banks and banks inside of shielded cabinets of these different wires leading to all kinds of different inputs and outputs and relays and starter motors and things like that. And you’d have to have really detailed wiring diagrams of what everything did, how it worked, all that type of thing, and then making a [inaudible].

Jared Evans: 00:12:39.262 [inaudible] the invention of the PLC because what it did was it took all these relays and wires and everything and turned them into a program that could be loaded into a PLC. And what a PLC does is it takes all its different inputs. Whether it’s sensors, contacts, switches, buttons, relays, what have you, it takes them all as inputs and then runs its program that’s [inaudible] in its memory along with a limited amount of data that it can hold in memory, evaluates it through a CPU, and then fires it to different outputs for, say, relays, starters, valves, solenoids, lights, and displays. So say you had a level sensor in a water tank, as well as a switch, if the switch gets turned on and the sensor hits a certain level, then a valve will open and let that water out. And the PLC actually, it gets programmed by a PC connected to it that’s then later taken away when the PLC is actually in run mode. And then you can also have communications with the PLC to other PLCs or SCADA systems and things like that. And so it evaluates on a very, very fast loop. And then you can get limited communications out of it, both for the data that it stores in memory, as well as what the current state of all its inputs and outputs are. So that’s what you can map to actual information that’s useful for decision-making in the plant. And it’s a huge amount of IoT data that can be captured off of these.

Jared Evans: 00:14:32.270 The only problem with that is that back in the 90s and early 2000s, all the different PLC manufacturers decided that they had a really good idea for how to set up an industrial protocol to communicate with the PLCs. So pretty much every brand has its own — and even within the same brand, different makes and models, to have different protocols for all these different manufacturers. So Allen-Bradley sort of standardized on ethernet IP. But they still have older DeviceNet and PCCC. Siemens has two different protocols floating around. There’s legacy protocols for Mitsubishi, [inaudible]. A lot of devices still use Modbus, so actually one of the oldest protocols for industrial data transfer. And then we’re starting to see newer protocols in place in terms of MQTT, AMQP, even APIs for some that are now hybrid PLC [TCs?]. So if you want a full solution to be able to capture data off of the plant floor, you may need to employ any or all of these protocols at any given time to be able to capture data from these devices.

Jared Evans: 00:16:02.686 And like I said, our Visual Factory software and our line of visual manufacturing software, that’s been our bread and butter since 2014. We use it to find root causes of downtime for our customer, quality issues, production slowdowns, and help improve that overall equipment effectiveness metric. What we’re seeing now is a lot of customers are actually looking to go deeper than just that though, and actually dive into the process data at an enterprise-level, understand what their best plants are doing, [inaudible] understand what their plants that are having the most problems are doing. And we’ve seen some really great results from applying what traditionally, in [inaudible] manufacturing, would be called statistical process control to these types of more cloud-based applications. So we’ve seen customers be able to reduce their downtime by 35 to 45 percent, reduce waste by 7 to 10 percent, all by taking that OEE as a starting point, and then diving into process data and IoT data from using InfluxDB. And just before we go further on that, I just want to really reiterate how big a deal this is because for some of our [inaudible] equipment can cost $60,000, right.

Jared Evans: 00:17:44.263 It can be hugely expensive to have downtime in today’s just-in-time environments. If you’re missing delivery shipment to customers, they can [inaudible] you back and cause you to have to pay damages to them, all kinds of things, as well as just having to run more overtime to catch up and things like that. So when we’re talking about that, if you can reduce — say you have two hours of downtime a day on average, which isn’t at all out of the realm of possibility for a manufacturer, if you can reduce that down to one and a half hours, one hour, something like that, you can be really, really having a huge ROI on these type of projects, which is extremely exciting. Now that we’ve started to dive into this IoT focus and process data focus, we’re also seeing a lot more opportunities for machine learning and AI applications, especially with all the tools that InfluxDB provides. So we’re looking at being able to do more around operational technology, network health monitoring, smart detection of assets on the plant floor, adjustments to shift targets, starting to figure out, “Hey, here’s a change you made on the plant floor. What actual financial impact did that have to your operations?”

Jared Evans: 00:19:23.850 And another one that we’re really excited about that we’re starting work on is looking at energy optimization and tracking energy usage of individual equipment. Some of the energy bills for some of the biggest manufacturers, especially if they’re doing, say, smelting or other metal working, are just enormous. I know within Ontario, Canada, where I’m located, I think 6 of the top 10 energy consumers are steel mills across the entire province. And they get hit with much higher energy bills when they go over a certain threshold, right. And that can be caused by a lot of different things. So there’s a lot of interest for that as well. So we’re really excited about adding that into our product roadmap now that we have the capabilities to work with all that IoT data. And we’re excited to see what our team can put together in terms of solving some of these problems with higher-order analytics. Just in general, and this is a very sparse diagram, but I just wanted to sort of level set everybody sort of how we get data off of the plant floor and what we do with it when we land it in Azure before I jump into our demo. So like I mentioned, our IoTConnect software, it runs on a physical hardware gateway within the plant and connects to different controls on-site. We actually run a couple of different docker containers within the Azure IoT Edge runtime, including our main IoTConnect software, as well as monitoring and logging software to ensure that we’re keeping all our device connections alive and all that type of thing. And that gets pushed up.

Jared Evans: 00:21:23.620 And we’ve actually started using InfluxDB to do some of that monitoring and alerting around that as well. And then it also [leads to?] opportunity to actually push machine-learning models back down to the Edge in the form of a containerized application too. If, say, we make some sort of good inference from a machine-learning model that we’ve developed in the cloud, we can push that back to the Edge and start running that against real-time data that comes in from the equipment. So that gets transferred from that device up to Azure IoT Hub. We’re a big Microsoft partner. We use Azure IoT Edge to IoT Hub for all our data transport needs. We find that it’s the best and most secure in the industry. They put a ton of R&D into it. And it works really well for our use-cases. I will say, though, other cloud platforms have also developed very similar IoT [inaudible]. You can also potentially use — if you’re sort of rolling your own application, you could potentially use an MQTT broker. One thing that we do a lot of though is we do a lot of data transformation and manipulation on the Edge before it gets sent up to make the data make sense. And you do need something that can actually communicate to the devices. So that’s where we live. And then we let IoT Hub worry about the transport.

Jared Evans: 00:23:12.127 From there, we use a couple different Azure services, very cost-effective services for sending data to different applications. So we use Service Bus for some things, Event Hub for other things. Our actual Visual Factory application runs as a Kubernetes cluster. So we can scale up with different organizations depending on how many sites they have, how many pieces of equipment they have, that type of thing. And then we also orchestrate that using Terraform. And we’ve now orchestrated spinning up an instance of InfluxDB when we are doing that as well. So that’s really exciting because we can start offering that to customers more easily and in a simpler matter. We’re usually having to work with the customer if we’re hosting on their Azure tenants on some of their goals as well, like if they want data lake or if they want integration with their ERP system, that type of thing. So it gives us a lot more flexibility.

Jared Evans: 00:24:28.493 So I’m just going to walk through a quick case study on sort of — this is one of our early uses of InfluxDB just to sort of give a highlight of how the customer derived value from it. And then I’ll get into an actual demo of using our software to connect to a PLC, send the data up, and set it up in InfluxDB. So we’re working with a customer that did metal extrusion. We got them set up. They started using some of the Visual Factory tools. They set up some notifications for if they ever had downtime that exceeded 30 minutes. They want to get a text and email notification. So we have that as well as an in-app notification that would prompt them to investigate it more. So they started getting — and they really didn’t think they were going to get any 30-minute downtimes. They thought, “Hey, that’s pretty long.” They did start to get a couple though. And once they actually dived into their downtime records within the Visual Factory system, they saw, “Okay. Yeah, we have a 30-minute downtime. But then we have a lot of smaller downtimes too that weren’t necessarily being reported by the operators,” right. The operators were saying, “Hey, we ran fine pretty much the whole shift. It was pretty good.” But then there’s a lot of smaller downtimes. So they actually dived into it. And they actually saw an increase from one day to the next. So they knew, “Hey, something’s going on here. Something’s not working right anymore.” They haven’t started assigning reasons for the downtime within our system yet. So they didn’t have that much to go on as compared to like having an operator have a reason and a comment added, that type of thing that they could investigate.

Jared Evans: 00:26:26.060 So they had to look at other tools to be able to root cause this and fix it. So we had been capturing a lot of the process data off of the presses. And they were using InfluxDB and Chronograf to review some of that telemetry data. And one of the pieces of process data they were looking at was the butt length, which is like the little piece of leftover metal after the press pushes it through. And they were finding that they really weren’t supposed to have any long butt lengths. But they started to see, “Hey, we actually are getting quite a few. And they’re correlating exactly with when we’re having those downtimes.” So that allowed them to actually sort of pinpoint that and go out on the floor. They found out that their butt sheer mechanism, so the part that was cutting off that last little bit, required [inaudible]. So that made them realize, “Oh man, we’re both having downtime, plus we’re scrapping much larger pieces of metal which are not going to be able to be recycled back or anything. So we’re giving away material too.” So there comes that scrap portion of it as well.

Jared Evans: 00:28:07.885 So what we helped them do is set up a notification that would notify them whenever the butt length, over 1.5 inches, was hit. That would be a precursor to downtime for them. So now they’re able to respond immediately rather than waiting for, say, a whole day or a whole cycle before they say, “Hey, what was the problem? Let’s talk to operators,” and things like that. So they’re being able to avoid engineering scrap, avoiding potential downtime. And it’s a huge win out of just a small amount of industrial IoT data. So just imagine what they’re doing now in terms of looking at temperatures, pressures, voltage, all kinds of things, right. Another thing that we’ve used InfluxDB for with a customer is actually network monitoring as well. Industrial networks can be unstable. They can drop in and out. There’s a lot of electromagnetic interference out on the plant floor because of spinning drives and all kinds of stuff. So it becomes really important for any data capture application to have good network connections and also notify and get ahead of any network drops, right. So some of our solution implementation engineers have started even just putting together like effectively implementation databases and monitoring databases to track that type of information more closely and root cause during the implementation phases of projects.

Jared Evans: 00:29:53.108 So I always start with the use-cases within and the ROI within this. It’s very important for manufacturers. They often have low margins. They make it up on volume. So it’s really important to them any project that they take on isn’t exploratory, it has a concrete, “Here’s what we’re going to do. Here’s our expected result, plan, do, check, act,” and understand how they’re going to recoup the money that they put into a project. So I’m just arming everybody with that. As you’re talking to manufacturers, talking about IoT data collection, things like that, these are some of the experiences we’ve had of how this [inaudible] ROI. That being said, I know that everyone is likely more interested in — on this call, more interested in demos and seeing software in action than necessarily business use-cases and things like that. Though again, I would stress, it’s very important, especially within the manufacturing. But what I was going to do now to sort of wrap up is show a quick walkthrough of connecting to a PLC using the MAJiK IoTConnect software. If you’re interested in trying out the software or using it, please feel free to reach out to us either through our website or through my contact information, and we can get you a demo copy, let you give it a try. Also, we’re not the only game in town. There’s definitely other ways to capture data and get it sent up to the cloud as well.

Jared Evans: 00:31:52.976 So if you’re wanting to explore that, hopefully, this will give you an idea of some of the challenges and also opportunities for it as well. So I’m actually on our office VPN. And our office network has some test PLCs on it. So I’m going to go ahead and add a device. I’m just going to say Influx demo PLC. We have a nice little explorer here too. I can select the brand. So it’s an Allen-Bradley PLC. It’s a CompactLogix. And then I just got to look up the IP address that I wrote down. [inaudible] we might have to refresh here. I might be having a little bit of an issue. [silence]

Jared Evans: 00:33:07.385 Okay. There we go. So I’m able to ping the device on the network. So that’s a good first step. That means there’s something there on the other end. I’ll go ahead and save that. Now the software itself has recommended the protocol that it thinks I should use based on the brand I selected and the ping. So it’s saying, try using common industrial protocol. It also has a couple other suggested protocols and then the rest of the protocols that we support if maybe I know something it doesn’t, right. But I’ll [just?] stick with CIP for now. I need to add a connection name just because there can actually be multiple connections to a single device over different protocols. So if that is the case, you want to have different connection names to keep them straight. The connection name itself doesn’t do anything. It’s just for your readability for these different connections. You can see the same IP addresses here that I put in. And then it’s also recommended the default port for that protocol. So I can go ahead and test the connection. I can see, “Okay. Great. CIP worked with 44818.” So that means now, I can move on to the next step, which is adding some tags, adding some data tags. If you remember back to our discussion around the PLC, it has those memory tags and the input and output tags. So I can actually — because of this PlC’s structure and protocol, I can go ahead and browse the tags. More modern PLCs have this capability if you have software that’s set up to be able to do it. Other PLCs that are older only have memory addresses and things like that. So you need to do a little bit more work with the PLC program for it.

Jared Evans: 00:35:05.211 So I can see all these different atomic tags here. And I can actually test them and just get a quick reading, see what they’re doing. So I have a few different tags here. I have this weight total tag. It seems to be fluctuating or actually maybe just increasing. I have an emergency stop tag. It’s false right now. So it’s not in an emergency stop mode. Nobody’s hit that button. It also has a proximity tag for a proximity sensor. So probably, somebody left a little nail right beside it we have for testing in the office. And then this [dosing?] count per hour is just staying at one. And then we have this other tag that’s fluctuating. So in this case, I don’t care too much about these boolean tags or this static set point tag. I am sort of interested in this total weight tag and this other tag that’s fluctuating. So I’ll save those. And then I can also go ahead and do a couple other things here. So I could set the time out for this, as well as the polling rate. I’ll leave that at one second. I can also change the output paradigm here, either from sending all data or only when the data changes. And that can be really important for an IoT application because if you have a jittery sensor that’s changing all the time, but in a very small band, that can chew up a lot of data without you really caring about it, right.

Jared Evans: 00:36:56.447 Like if you have a temperature sensor that’s bouncing between 70.1 degree Celsius and 70.2 degrees Celsius for most of the day, you don’t really care. If it goes up to 78 or 100 degrees, okay, yeah, I’d care. I really want that, right. But [inaudible] this is all for now. But being able to send it on change-only is quite important. I’m going to add additional attribute called the work shell ID. And I’m going to call it [inaudible]. [inaudible] in our implementation of this, that’s very important because that’s what sets up part of the key value pairing within Influx. And we have documentation around that. So I’m going to save this now. Now, some of you may be familiar with this interface. We’re a contributor to the open-source Node-RED project. We’ve also developed a bunch of our own nodes for connecting to different types of PLCs as well as other cloud systems. So I’ve just set up our proprietary CIP node for that PLC and captured some data. And now I’m going to drag on an Azure IoT node here. By default, how we have this set up is that it uses — it’s set up for HTTP. I can set it for MQTT, so if I’m doing this to an MQTT broker or AMQP, what have you.

Jared Evans: 00:38:51.923 And then we ship our software with an environment string for a specific IoT Edge and IoT Hub instance to make that secure connection. But if you’re setting this up fresh, you could turn that off. And then in my instance of Azure, once I’ve set up an IoT Edge and Hub pairing, which is a really simple walkthrough, it just takes a couple of minutes for Azure to instantiate it. So I did it before the demo just so we’re not all sitting here. I can take then — all I need is actually this primary connection string. I just need to copy it and then bring it over here, [paste?] it in. And then that’s going to set up my connection from the edge within the plant in a secure, encrypted manner out to Azure. So then I can just connect these two nodes, and that’ll start sending data. I could add a debug node if I wanted to. This debug node comes with Node-RED. These other nodes are MAJiK proprietary nodes. But then I can see debug if I need to test anything. Node-RED also comes with a number of different types of functions and things like that. So like I could even write a little bit of JavaScript, say, if I wanted to transform a tag for something.

Jared Evans: 00:40:35.142 And we’ve sort of seen it all, like maybe translate from Fahrenheit to Celsius or Pounds to Kilograms or change the time zone tag or things like that. But anyway, I can do all of that, hit deploy to save it, go back to my main screen within IoTConnect, which is back at the device management level. And I can see, “Okay. We’re connected on this demo device.” And then I can also see the individual connections and make sure that it’s all going well. And then I’m not sure why it’s saying not read because it is reading right now. Maybe I’m just having something bug on my internet connection. But now that that’s all done, I can actually jump over to Chronograf here that I have with my InfluxDB instance that we deployed with our Terraform script that also deployed IoT Hub and Service Bus behind it. And I can actually go into the explore area. My webinar Influx instance has been generated. And then I have my press here that I can look at by work cell ID. And we written some software to set this up to actually tag from that attribute work cell ID that I sent in. And then that WC1 that I set up, all the data is partitioned by that. So I can choose that. And then I can see my two tags that I have. So I can turn on my weight total, which we were seeing is just going up.

Jared Evans: 00:42:26.379 And I’ve been running it already this morning just to sort of test some things. [inaudible]. And then I also have my LIT 106 data that was fluctuating here. So this is the data that we saw from the PLC that was jumping up and down. Now I have it in the database at a time series level where I can start exploring it, all that kind of thing within Chronograf or using it for other applications from Influx. So that’s sort of the long and short of it. I see we’re sort coming up on 11:46 my time here. So I think we have less than 15 minutes left in the webinar. So I wanted to get through that and give everybody some time to ask some questions for 10 minutes or so here before we have to sign off. But yeah, thank you very much. And hopefully, everybody found that interesting and informative of what we’re working [inaudible]. [silence]

Caitlin Croft: 00:43:51.794 That’s amazing, Jared. Thank you so much. It’s interesting. All those spikes is that within an hour?

Jared Evans: 00:44:02.102 So one thing I’ll just say is we’ve programmed this PLC to be as dramatic as possible for demo purposes. So you probably wouldn’t see all these spikes, usually, from a set of data. But it does give a really nice visual representation, obviously. I just have it set for the past five minutes. So this is just coming in since I set up that flow from the PLC. So our demo PLC code is making it go crazy like that so we see something cool. But you can see that in industrial processes, right. And then manufacturers love when they can drill in on things and start to understand like — again, this is just a demo. But here, you might look at it and say, “Hey, why did that one not go down as much, right, if this is a real thing.” So I see a couple of questions here.

Caitlin Croft: 00:45:09.709 [crosstalk] would you like me to read them out?

Jared Evans: 00:45:12.521 Sure. Sure. That sounds great.

Caitlin Croft: 00:45:14.859 All right, “Thanks a lot for the presentation. How did you interface InfluxDB with Node-RED?”

Jared Evans: 00:45:23.217 Right. Yeah, great question. So we are using IoT Hub as an intermediary because that Node-RED instance, along with our IoT Connect software on top of it, is running on the Edge, right. Like in this case, it’s actually running on my laptop. But it would usually run on the Edge. And then that data gets pushed up to an instance of IoT Hub that I created. From there, we’ve written some software to interface that data through Azure Service Bus into InfluxDB using Influx’s tools and things like that. However, you could also be writing your own tool or using that kind of thing for getting the data into Influx as well. But it is a really key component. It’s getting it from the Edge out to the cloud system.

Caitlin Croft: 00:46:37.090 Perfect. Let’s see, “Industrial IoT device management looks great and easy. How did you connect to so many PLCs with dedicated drivers, using open libraries? Is it Kepware, other middleware, or somehow from scratch?”

Jared Evans: 00:46:55.615 Yeah, great question. So keep in mind, we started our company in 2014. So we’ve had like nine years effectively, at this point, where we’ve done a ton of work developing drivers and things like that. We also contribute to some specific open-source projects, as well as I mentioned off the top, I’m part of the OPC UA working group and MTConnect working group. So our company really works within those frameworks too. Again, there’s so many opportunities for all of these that we try to give back as much as possible on that kind of stuff. But for some of them that are more proprietary, it honestly started with us taking the IEC spec, reading through it, getting a device using Wireshark, and building our own drivers. That being said, we did that because we had very specific idea around data collection and things that we needed. I know for example, like Kepware can be great, especially for proof of concept projects and things like that. And then IoT Edge itself has an OPC driver that can just be deployed natively. Like they just have it on GitHub. So then you could interface your IoT Edge module with OPC UA on it, with Kepware too to pull it as well. But we have done a lot in terms of that workflow for set up as well as a lot of back end on the drivers to make sure that it’s working more for like an IoT-type application. And that’s why we made the choice to develop that.

Jared Evans: 00:48:55.016 So like I said, if you’re interested in trying it out yourself, trying out our software, please drop me a line either through our website or from the contact information. In fact, I’ll pull that up here just so people have it if you’d like to try the software and maybe walk through some of this, set up with it yourself.

Caitlin Croft: 00:49:24.761 And also for anyone who maybe misses this, you can also email me, and I’m happy to put you in contact with Jared if you have any further questions or want to try it out as well. “Are there any insights or analytics on this with time series data?”

Jared Evans: 00:49:43.715 Yeah, good question. So like I said, InfluxDB is fairly new for us. So we have a very extensive roadmap of what we want to do now. And we’ve definitely been utilizing Chronograf as well and then also building this into some of our own application. We also have a lot of analytics, more for event-type data on like downtimes and production and things like that with our Visual Factory suite.

Caitlin Croft: 00:50:16.994 “What is the minimum scan rate you have tried to read data from PLCs? Have you tested 100 milliseconds?”

Jared Evans: 00:50:27.377 Yeah, great question, and obviously, somebody who knows their PLCs. So the minimum we’ve been able to achieve is about 50-millisecond scan rates. And one thing that we do with our software though, like I was sort of alluding to, is — well actually, you can set the scan rate. But then the software will also dynamically adjust if the network isn’t capable of supporting it because you really don’t want a lot of undelivered packets floating around an industrial network that’s time critical and things like that. So we have done 50 milliseconds for a customer. They were in a very intensive stamping process that you really needed to see the full curve of how the press is applying weight and things like that. Most of our customers, they don’t need it that fast. So it’s always a little bit of a game of tug of war with that.

Caitlin Croft: 00:51:40.029 “Do the PLCs have to connect to the internet for this? And if so, how much of a security risk is that?”

Jared Evans: 00:51:48.649 Yeah, great question. And they do not connect to the internet because that would be a huge security risk. We hear all the time now around PLCs really weren’t meant to be on a larger network. They don’t really have built-in securities themselves. And then that combined with the fact that they can control physical processes make them a very, very ripe target for hackers and bad actors. So that’s why we have the Edge and cloud architecture. So our Edge device runs inside the plant on the same network, same subnet as the PLCs. And it connects just directly to the PLCs. It can also be orchestrated from, say, a network administrator standpoint so they can monitor traffic and things like that. Then once that data is collected on that Edge device in real-time, we use the IoT Edge and IoT Hub encrypted connection to push the data out. So an outward-bound connection is much more safe than something making a connection from outside-in. So when it phones home and starts pushing data, we don’t actually know necessarily where it is, right. And then by we, I mean like our software doesn’t know where it is. It just sees, “Oh this device connection string is making a connection from this shared IP address that then goes through all the company’s firewall processes.” And we start accepting data from it based on that.

Caitlin Croft: 00:53:34.426 Someone says, “Thanks for the presentation. Have you had any experience using Flux?”

Jared Evans: 00:53:42.041 Yeah, thanks for that. And thanks for the question too. It’s actually funny as our customers have been wanting to do more with it, with the database, and also us as well. We’ve been using TICKscript a lot. We’ve actually been finding a few limitations for some of the things that we want to do with TICKscript. Just in terms of if people want to get like different types of notifications or alerts or things like that, it starts to get a little bit convoluted for the average user as well as a little bit tricky to maintain. I just think it wasn’t really meant for what we’re trying to use it for. So we’re very excited to start using Flux and see if we can knock off some of these use-cases that customers are asking for with it because it does seem like it’s going to be really good. I haven’t had personal experience with it. A couple of people on our team are trying it out as we speak though.

Caitlin Croft: 00:54:43.488 Yeah. And I will just shamelessly plug InfluxDB University again. If you are brand new to Flux, and you’re just trying to figure out the basics or even more advanced queries, definitely be sure to check out InfluxDB University. It’s completely free. And there’s a ton of really fantastic courses that have been developed by a bunch of data scientists. So if anyone has attended InfluxDays and gone to one of the Flux trainings, actually, the on-demand Flux training courses have been developed by the same group of people. So it’s really great. I just threw a link in the Zoom chat to InfluxDB University. So check it out. It is completely free. And you can start getting familiar with it. All right, if anyone has any more questions for Jared, please feel free to post them in the chat. I know someone was asking for more technical information. Please feel free to email me. I’m happy to connect you directly with Jared if you want to go deeper into more of the technical stuff. And if you’re interested in data sheets and other content, be sure to check out our website. And we also have a lot of videos. If you go to our YouTube, there’s all the [inaudible] developer videos. And, of course, the training, there’s lots of videos within InfluxDB University. My last question for you, Jared — and I know we’ve talked about this before. But just one final, any tips or tricks that you wish you had known prior to using InfluxDB that you’d like to share with the wider community?

Jared Evans: 00:56:20.672 I’m think there’d probably be two. One is sort of what we were just talking about, is don’t try to get too fancy with the TICKscript. Just try to have sort of more simple use-cases for it, that kind of thing. And it might be our inexperience, but we’ve gone down a couple of rabbit holes where we’ve tried to implement something with it. And it gets pretty convoluted pretty fast for us. And like I said, I think it’s because we’re sort of pushing it into an area that is not really meant to service and we’re just sort of exploring. But that would be one thing. And then secondly, it took us a while to sort of get how the data structures and different data collections and things like that are set up in Influx. And I think we maybe just assumed it was going to be very similar to a relational database with a bit more power under the hood, so to speak, when we got started when, really, there’s a lot of really good features around looking at data in different ways and how it calculates on the fly for — well I shouldn’t say metadata but analytic data on data sets like maxs and mins and averages and standard deviations and all that kind of stuff. So take the time to read the documentation. Go on the website. Go to the university, and do it, because there’s a ton of powerful features. And I think we probably spend a little bit too much time sort of [busting?] around ourselves rather than getting all this really good information handed directly to us.

Caitlin Croft: 00:58:19.899 Yeah, absolutely. And I will say, just because the use-case that you were showing today is an industrial IoT use-case, what we do find, especially with the IoT use-cases, is when you first start out, you end up collecting a lot more data in InfluxDB —

Jared Evans: 00:58:35.845 Yeah.

Caitlin Croft: 00:58:36.168 —than you might need. And that’s pretty common with time series data. I think that’s a misconception. People just start collecting all the data because they’re not sure of what they need. And then over time, they figure out, “Okay. Maybe I don’t need it at the millisecond granularity. Maybe I only need it at the second granularity or even minute.”

Jared Evans: 00:58:57.793 Yeah. No, that’s a really good point. And I think just in general, with IoT architecture, it’s important to sort of push some of that to the Edge. Like do some of that paring down of your data at the Edge, like only getting things when they change versus collecting all data and looking at like, “Okay. Do I really need data captured this often?” It’s important for your data storage and the growth of your data. It’s important for being able to find insights faster. And then it’s also important, at the Edge, to not overload these control systems because they have their own job to do in terms of managing the industrial process too. So I think that’s a really good point to take away as well, Caitlin.

Caitlin Croft: 00:59:54.733 Awesome. Well thank you so much, Jared. And thank you, everyone, for joining today’s session. Once again, it has been recorded. And if you want to check out the recording or the slides, be sure to check out the website tomorrow. It will be available. And if you have any questions for Jared that you forget and think about later, just feel free to email me, and I’m happy to connect you with him.

Jared Evans: 01:00:21.273 Thanks so much.

Caitlin Croft: 01:00:22.875 Thank you, everyone. And I hope you have a great day.

[/et_pb_toggle]