Ignition Community Live: Ask a Sales Engineer

Featuring Travis Cox

55 min video  /  49 minute read
 

Speakers

Travis Cox

Co-Director of Sales Engineering

Inductive Automation

The Ignition community always asks outstanding questions about industrial automation, software, and technology. For our second installment of “Ask A Sales Engineer,” Co-Director of Sales Engineering Travis Cox will answer attendees’ questions, whether about SCADA, HMI, IIoT, digital transformation, machine learning, Ignition, or beyond! With such a wide range of important topics, missing this webinar is out of the question.

Webinar Transcript

00:00
Travis Cox: Hello everybody, and welcome to another edition of Ignition Community Live. This is Episode 37, “Ask a Sales Engineer.” I'm gonna introduce myself, I am Travis Cox. Hello, everybody. I am the Co-Director of Sales Engineering here at Inductive Automation, and really excited to be here today because this is what we do every single day, we help customers through any of their technical questions and demonstrating the product. And we're solution architects, so we love to be able to show people what's possible and to overcome any issues that they have. So I'm really excited to be hosting today's ICL.

00:37
Travis Cox: So normally when we do a webinar, we answer questions during the last 10 minutes, and there are always more questions than we can respond to. So today is different. I'm gonna spend the whole time answering your questions about industrial automation and Ignition, whether it's about Ignition, SCADA, HMI, IIoT, machine learning and artificial intelligence, the cloud, the edge, scripting, security, I'm gonna take your questions and do my best to answer them. So to send me a question for today's session, just simply type it into the questions area of the GoToWebinar control panel. Alright. So if you find that, go ahead and put those in. I'm gonna review those questions as they come in and we'll take them live. So let's go. Ready, set, ask.

01:22
Travis Cox: Alright. So let's go with the first question here, "What is the best way to deal with alarming over multiple real-time tag providers on a single site? Alarm journal filtering doesn't support OR logic, so how could we have two alarm journals that show line one plus common alarms and then line two plus common alarms in another?" Okay. So that's definitely a good question, and I'm going to actually bring up Ignition here. So we'll use Ignition and show some of the things as we answer these questions. So in particular, what we're dealing with here, let me go ahead into the configuration area, is essentially, we can have one or more real-time tag providers. So let's create another one here, I'm gonna call this “tags.” And so I've got a default provider and I've got tags, I could have many of these. And so the idea is that we can configure tags in there and have alarms configured on those tags in each of these providers.

02:25
Travis Cox: And so when it comes to the storage of these alarms, to store in the database, we create alarm journals. And alarm journals, we can have one or more profiles here. And essentially, every alarm that gets generated will go through all of the profiles that are here. So if I have four profiles, that alarm will go through it, and the profile will determine whether or not it's gonna actually log it. What we do is specify a data source that we want to log it to, and then we can specify the filters here, so what type of events do we want and what kind of data do we want, and of course, do we wanna filter on source, display path, or something like that.

03:10
Travis Cox: And so ultimately, if I had two alarm journals with no filters in them and they're going to two different databases, we're gonna mirror the history to two different databases, we're gonna log to both of them at the same time. So if I want to have the OR condition, because there is no OR here, these are just, the what we're gonna... the path that we have in here... Well, actually, we can have multiple paths that we can have by comma separated, so that could be the OR condition there. But ultimately, we can generate one or more of these profiles, we can put the filters in there. Even if it's the same or different database, again, the alarm will come through, if it passes, it'll be logged to that particular one. So feel free if you need to create two profiles to log two different sets of alarms to the same database, you can certainly do that with the alarm journals. So that's a good question here. But I do believe, though, that you can have multiple sources comma separated, so that should be an OR condition within this because you wanna be able to match multiple different paths that we wanna store there, so you could try that.

04:26
Travis Cox: Okay. Let's see. Let's take a look at some other questions. Alright. So another question here is about Perspective, we had a couple of questions about Perspective, but it says, "In Perspective, I'm using the file upload component to upload images and store at a location on the local disk, but I'm not able to show that image in the image component or inline frame, is there a way to do that?" So, yes, there's a couple of ways that you can do that. So the way that Perspective works is that if I'm gonna show something in a browser, that thing has to be exposed to the web server. So that file that we uploaded to our local disk would have to have a URL path to that particular file in order for this to work. So that's one way that we can accomplish it.

05:13
Travis Cox: So I'm gonna bring up here... It is very possible to actually store on the local disk. Instead of storing it in a... arbitrary location, you can... Let me bring this over, you can actually store it into the web server directory. And when you do that, it actually can be exposed and on the web server itself directly, and you can have a URL to that particular file. So that's one way that people have done it. But the problem, of course, is that if I move Ignition, if I take a backup and move from one Ignition gateway to another, of course, those files aren't gonna come across because they're not in that directory on that new server. You have to move those files manually. So that's one way that you can accomplish it. Another way that we could accomplish it is by actually leveraging our WebDev Module. So I'm gonna go here to our docs and go to WebDev.

06:12
Travis Cox: And so WebDev is basically a module that allows us to add endpoints to the web server. So we can essentially program against the web server. And we can have different resources, but as you can see there's an actual file resource that we can add. So if you have a file resource, you can actually point it to a particular file on your file system, and that would be exposed to that server. The other way to do that is actually to have a mounted folder. So if you have a folder where you're putting all of those particular images, you're storing it, you can use the mounted folder, and everything inside that folder will be exposed. You'll have a URL to those. And you could just simply... in your image component, just have the /system/WebDev that URL to that particular resource, and you're good to go. So if we can get it to the web server, it's very, very simple for us to display it in the image component.

07:00
Travis Cox: Now, the third way that we could potentially do this is... Especially people who store images in the database, in a SQL database, again, we can leverage WebDev to expose that as a file by reading that blob, the byte array, and exposing it as an endpoint. But we could also get the bytes of the image, and we could convert it to a Base64 string. And you could actually set the source of the image component to something like this. So if I actually do this... Let me bring... Open my designer and simply go to a new view and put the image component on here. If I put the source over here to that string that I just copied there, you can see that I've got this image, right? It's not a very good one, but the point is, is you can have this string as a source. So it could be going to a URL on the web server or could be going to this... The source string. Either of those would allow you to display that particular image.

08:01
Travis Cox: I think it's best to leverage WebDev, it's the simplest, so you can actually have that URL that you can go against. And the second follow-up question to that was, "If there's a button click or an event, how can I open the PDF or image in the new tab... In the next tab of the browser?" So this is even easier when we have it as a URL through WebDev, because then I can just use our system.Perspective.navigate function to a new tab with a URL that's going directly to that particular resource. So hopefully that answers your questions... Your question here on the images. Alright, so let's take a look at some more questions. Alright, so this... Here's a question here from Keith, he says, "This is probably pretty basic, but can you go over using a drop-down list for page navigation in Vision?" Absolutely. So the way that that works is... Let me go over to a Vision window. So we could do the same thing really with either Vision or with Perspective. Perspective happens to have some built-in components for this type... This style of navigation. But with Vision, basically the tab strip component, it has built into it a navigation mode for swapping windows.

09:19
Travis Cox: So if your strategy for navigation is to swap the main view, it's already there. All that you would do is in the customizer, you would specify the actual window name, the path to the window that you wanna swap to when it's in that particular mode. So that allows... That would force every single tab to basically swap out the main view that you have there. If you're... If you don't wanna do that, if you're looking at ultimately trying to maybe open a pop-up or maybe open a dock or open a... Or maybe swap to a window, you wanna be more in control of how that works. Basically, you can turn off the navigation mode, set that to disabled, where it's not gonna automatically do that behind the scenes. But instead, what you would do is you would handle the event that... Basically that's gonna fire here. So if they go to scripting, the actual selected tab is going to change. And when that selected tab changes, basically on a property change script, you can say, "If the event.property name is equal to selected tab," then from there, we can say, "If the new value is equal to this, we can system.gy.open... Or system.," sorry, "nav.open window," or, "swap window," or any of those functions.

10:44
Travis Cox: So if you wanna go the more scripting route, where you can control exactly what happens in all those, you're more than welcome to. But if you wanna use the built-in, of course, navigation mode for swapping, you could do that as well. So hopefully that answers your question there. Alright. Okay. So here's a question from Jesus, he says, "By... How does Ignition deal... For getting licenses for these remote sites, are the licenses sold separate? If so, what is... What are the options for points?" Okay, so the way the licensing works for Ignition is every single Ignition server will need to have a license for the modules that you want on that particular server. So if I have two remote sites and one central location, that's gonna result in three Ignition licenses that we will purchase.

11:32
Travis Cox: But each of those licenses could have different combinations of modules, it's for basically what functions you need to have at that location. Whether it's Ignition Edge or a standard Ignition, regardless you're gonna have a license for each of those. So that's how that... The licensing works. Pretty simple on that. And the license is fundamentally unlimited, so you're not paying for a tag, for a client, for any of that. If you want to limit the number of clients, our Vision, Perspective modules, we can limit the functionality there. Ignition Edge does automatically have a limitation of one client and has a limitation of two device connections but still unlimited tags. So pretty simple there, we like to keep things very unlimited, very simple as we go forward here. Okay, so I see that we've got quite a few MQTT questions in here as well.

12:24
Travis Cox: This one here is when using MQTT between two Ignition gateways, Transmission on one and Distributor plus Engine on the other, and you're publishing UDTs through Transmission. If the first Ignition gateway is simply being used as a tag gateway and do not have any visualization, what happens with all the alarms configured on the first Ignition gateway? If they are never acknowledged, will that be a potential problem in the future for that first gateway? Okay. So this is definitely a question that a lot of people have with MQTT. We essentially use Ignition for a lot of our legacy devices, proprietary, the polling protocol devices where we have Ignition out there talking to those PLCs locally, bringing that data in, and then we publish it to an MQTT server, right? So it's a decoupled architecture. The MQTT Engine will automatically discover those tags and that is where typically you apply the configuration of history of alarming, you do that on the central gateway, because we have store-and-forward built in, and ultimately that's where your long-term storage may be of your data.

13:28
Travis Cox: So that might be the corporate location, might be in the cloud for that, but that's generally where the configuration is. Now, a lot of people still need that configuration on the local Ignition at first gateway, because they have a local HMI, they have Edge Panel, for example, panel plus IIoT, and they wanna be able to see those alarms locally, see the one week of history, see all that data out there at that site. So, that can certainly happen, we don't send that configuration of the alarm that's on the first gateway through MQTT and have it automatically set on the central gateway, we don't do that. We'd want you to define that alarm configuration separately on that central gateway. We've had a lot of requests around this, but that's how you do it right now.

14:09
Travis Cox: So the question is about acknowledgement. It is very possible that when you acknowledge the alarm on that central gateway, you can publish an MQTT command, that would then be received on that first gateway to the acknowledged local alarm, if you absolutely had to have it be acknowledged in both places. But generally speaking, it's better to kind of think of it as truly decoupled, have the configuration that you need for local, for what you need to have locally, but mainly focus on the configuration for that central gateway there. That was a good question.

14:43
Travis Cox: Okay, so another question here is, what is the best way to set up Ignition HMI that continues to operate even if communication with the server is lost? So we get this question a ton, is with the Ignition client, whether it's Vision or Perspective, those clients rely on having a consistent, reliable connection to the Ignition gateway. And so, if that gateway communication is lost, let's say the gateway server goes down, let's say the network goes down between it, the Vision client or Perspective client will be rendered useless, that it won't be able to do anything until it connects back up to that central... To that Ignition server. So, we have designed Perspective to be able to work in offline mode, but we don't have any offline features yet besides simply navigation.

15:30
Travis Cox: We're looking at doing some forms, offline forms as we go here in the future, and we’re still adding more features as we go in terms of offline mode. Now, generally speaking, what's best is if you have a client out there that has to continue to operate regardless of the connection to the central gateway, typically what we do is we put Ignition on that local client, so we'd have a local... Maybe Ignition Edge Panel or a one-client Vision or Perspective license, so that we could fall back to that local Ignition system. We have a feature of a local client fallback in both Vision and Perspective, where if I lost communication to the central, it'll redirect automatically to that local system and we can keep running, keep going on that local one.

16:14
Travis Cox: But it would mean that I have two separate gateways here that we're managing, right? The local one and the central one. That's a way to guarantee that that will always run, you know, not to rely on the connection back to that main Ignition gateway. So hopefully that answers your question there. Okay, so let me take a look at some of the questions that are coming in. Okay, so here's a good question here. This is always kinda near and dear to my heart. It says, "How do you see the home automation market using Ignition? Can the end user use Maker? Or do they need to purchase Edge?" So, great question from a home automation perspective, we built Maker Edition of Ignition as a free version of Ignition for personal use, a non-commercial. So anybody can use it at home for their home automation system, for whatever they wanna use it for locally.

17:05
Travis Cox: I in fact use Ignition here at my house for all of my home automation, plus managing my bills and so on. I love it, and I'm using the Maker Edition of that. It is completely free for that. We'd only have to purchase a license if we're using it for commercial use, right? So if it is just personal, go ahead and use Maker. And I do anticipate a lot of the... that the home automation enthusiasts, the tinker-ists, you know, those hobbyists, they'll definitely go ahead and do that. And there's probably been a lot of people already. Again, you could just go into your Inductive Automation account and request a license for that automatically.

17:38
Travis Cox: Okay, so there was a question, a follow-up from what I had before. “Speaking of offline forms, is that a plan feature for 8.1 or it will be included in the later 8.X version?” So that's still yet to be decided whether it's gonna be an 8.1 or in a later like, 8.2 release. We haven't committed to that yet, but it is something that we do want to do, there's a lot of requests out there for offline forms. We'd love to see that be a part of the product. Another question here that came in, it was talking about Panel, Ignition Panel. Is it a different type of license? So, we have two different editions of Ignition. We have the Ignition Edge and a standard Ignition. Ignition Edge is... They're both the same code base, the difference is a license. The Ignition Edge is a lightweight, kinda more limited version of that, and so, the license is cheaper, but it's very specific for edge-of-network.

18:30
Travis Cox: So a local HMI, store-and-forward data collection node, those kinda facilities. And typically kinda for a fallback or again, for like a hub and spoke architecture that get data to a centralized system. It's typically what they're used for, and that is again, different from a standard Ignition license that's completely, fully unlimited and you're just looking... Paying for what module you're looking at on that side. Okay, so another question that came in here is on Perspective, and has to do with drawing tools, the 2D Perspective drawing tools. So that is also something that is...

19:06
Travis Cox: That is in the works. Ultimately, it's I don't know the exact timeline and for when that will be in place, but it is a highly requested feature to be able to have drawing tools very similar to Vision, where you can go and manipulate SVGs, and have those path tools of all of that so we wanna have kind of that feature parity between Vision and Perspective. Hopefully it'll be something that we can see again, either in 8.1 or potentially probably 8.2 on there. Again, what I would suggest for anybody who’s looking for the roadmap or for kind of when future things are gonna come in, to attend our ICC conference this year, our ICC X, our Ignition Community Conference. That is where the Director of Software Development and what they're actually gonna talk about that future roadmap and talk about where Ignition's gonna be going. So I highly encourage you guys checking that out to get more detailed information than I have here today.

20:04
Travis Cox: Okay, so all right another question came in, is, “Any plans at OPC UA, pub/sub OPC UA event and alarm and history on both sides, client and server?” So again, another kind of future roadmap, I could tell you that currently we support OPC DA or HDA, Historical Data Access on using Microsoft COM, it's not obviously leveraging UA yet. There is interest in that and there's also a lot of interest in the alarm and events part of that. And so we're currently trying to look at from a priority standpoint, whether we focus on a particular driver, whether we focus on the alarms and event with an OPC UA, so there's more that could be shared on that, don't have details yet, but that is something that's very, very highly requested, and I would encourage anybody, if you guys want the alarm and events or the history on that too, go to the ideas forum and vote those up so that we can get a real good understanding out there of how critical these particular features are for everybody, so yeah, let us know how that is going.

21:07
Travis Cox: Okay, so let's see here. There's another question here that came, is, “Is there a way to use the byte array source method for a PDF file instead of an image?” So yes, but it's not using... What you'd have to do is basically, again, have in Perspective, like I said earlier, you gotta have a URL on the web server that will expose that byte array with the proper MIME type, that's an application, PDF MIME type.

21:37
Travis Cox: So typically WebDev is used for that very, very easy to do, where I can get the bytes of the PDF file and basically return that byte array with that MIME type and I can use it in our PDF viewer component. I can... The browser could just natively show that using the built-in PDF viewer in the browser. So either of those would work. So WebDev is really a very awesome module for that, especially that kind of thing, and with Perspective. So you guys could check that out for custom images that you're putting there, for custom PDFs, those kind of things, it can really, really be handy quite a bit there.

22:14
Travis Cox: Alright, here's a good question. It says, "What is the sweet spot in discovery phase before giving a demo?" And so that is... Demos are an art form. We love giving demos on the Ignition platform, and our goal is to really just show the product off. It's not a sales pitch. It's just to show what Ignition can do and answer people's questions to understand it. So the sweet spot for me is kind of understanding what their customer is looking for, what they're trying to accomplish, what persona are they? Are they an operator, are they a plant manager, are they kind of a CIO and basically catering that experience to them. And so to me, it's just I like to be able to show the ease of which we can install the product, the ease of which we can open the design... Connect the devices and open the design or build out a system and launch that. We take a lot of things for granted, but how simple that process is, but within that, a lot of people don't realize, just, they could do that on their own, they could play around with it in that way. So we always encourage people to go and try it out for themselves as well, just like we do in our live demos there.

23:27
Travis Cox: Okay, good. So that's a good question. Alright, so the question here from Jonah, it says, "If we find something missing or could be improved on the online manuals, is there a process to get more information added?" Absolutely, I would definitely encourage you guys to email. I believe in the documentation there's an email address that you can go to, if not, you can just go to support, email to support, but that gets over to our training team who and the documentation team, who can make sure that we have all the good examples and all the good relevant information on documentation. We try to make sure that it's really up-to-date, really good, especially as new versions are being released, but if there's things that are missing or things that you'd like to see in there, definitely let us know, we'll be happy to address those and to get everything put in place. So a good question there. Okay, another question that came in. It says that, "Can you throw some light on using Ignition as an MQTT broker? And how can we configure topic in Ignition?"

24:35
Travis Cox: Let's talk about that. Certainly, you can use Ignition as an MQTT server, so I'm gonna bring up my Ignition gateway here and go into the configuration section. Kind of anticipated some questions on MQTT today. So there are three modules that we provide for MQTT, there is an MQTT Distributor Module, and this is a in a way, a standard 3.1.1-compliant MQTT server, so we happen to have a module for Ignition, so for the folks that don't have a third-party broker and they don't have anything else and they want to just have it all contained with Ignition managed there, it's perfect. There's a fully compliant MQTT broker with access control lists and user management and all of that, so you can simply just install it just by installing it into Ignition, it is now, I now have an MQTT server that I can work with, and you can run it on the standard non-TLS and of course, TLS ports, we encourage the TLS for having encryption there, but once you have that it's as simple as, if I go to MQTT.fx here, this is just an MQTT client.

25:51
Travis Cox: So if I go into that, basically I can... Let's create to my local host there and yeah, I think that should all be good, so let's just do a connect. So now I'm connected to my local broker just like that, and I could publish and subscribe. Now, in particular, there's a lot of questions. I'm gonna exit this here, a lot of questions around the data that's being published in MQTT.

26:15
Travis Cox: So MQTT itself, you can publish any data on it on any topic, whatever you want. And so that is... It's good and bad. What's good is that the specification doesn't dictate how the data should be formatted. What's bad though is if I have lots of applications and devices, we need to have a known format of that data so that there's automatic discovery, there's interoperability, there's all of that.

26:41
Travis Cox: And that is why MQTT Sparkplug was created. So let's come down here, so Sparkplug is a payload specification, it's an open-standard specification, and it's part of the Eclipse Foundation, and it defines an OT-centric topic namespace, and it defines the payload and the data models and how state management works, and of course, the ability to publish metadata and actual UDTs or models along with that, and store-and-forward of data.

27:14
Travis Cox: So really what we're getting here is kind of the single source of truth of data at the edge of the network that is completely contextualized in a format, in a standard format that can be consumed by any system and have that understanding to know what that data actually is. And so that's the format that we use in Ignition by default. So we have a module called our MQTT Transmission Module, and this module we connect to that broker, so I've got it connected and we basically point the transmitter to a set of tags, and it will publish that data on that particular topic.

27:50
Travis Cox: So if I look here, I actually have some tags and you have... I got a PLC connection with a couple of example tags, and if I go over to my engine, that data was automatically discovered, so there's my group, my edge node, and there's that PLC, and there is those two tags that are being published there. So we like to use Sparkplug as the topic namespace just because it’s simple, but if you wanna publish data on any topic, you certainly can from Ignition, if you also want to subscribe to a non-Sparkplug format, like a JSON format, you could do that as well with an MQTT engine so that's not a problem at all.

28:28
Travis Cox: Now, a follow-up question to that is around basically defining a really nice normalized unified namespace. And again, that's something that Sparkplug really helps out with. So let me go down here to the topic namespace. Sparkplug basically forces this and you have three layers in the topic that you can leverage. It allows for scalable namespace that can uniquely identify all of the actual devices and edge nodes that we have out there. So first is our group ID, and the group ID is a logical grouping of all of the edge-of-network nodes.

29:06
Travis Cox: So possibly you do it by your company or maybe by a physical area, some grouping there, but that's your top level. And then you have the edge node ID, so this identifies in the Ignition Edge or maybe identifies the actual some other node that potentially behind it has one or more devices. And then from there you have devices which identifies a, physically or logically, device that you have out there that's connected to that particular node.

29:36
Travis Cox: So for example, with Ignition Edge, the group ID can be whatever we want, but then our edge node would be that Ignition Edge system, and then I can have 10 PLCs connected to it inside of that, and we'd have... Give each of those PLCs a different name. So within that though, outside this topic, you can have any tag structure you want below that, it's completely up to you. And if we wanna do data modeling, UDTs, all of that, that's all good.

30:00
Travis Cox: But because Sparkplug defines this, it gives us a way to identify these assets properly with all the health and diagnostic metrics that go along with that along with uniquely identifying all of these, and it allows us to scale that up to lots of devices that we wanna have out there. So that's definitely a good question there.

30:27
Travis Cox: Okay. Let's see here. It says, "Do you have any documentation on having a SCADA historian reporting on the OT side and utilizing a data diode to move information to SCADA read-only historian and reporting on the IT side?" So we don't have a lot of documentation about that. I know that in conferences, especially, we've done some security presentations, we talked about data diodes and how important they can be in guaranteeing that data is a one-way street going over that data diode.

31:00
Travis Cox: Now, I have worked with various data diode companies, and we have successfully been able to get MQTT and OPC UA data through data diodes. So that's really one way that that data can come through and you can have Ignition on the other side. What they've done is they have services that allow that data to go through that kinda mimic these things on both sides to make sure it works.

31:22
Travis Cox: It's not gonna, out of the box be supported by Ignition, you'd have to use the services that these data diode companies that they have. And so the few that I've dealt with have services for OPC UA and MQTT, and I would suggest looking at those, or you could write your own potentially, but we would like to try to support those better as we go forward, but as of right now, there are ways that you can leverage that.

31:47
Travis Cox: Okay. So another quick question here is, “Any considerations on how to configure Ignition when using different antivirus softwares such as Norton, AVG, ESET, Trend Micro, any of that?” So definitely, I would encourage you guys to take a look at... I'm gonna go to our support portal.

32:12
Travis Cox: Okay and look for “antivirus.” And there's a lot of good tech notes that the support teams have put out there. So here's a common antivirus exclusions. As a rule of thumb, most of the antivirus softwares we have no problems with, it works perfectly fine on there. But this does at least talk about if there were issues, things that we could exclude, the directories we could exclude on there. So this is basically you can refer to this, but typically, there's not really any considerations you have to worry about with these things. Unless they have really strong locking, they lock files and then our system can't access them, that's where we have to do the exclusions. But for the most part, most of these systems don't do that these days, they just look through them and they're typically fine. So you just have to make sure that the ports and things that are needed for Ignition, of course, are that we are mindful of those. But anyways, this document can talk a little bit more about that, so I suggest taking a look at that. There's some good ones that are in support, you can just go there and search like I just did, and you'll see the different ones that are there. Okay.

33:20
Travis Cox: Another good question here is, “Is there a way to take a picture with the tablet and have Ignition save it to the database? What format is the best way to save it in the database? What is the best way to view it, to view that picture and report in Ignition?” Alright, so another great question. Kind of similar, a little bit in line with the displaying part of that image, we talked about that with Perspective earlier. But in terms of taking the picture, the best way to do that, and I assume we're talking about Perspective here 'cause you said tablet. So we have native apps for iOS and Android for Perspective, and on the native app, there is the ability to basically take that picture and you could scan a barcode, you could take a picture, and that would come in, we'd handle that through the event and basically get that byte array there and we'd store that to the database. In fact, you could just use the, I think the upload component, upload file component, and it has that interaction with it. But anyways, you can get that image uploaded through the native app. We don't have one directly in just a normal browser where you can get actually the camera and take a picture from the camera. It has to be on the native apps, so iOS or Android. You do that, and then basically get that byte array and we store that as a blob in the database.

34:40
Travis Cox: So in MySQL, for example, you'd have the long blob data type. In the Microsoft SQL Server, you would use a VARBINARY(max) as your data type. Store it as a byte array there. And then to get it back out, if you're getting in Perspective like we talked about, WebDev is a great resource for that, we could just get that byte array, convert it to a B64 string. Another great opportunity for that. If it's in a PDF report in the Reporting Module for Ignition, that already has support for an image component where you can actually bind the source image to a key, which can be the byte array and it will show that dynamically on the report. So it is possible there. If you run into any issues with that, certainly you can talk to our sales engineering team, we can walk you through how that would work. And any of these questions, if you guys have follow-ups. Do you wanna go deeper and certainly don't hesitate to ask us.

35:33
Travis Cox: Okay. So another question. Your kinda general question is, “Are there any plans to have local IA community meet-ups?” So that's a good one. Mainly right now, our main event is our Ignition Community Conference. So that's the time where we bring the community together and we can talk about things that we're doing and things and just general trends in the industry. It's a great way to have those meet-ups and we try to also get groups like different verticals and all of that where they can have space to talk to each other and cross-pollinate within that event. So it's one way that we do that. We also do discovery days, Ignition Discovery Days in various locations where we can invite partners and customers to come and learn more. It's another great way to meet up. Outside of that, we don't have any other specific types of meet-ups. We have these (Ignition) Community Lives, we have different things that we do, but it would be nice to have more community meet-ups, that's what we could do and organizing those. I do know that there are some organizations like there's a Oil and Gas Collective and there's just a Cross-Industry Collective for Ignition that have kind of come up and they have meetings and meet-ups that happen on those.

36:38
Travis Cox: So you may wanna check out a couple of those ones, but we try to have a lot of engaging time where the community can come together. So if you have ideas there, shoot it our way, for sure. Okay. So some customer asked for a database encryption for food and beverage, and do you have any suggestion about that or previous experience on encrypted databases? So I don't have a whole lot of experience with that. I do know that it's possible to have that data be encrypted and not only the connection to the database, but the data itself being encrypted, and so I would definitely work with your database, MySQL, Microsoft SQL Postgres for how to do that. Ultimately, it should be fairly transparent to Ignition in terms of how we are running those queries, the insert selects, deletes, updates that should be fairly transparent 'cause of course, with the connect to the JVC driver, we will be connecting to that database and it should know what to do there. So again, I haven't specifically done it myself, but it shouldn't be too difficult to get set up. I do know that people have done it. There's been some database experts that for various customers that have set these things up. So I wish I had more details for you on that one. That was a good question.

37:55
Travis Cox: Okay. So question here. It says, “Any plans to offer a subscription license instead of a perpetual license? What major obstacles does IA need to overcome in order to provide this option?” So yeah, it's a great question, one that lots of customers have asked for. Currently our licensing model is perpetual. Perpetual license, you buy it upfront... You own that indefinitely. For subscription licenses… We don't currently have really any specific plans. We do know that a lot of customers are asking for, for those. And we're looking into things like being able to go to AWS and to Azure in terms of marketplaces, but again, nothing concrete. So there should be, hopefully we can have at the conference, you know, like a good question to ask some of the teams there and see what they have to say in terms of the roadmap as well. Alright. So this is a good question, one that has, comes up a lot in terms of Digital Transformation discussions. It says, "Can you explain digital mirrors to me?" And so it's something that we say a lot, digital mirrors, there's obviously a lot of discussion around digital twins today. A lot of companies are trying to figure it out, and there's a lot of products out there that are helping, assisting with digital twins. We tend to think that digital mirrors are the first step towards the full digital twins, right? Digital twin is basically, a complete twin of your process, both in terms of the data and the models, but also just how it functions that you can run things through it and see how it would actually, in a simulation environment and see how it actually respond and help you try things out. And so there's... It's amazing what can be done.

39:36
Travis Cox: But digital mirrors are something that is really the ability to mirror the industrial process in regards to data and data models, and with all that context. So we were talking about Sparkplug before and being able to define those, the data with context, very, very similar. What we have to do is basically get all of our data into standardized formats, store it against that context against those models, those assets. And then when we do that, we can leverage things like AI and ML. We can go a lot further with that data. But the step one is basically making sure we get access to all of our data and putting it into a conducive format. MQTT Sparkplug can be one really great way to do that. People are leveraging it, especially getting data to cloud like AWS and Azure. There's services that are in the cloud, like AWS IoT SiteWise and Azure Digital Twin that we're working towards have direct integrations with those, so that that data can be stored there long-term against that context so that customers can go further and ultimately get to things like digital twins. So good question. That's sort of how we see digital mirrors, but that, again, that's not the only way to look at it, it's just the way we've been kind of talking about it.

40:48
Travis Cox: And then in terms of AI, what is the role of that in recent Digital Transformation? So I think that's a good question. Often when we look at Industry 4.0 and Digital Transformation, we really, there's a lot of focus on digital twin, AI/ML that is kinda the holy grail, right? To get to, to be able to leverage that, there are a lot of steps we have to do ahead of time to get to that place. But AI does have a critical role in Digital Transformation. They're really linked together. Without AI digitization of products and processes would basically produce so much data that no human could ever be expected to analyze that data in an expected timeframe or acceptable timeframe. So AI can really help organizations analyze that data, learn off that data and identify patterns. So a lot of people are doing things like prescriptive analytics, kind of trying to get to that where they can see multiple options and potential outcomes, as more data comes in, those prescriptive analytics can alter its predictions and suggestions accordingly. So we could do things like inventory management or predicting machine failures or eventually tuning processes, kind of that closed loop control that's there. So AI is really a way to do that and it's gonna get easier and easier as we go along, as there's more tools, more things available. And, but what's fundamentally important though, is that we standardize and understand our data to get it that way. At least we talk a lot about that.

42:20
Travis Cox: Okay. It says, "What versions of SQL does Ignition support updating SQL Servers? Our DBS is on SQL 2019, just wanna make sure." Really all the versions of SQL Server, well, any, MySQL, Microsoft SQL Server, Postgres, we support the majority of them, especially the new ones that are coming out. I mean, basically those companies are providing the JDBC drivers, the Java Database Connectivity drivers. So you may have to update or upgrade your driver in Ignition for the new version, but it shouldn't be a problem. And we have people using the latest and greatest today. So it definitely will do that. We try to update our website to kind of show those versions as they come out, but likely, like I said, we haven't had any issues with new versions, we can just simply use them. We may have to update the driver, but that's about it. So we've had very, very good success with that within Ignition over the years. Okay. Another question that came in here is, "What techniques have you seen or do you recommend using for allowing a gateway on an isolated network to communicate data securely across a public network, i.e., the Internet?" So, great question.

43:28
Travis Cox: So I'm gonna, I wanna answer that in a couple different ways. I first wanna talk about before we can look at the Internet for a second, which clearly we wanna do things in a very secure way, but if we look at just what's on premise. There's a lot of networks today that are segmented networks. So we have a layer 3 or an OT layer. We've got the DMZ layer and we have like a layer 4, the business side. And a lot of times we have those segmentations too; the more statements we have, the more secure that system can be. It limits connections and ports that are being open, all that good stuff, right? No direct access from business to OT or OT to business kinda goes to that middle layer. So that's one way that people have done a lot of mitigation to securely send data across, of course, having encrypted connections, outbound connections only, that kind of stuff. Now, when we look at going to the cloud, security is extremely paramount as we do that. And we, there's two methods that we leverage in Ignition to securely get data to a public network, to the cloud in particular. So one is MQTT. So MQTT is a, it could be a TLS-encrypted connection. It's an outbound connection. So your Ignition system on your local network would connect outwardly to your cloud server or to that broker.

44:44
Travis Cox: And there's... No ports have to be open on the firewall internally, so that allows it to securely send it up, and we can also make it so that data is read-only, it cannot... There's no way for that data to... For you to write back down. That's perfectly fine if you could definitely do that, but that connection being outbound like that and TLS, we have a lot of customers leveraging MQTT, especially getting data to the cloud.

45:06
Travis Cox: Another option that we have is our gateway network. The gateway network is an Ignition-to-Ignition communication network. So we can connect, again, an outbound connection from our local Ignition to our cloud or central Ignition, and it's a secure connection, has certificates to make sure that there's approvals on both sides, and ultimately, we can send data through there. Again, we can have security permissions locally, where we can guarantee things don't get written to.

45:31
Travis Cox: So those are typically the way that we see it. Generally speaking, MQTT wins because it's very low bandwidth, it's very efficient, it allows us to get all the data, and then we can fully leverage all that information in the cloud, but they're very similar approaches on how we can do that. So those are typically the techniques for being able to have the data being sent securely there. So hopefully, that answered your question.

45:56
Travis Cox: Okay, so another question that came in, it's a little bit longer kind of setup on here, but it says, "I'm a PhD student in Sustainable Energy Engineering and Management, about to conduct research on the integration of the three Ds: decarbonization, decentralization, digitization, in the energy chain value and assess the operational and environmental challenges out... Constraints in sub-Saharan Africa. Is there in the fourth revolution, which is Industry 4.0: open, no data storage, analysis and load forecasting are the key aspects that will need special attention. They like to know, how can we have secure and reliable data systems to effectively meet the above-mentioned objectives?" So this is something that definitely comes up a lot and something that we have talked about in education in terms of, if you will look at... Looking at data ops, right? In Ignition are great data ops tools, allows us to get data to where it needs to go. The Ignition itself has tools to bring in data from all different disparate systems, whether it's PLCs or OPC UA, whether it's REST APIs, databases, whatever, we can bring that information in, we can model that data. So it's really important that we provide context to that data at the Edge, that single source of truth of that data, publishing it in a standard open format that then can be accessed by different systems.

47:22
Travis Cox: I think that's really important, to have a secure way to do that and have an efficient way. Again, single source of truth with that context. It's standardizing our data on our data models, said a few times here today, but that's really what's needed in order for that to happen.

47:41
Travis Cox: Okay, so there were some questions in here about leveraging... This is a little bit more advanced topic, but leveraging Git or source control with Ignition 8 and the projects that are in the file system on there, and sort of what's the best way to track specific changes in a project and commit those to Git. So we did put out an Ignition 8 Deployment Best Practices Guide, and in that guide, we talked kind of in general about how you can develop a process for doing source control and having a development environment moving from development to production, all that good stuff. And in there, we have an example. We show a post commit hook where we save... We can actually tell... We can actually publish. When the, say it happens in the designer, we can publish those changes directly to the repository. And that works well, but it's not something a lot of customers do in practice, because a lot of people have a shared development environment, single development environment, and ultimately, it should be more controlled about what we push to our repository and who's actually doing that.

48:52
Travis Cox: What I always suggest, actually, if you had to share a development environment is to have projects for each... Each developer has their own project, they're making changes in there, they can push to their own branch within the repository, and then you could have PRs and merge that in with the main development branch, and then later, we can bring that into production and so on. I tend to think of doing that then trying to have be more automatic within Ignition. Even best if each engineer or developer has their own environment on their own laptop or something like that, just makes things a lot simpler. I know it's more work to do, but it's a great way to leverage that full source control, and that's only for the projects. I can tell you that we definitely... For all the rest, Ignition gateway configuration tags and all of that, we have plans to move it all into file systems as we go in the future, so everything could be tracked in the source control, but for now, projects... And you should export tags to a file so that you can store that in there as well, and you can track those tag changes. But you gotta basically establish a process that works for you guys, because we don't disperse control in Ignition anymore, so you gotta find a way that's gonna work and how you go from a development environment to a production environment. So it may not answer that particular question, but hopefully gives a little bit more context.

50:09
Travis Cox: Okay, so another question here came in, says, "I'd like to know how I can get the information of an array in an object, please. We usually work with RFID and IO-Link by OPC UA, I can get all information, but when I want to use all of a string of 32 bytes, 32 characters, and only one object, I do not know how to solve that." So, okay, that probably one way to look at a little more specifically with you, certainly Ignition does have array support within our tag system. For all the different data types, we can have arrays. It's just a matter of how we're interfacing with that with OPC, so with bringing a byte string, we probably could convert that to an array if we needed to, but I'd suggest talking to... Get in a call and talk to a sales engineer so we can see more specifically about the problems you're running into, but we do have array support within Ignition.

51:01
Travis Cox: Okay, this is a great question, is, "How common is it for users to run Ignition within Docker and what kind of pitfalls should you watch out for?" So great question here. Our Docker image has come a long way, our official Docker container or Docker image, and with it, it's production ready, you can leverage it. A lot more customers are really trying to figure out how they're gonna leverage Docker in their environment, a lot of it's for especially Edge and orchestration and kinda get Edge out there. But ultimately it's becoming more commonplace, like I said, from a development standpoint, it's a no-brainer to use it for developing, 'cause it helps you spin up all these different environments really easily, but from a production setting, we're starting to see more customers go down that path.

51:42
Travis Cox: Now one thing that's required for that to work is leveraging our eight-character license key. This is something that... It is what we use with Maker, that is a lease space license, so it continuously hits the Internet to renew the lease on the license, and that's needed because you can't... Our six-character key that we have, it gets locked down to machine, you can't reliably use that because the Docker container can be moved around, it can have different IDs and that you can lose that license. So retaining the license is important for the eight-character license key. That's the main pitfall to look out for within it. Outside of that, we just have to mount the data directory, we have all of our persistent storage inside that data directory, and of course we're doing a lot more as we go forward to be able to spin up a Docker container with any kind of configuration in there that you'd like, but it is definitely becoming more commonplace for sure.

52:35
Travis Cox: Okay, let's see. We didn't get to get to all the questions that are in there, I'm gonna kinda jump forward a little bit, and I appreciate all of the questions that everybody has sent in. I wish I could've gotten to all of them, they were great questions. Hopefully this... Today. But if you still have questions that you'd like to ask our team or other members of the community, you can certainly go to the forum, so forum.inductiveautomation.com. You can ask our teams as well as of course, the Ignition community at large. You can also contact our sales engineering team and basically get a one-on-one call with our team where we can answer your questions directly and help show you various things, love to do that, so that's on the table for everybody here, just contact your salesperson. And as I said earlier, we've got a lot of questions here today about the Ignition roadmap and kinda the future of Ignition. And if you wanna get insights into that, into where Ignition development is going, and a whole lot more, I highly recommend that you attend our 10th annual Ignition Community Conference.

53:39
Travis Cox: The developers of Ignition will be presenting a technical keynote in several sessions at ICC. We have great sessions that I know our sales engineering team is gonna be providing, especially on things like leveraging deployment strategies and Git, and as well as ML, the machine learning session, so definitely check it out. We've got a lot of great content and we have an amazing Build-a-Thon competition that's gonna, happening this year, great workshops and networking and a lot more. So this year, there's two ways you can attend, there's in-person events, on September 20th to 21st in Folsom, California, and there's a free virtual event on October third through fifth, so don't miss it, register now to experience and explore everything that ICC X has to offer. Really, really excited, and it's our 10th one, so it's gonna be nice, it's gonna be awesome, and it's great to be back in person again. So thanks for being here.

54:32
Travis Cox: I have enjoyed answering all of your questions. To stay connected with our latest news and events, please follow us on social media and subscribe to our weekly News Feed and our podcast at inductiveautomation.com. So bye for now and have a great day. Let's see you guys next time.

Posted on July 5, 2022