Inductive Automation Blog

Lauren and Shay sit down with the Co-Inventor of MQTT, and CTO of Cirrus Link Solutions, Arlen Nipper to discuss selling MQTT. Arlen talks about how the addition of MQTT modules creates a more efficient SCADA system and how that solves current system issues and creates an infrastructure ready for digital transformation. Arlen discusses the partnership between Inductive Automation and Cirrus Link Solutions, the MQTT modules, the key selling points, the Sparkplug specification, and the guiding principles of utilizing Ignition and MQTT. And we get to see Arlen do a demo!

Lauren and Shay are talking with Training Content Manager Paul Scott about how to identify the correct modules for specific customer needs and leveraging those modules for successful projects. Paul covers the correct time during a sales process to bring up these modules to educate a customer, not overwhelm them. Paul covers the level of knowledge you should have on the modules, what to understand about the customer’s project, and ultimately determining the best module by breaking up the solutions into categories: device connectivity, data logging, visualization, reporting, alarming, and enterprise solutions. Paul gives some examples of what modules might be the best solutions under certain circumstances.

Video Transcription:

00:08
Lauren: Welcome back to our Sales and Marketing Training Videos. I'm Lauren.

00:12
Shay: And I'm Shay. Today, we're talking about identifying the required modules for customer projects.

00:16
Lauren: We're sitting down with Paul Scott to talk about how to leverage the Ignition modules for success. Paul, thanks for being here.

00:23
Paul: Thanks for having me.

00:25
Lauren: So today we're talking about identifying the best modules for your customers and projects. When do you really start talking about that in the sales call process or in the sales process in general? 

00:37
Paul: So it's kind of tricky because you don't wanna lead with it. So if you've been following along with this video series, you know that understanding the solution, understanding the end goal, understanding the customer's needs is really the most important part. When you start talking about the modules, they're just naturally more complex, and they start leading towards a very technical area, where each module does what. So I generally find it's not too helpful to lead with them. I mean, you don't have to hide that modules exist. Ignition's the platform, and that's fine, but really maybe a little bit later down in the process, after you've already kind of figured out what the solution should be, or what your potential options are. Another way to think about it is that the modules are really the tools you're gonna use to build a solution, and you don't really need to get too focused on what the tools are initially. And it's something you really kind of examine later once you understand what the problem is. So really to answer your question, I guess, you can lead a little, but I would definitely maybe kinda push it back towards ... maybe the middle or towards the end of that whole discussion or the series of discussions.

01:39
Shay: Definitely. So it sounds like you kind of get a sense of discovery, figure out what problem they're trying to solve, and then once we kind of have an understanding of how Ignition works, then we can look at ‘How do we actually solve that? What tools are we going to use to do that?’ So with that, how do we avoid that complexity in the initial conversation or conversations with customers? 

02:00
Paul: Again, try to focus on the solutions or the big picture that you're here kinda heading towards. And again, you really need to understand what the modules do before you can really identify them. So you're gonna need to have at least some solid understanding of at least how they work, you're gonna wanna be familiar enough. Those details about how they work and stuff don't necessarily have to come up in the initial talks, but you really wanna have them in the back of your head, just to be able to piece this whole project, or what that whole project or series of projects will ultimately end up becoming.

02:31
Lauren: So once we've had those initial conversations, how do you determine the best module for someone's needs? Are you looking to solve a specific problem? How do you consider that? 

02:40
Paul: Sure, so yeah, it's definitely best to maybe abstract away the individual modules and kinda focus more on general categories of solutions. Common ones would be device connectivity, data logging, visualization, reporting, alarming, and then enterprise solutions.

02:57
Lauren: Quite a few. Well, why don't we start with device connectivity? 

03:00
Paul: Sure. Now, fortunately this one is relatively simple. You need to understand basically: What hardware does the customer have? What are they trying to connect to? Also, what do they have currently? A lot of the times, either we're replacing a system, or they're just adding on to an existing system, so they might wanna try to keep all their hardware in a particular family of devices or vendors. So first of all, do they have an OPC server or some sort of MQTT solution already that exists? So if they already have those, and they wanna keep those, we can connect to those easily, and you don't really need any modules except for the MQTT side, you might need some. If you're going to be using our OPC server, then you'll need our drivers, right? So it kind of depends at that point. You may need to look at incorporating our OPC-UA module as well as our device drivers, or maybe you can skip them entirely and just use what's already there. It really kind of depends what the customer's comfortable with using. So you don't necessarily have to throw away everything they have, they might wanna keep it around.

04:03
Shay: For example, if someone has some Allen-Bradley devices that they're wanting to connect up to, they can use our OPC server and then our Allen-Bradley driver suite. And then they're not gonna need any third-party driver or anything like that. Whereas if they were using something like Kepware, then maybe they would wanna take advantage of a third-party drivers suite with other devices.

04:21
Paul: Correct, yeah.

04:23
Shay: So we've connected up to our devices with our drivers, and now we wanna log the data. What options do we have for that? 

04:29
Paul: So for data logging, you really do have two main options here, and this is definitely where it gets a bit trickier. So we'll talk about both options, so the Tag Historian Module, this is basically the ‘set it and forget it’ sort of solution. The whole module is really designed to kind of take care of the whole database maintenance aspect of it, which is fantastic, because you can just install the module, you can go to your tags, you can turn on history, and then you can just start trending. And that's really it. You don't really have to do a lot of other things. You can start building, you can start putting charts down on screens, and you're good to go, and really, indefinitely. And again, it'll manage all the tables in the database for you. It's fantastic if you're doing any sort of time-based or time series charting solutions. It also does a lot with the actual charting approach, so the actual retrieval of the data in addition to sort of handling the retrieval portion itself. It does a lot of interpolation of the data.

05:26
Paul: So, if you technically have like millions of records, and you're trying to like push those out to a chart on something, client or something like that elsewhere, you don't have to worry about performance because we're go ahead and we're basically giving you accurate representations of what those datas are without the millions of data points. It does a lot for you so you don't have to. It is definitely the most, again, simplistic approach. Conversely, it's not a very friendly format if you wanna try to modify or make changes later. So what I mean by that is, is that whole module will try to manage the database tables itself. It has very specific expectations on what it wants, and if you're looking to modify those, you can, but then you go in this territory of what I tell most folks that you really need to understand what those tables do, and that's not something we really expect most folks to know. You can learn it's there, you can see what they're doing, but it kinda goes above and beyond what most folks probably want to do at that point. So it's definitely the easier solution and it's great for trending.

06:26
Paul: So to kind of transition, and then talk about SQL Bridge. So this is a little bit more complicated to set up, but when I say complicated, I mean it's in between getting out of the bed in the morning and going to the grocery store to shop. It's not like super complicated, there's just a couple of extra steps you need to do, it's a little more transparent. The transaction groups you create from this module, they can record based on intervals of time, just like the Tag History system can do, but it doesn't do a whole lot of magic in the database. It doesn't have a bunch of tables, it's putting stuff up, it keeps everything centralized in one. It's also nice because it's actually living as a project resource. A lot of folks kinda like that, they like to have a dedicated history and data collection project, which the Tag History system kinda just does silently in the background. So there's something nice about having that kind of visual element, you can kinda monitor and do things with. But where these really shine, these transaction groups, is event-based logging, so Tag History is doing this time-based recording every number of seconds or whatever, generally speaking.

07:31
Paul: But transaction groups can go into event-based logging, so if you have some bit you're monitoring, and every time that goes high, and it goes at high at odd intervals or under certain cases, the transaction groups can natively record that. The Tag Historian system, if you wanted to do that, you need a script. Which is a little bit trickier to do, obviously. So it's kind of nice because it takes care of all that, it has a built-in interface. It's a lot more elegant with the whole representation of what's going on with a recording system, and then you can kinda customize it too. This is also ideal if you did want to have some database interactions. So you're not just like recording stuff. The idea with the transaction groups is, yeah, you can record stuff with them, but then you can also very easily pull them back under, those records, back under certain conditions, and so on. That was a lot. So, how do we boil this down to some key points? Just to kind of like help solidify this.

08:28
Paul: So if you're talking to the customer, and you're talking about these data logging solutions here, if you hear things like "time series," or "trending," "ad hoc charting," Tag Historian is much easier to use, it's definitely more the ideal module to use in those cases. You can use SQL Bridge for it, but there's a lot of extra work you gotta put in, so that's why I prefer that in that case. For SQL Bridge things you wanna listen for, "event-based," "triggers," anything that kind of invokes an idea of a particular action or event occurring, not necessarily on a set schedule, but then you're gonna wanna do something. So if you're recording for particular events, I wouldn't say alarms because that goes into another topic. Also, what's great about the transaction groups, there's a lot of folks that like to create their own like recipe management system for a lot of things. Transaction groups are really easy to do that. That's actually really common use for a lot of our customers.

09:22
Shay: We actually do have two posts on our blog about 12 different ways to use this SQL Bridge Module. So if people wanna check out even more ways they can leverage it, they can look there as well.

09:31
Paul: Absolutely.

09:32
Shay: Yeah. And then moving on, we've got our data, we're logging it, we might wanna build some screens next, what do we have in terms of visualization? 

09:40
Paul: So you really have two main options, again. So you have Vision and you have Perspective. Vision has all of these kind of common HMI aspects and features and functionality that you would expect to have. And any sort of visualization product Perspective. It's the newer one. It's got a lot of the same toys. It's definitely a more modern approach, it's using a lot more modern tech, even just looking at it, it's more of a sleeker, web-based kinda look and presentation. And it's a fantastic solution for trying to build any sort of project that requires any sort of responsive design. So you're gonna be looking out on a big screen, you're gonna be looking on your phone or smaller screen, something like that. We also have dedicated apps for Perspective, which a lot of folks have always been kind of clamoring for. Let's talk about the keywords real quick. Because again, there's definitely a lot of overlap. When talking, if you hear things like "desktop" or "HMI," maybe "Vision."

10:38 Paul: HMI's a little vague because, technically, that could still be a Perspective application. A big part of that, is whether or not, at this point in time, if the customer's interested in, or at least okay with having a browser on these workstations. 'Cause right now, the main way on a desktop to view a Perspective session is in the browser. And then of course if you're trying to view something on your phone, on a tablet, something, maybe a little smaller device, Perspective is fantastic. I mean it was really built for that whole solution. Now, something that a lot of folks maybe won't realize right away, is that you can't have both, you really can't. So it's possible to create that sort of desktop solution in Vision, but aside from Vision, you're creating tags, you're creating alarms, you're creating a lot of these other resources in the project that aren't really owned by Vision. Perspective can also use those. So, when you're building for one, technically you already have a good foundation to kinda add something into Perspective.

11:34
Shay: Definitely. And one really awesome feature with Ignition is the ability to do on-screen reporting. And with on-screen reporting, we can be using our awesome charting features, taking advantage of the modules that we spoke about for logging data and history. But what are their options if they would like a PDF report, or something that they're emailing out to someone? 

11:56
Paul: So it's funny, you hit a really kind of funny aspect of reporting. 'Cause the term reporting is incredibly overloaded. Lots of things are a report, right? So yeah, even something you made with one of our visualization modules, that could be a report. That could be a real-time report or however you wanna call it. So, yeah, the Reporting Module as you kinda said, it's really ideal if you need to make a document. If your end goal is, "I need a PDF," or something like that, "I need an email," "I need something that doesn't necessarily live in one of your visualization applications," it's something that could be sent out or saved elsewhere entirely. It also has some built-in scheduling capability. Which is great because if you're trying to shoe-horn that functionality into the visualization modules, that gets tricky, you're doing a lot of scripting, it's not always gonna be ideal. Whereas the Reporting has this really nice interface, and it's super simple to kinda get started with. So yeah, definitely again, key terms, things to look for, to kinda decide if you should be using a Reporting Module here, "schedule," "printing," "print the report," "write," something like that, or we're creating a document, PDF, like I said, "email," stuff like that. But if you wanna listen to those terms, that gives you a good idea of maybe Reporting is useful to you.

13:20
Lauren: Awesome. And then moving on to alarming, what do we have to offer?

13:24
Paul: Sure. Now, this one trips up a lot of folks. You gotta remember, alarming is part of the core platform that is Ignition. So if you just wanna alarm some things, you don't need to talk modules. If you're trying to record events that happen to your alarms, we have the alarm journal which is also part of the platform. None of that requires any module at that point. So when we start thinking about modules and identifying modules, we're starting to also discuss alarms notification. That you wanna focus on the Notification. Our alarming solutions modules are all designed to send out some message or something, some signal outside of the products that people can respond to it. So the main modules in this case would be ... they're a little bit easier because they're all based off of different delivery mechanisms. So you can send emails, we can actually call someone, so we can have a robot to do a little text-to-speech thing, tell someone what's going on and actually call them, we can send text messages with the SMS module, and then we have the Twilio module which also sends texts, but with the Twilio service here.

14:31
Paul: So big thing to keep in mind when you're talking to customers about these modules, these also require some sort of delivery mechanism, some hardware like a modem, or an SMTP server, or we need to sign up with Twilio or something, depending on which one of those you're using. So, key terms for these, "alarms," yeah, maybe. Really, again, if you just want something on screen, that's the visualization option. You already have the alarms available, and we have components. So "notifications," you wanna listen for notifications. Oh, maybe we should consider some of these modules. "Acknowledgements," "remote acknowledgements," if someone's trying to do mobile acknowledgement, or "alarm checking," or something like that. Then maybe the Alarm Notification Module would be appropriate.

15:19
Shay: So we've gotten to work with a lot of really large customers, and to help out with these big, really big installations, we have what's called the Enterprise Administration Module. Can you speak a little bit about its capabilities and when we should be offering that to customers? 

15:34
Paul: Yeah, so you have multiple Ignition installations. Maybe some of them have similar resources and that's intentional. You have some sort of maybe corporate standard, or your customer has some corporate standard of screens and visualization options that they want, and you're trying to make sure all of those different installations have them. That can be kind of a nightmare. If you're trying to make sure everything's up-to-date, that's a lot of work that you have to put into it. So the Enterprise Administration Module, we just call it EAM. So EAM helps you by getting the gateways to do some of the work for you. So the general idea behind this is that, when you're using EAM, there are two types of gateways. There's a controller, and there's only ever one, and then there's any number of agents. So the controller can basically ask agents to run tasks to do very specific things, which then the agents will do.

16:26
Paul: You can set these on a schedule, you can do it on demand, and those tasks help you in a lot of different cases. You can run upgrades, you can apply licenses, you can share those resources, I was talking about there. You can collect backups, you can even restore an agent. So if you had some hardware failure on a server somewhere, well, the controller keeps a copy of all the configuration items, so once you get a new server in place, you just tell the controller, "Hey, new agent's over here." And you basically go, and activating your backup and running again.

16:54
Lauren: So was that module required if I have multiple gateways within my installation or set up? 

17:00
Shay: Well, no, actually. So it's helpful for these maintenance tasks. It's definitely useful there. And when you start using it really depends on how comfortable you are with how many gateways you have at that point in time. You could start using it when you have just two, but maybe two is pretty manageable. So it might make sense for you to maybe look at this a little bit later, maybe five, maybe 10. It depends on how active you're developing on this, how many people are working on it, is it a good communication between folks? 'Cause at some point, you might have some breaking point, where it makes sense to have this module or multiple instances on each gateway. Now, it's important to know that you don't necessarily need this if you're doing any sort of data connectivity or sharing between these different gateways. We have remote tag providers part of the platform. So you don't necessarily need EAM to share data like that. There's a little bit of myth about that that folks run into, and you don't need it. Again, those maintenance tasks, that's what EAM is for.

18:04
Lauren: So when talking to customers, what are the key terms they should look for? 

18:07
Paul: So, yeah, key terms, "enterprise," usually comes up a lot when we start heading in the direction of needing or being interested in this module. "Multiple installations," "managing installs," "maintenance," "change of management," actually. If you're interested in having a development server, and then you wanna take the changes on the development server, and then push them over to production, this is also another kind of key term or key scenario you wanna be aware of.

18:34
Shay: And you can do that manually. So you don't necessarily require this module to be moving things from a dev server to a production server? 

18:41
Paul: Correct. Yeah, you don't need it, but it does help a lot when you get to the point where when that whole dev server, production server ... When you start having a whole bunch of dev servers, it's nice. But yeah, you definitely don't need it. You can still do that manually.

18:55
Lauren: But when we're having a discussion with a customer, how do we explain how these modules plug into the platform and how they actually work? 

19:02
Paul: Sure. So fortunately, that's a really easy topic to discuss. The key or the core modules that most folks are actually interested in, come with the installation of Ignition. So there's not really any extra work you need. In the few rare cases where there are modules that you do need to add in, it's very easy to just add them onto any existing installations. You don't have to restart your entire gateway, or server, or anything like that. They're easy to plug in and start using, and they all work on a trial, as I'm sure we're all familiar with at this point here. So it's really easy to get a new module, start playing around with it, even without a license or anything with it. Put together a proof of concept showing what it does and how that particular module's functionality or core feature set can help us reach the goal of the solution we're trying to reach.

19:50
Lauren: So with this, at what point do we start talking about expansion beyond the modules that they initially requested or were looking for for a part of their first solution that they built with Ignition? 

20:00
Paul: So really, it's an ongoing process. As you're talking to your customer, you've better understanding what solutions may work for them, you may find out that different modules may actually be appropriate even if you didn't hear the key terms. So again, that's just continuing to discover and talk to the customer, and understand what it is they're actually trying to do.

20:21
Lauren: So Paul, we went through a lot of different topics today, and I know our integrators and viewers will want to continue their education on this topic. Do we have any resources available? 

20:31
Shay: Absolutely. Paired with this video, you'll find a document containing all the terms you can use as a cheat sheet in your conversations with customers.

20:39
Lauren: Awesome.

20:40
Shay: Well, Paul, thanks so much for sitting down with us today. It was great getting to learn so much about the offerings that we have, and when we should be presenting them to customers.

20:48
Paul: My pleasure. It was great to be here.

Lauren and Shay welcome Sales Engineering Manager Kent Melville to show us the power of installing Ignition live to a customer during a sales presentation. Kent shares why doing a live install is so valuable, who we do them for, when it’s appropriate, and how long it should typically take. Kent demos database and device connections in the Ignition Gateway while providing best practices for overcoming problems during the install, important points to bring up during the demo, and launching the Ignition Designer.