Architecting Success With Scalable System Design
55 min video / 45 minute read Download PDFSpeakers
Brad Fischer
Sales Engineer III
Inductive Automation
Thomas Goetz
Sales Engineer II
Inductive Automation
Chase Dorsey
Sales Engineer I
Inductive Automation
Every organization’s system evolves in different ways, so flexible architectures are paramount to future growth. Ignition enables you to create an unlimited amount of runtime clients on almost any device with an Ignition gateway on-premise, in the cloud, or a hybrid of both. In this webinar, we will talk about how Ignition helps you build and scale nearly any type of architecture with ease.
You will also learn about common Ignition architectures, how to customize architectures, and the Ignition Architecture Builder, a powerful resource with tools that help you create, share, and track your architectures in a single project. Additionally, we will discuss Ignition's capabilities beyond traditional SCADA architectures, showcasing its ability to accommodate unique applications with third-party modules, database services, and more.
- Discover common Ignition architectures
- Learn how to use the Ignition Architecture Builder
- See examples of how to customize Ignition architectures
- Get expert answers to your questions
Transcript:
00:00
Chase Dorsey: Hello everyone, welcome to this webinar, “Architecting Success With Scalable System Design.” Thank you for joining us today. I'm Chase Dorsey, and I'm here today with my colleagues Brad Fischer and Tom Goetz.
00:13
Chase Dorsey: We're all sales engineers here at Inductive Automation, and we're excited to dive into Ignition architectures with you today.
00:20
Brad Fischer: I'm Brad Fischer, and as a sales engineer, I help customers with module selection, best practices, and system architecture. Prior to joining IA three years ago, I worked as a systems integrator for over eight years. Designing, deploying, and maintaining Ignition systems in a variety of industries, including water and wastewater, fiber extrusion, metal fabrication, and automotive manufacturing.
00:43
Tom Goetz: And I'm Tom Goetz, also a sales engineer here at IA. I've been with the company for two years. I bring nearly 11 years of industry experience, during which I discovered Ignition and implemented an Ignition SCADA system across various operations.
01:01
Chase Dorsey: So on the agenda for today, we will start by telling you guys a little bit about Inductive Automation, following with getting into standard Ignition architectures, then moving on to features of the Ignition Architecture Builder, and then at the end we'll have some Q&A. If you think of any questions during the webinar, go ahead and type it into the question area of the GoToWebinar control panel, and we'll answer as many of them as we can. If we can't get to your question today, please reach out to one of our knowledgeable account representatives, and they will answer it for you.
01:31
Chase Dorsey: We'll have their contact info available at the end of the webinar. Also, this webinar and its slides will be made available within the next few days if you wanna go over any of this again or share it with somebody who wasn't able to make it today. So to introduce Inductive Automation, here are a few facts about us.
01:50
Chase Dorsey: We make software for problem solvers, and we're focused on our software platform, Ignition. We have over 300 employees throughout the US and now in Australia. 57% of the Fortune 100 and 44% of the Fortune 500 companies use Ignition.
02:06
Chase Dorsey: We have a highly diversified customer base across many different industries, and there are Ignition installations in over 100 countries. We have over 4000 integrators worldwide, and our company is profitable and independent with no outside investors, and our focus is on providing the best platform for our customers. First off, what is Ignition?
02:28
Chase Dorsey: Here's a quick summary. Ignition is a universal industrial application platform for HMI, SCADA, MES, and IIoT. It acts as a central hub for everything on the platform and beyond.
02:38
Chase Dorsey: You can use it to create any kind of industrial application. It's web-based, web-managed, and web-deployed. It has an unlimited licensing model that is cross-platform, and it offers industrial-strength security and stability.
02:53
Chase Dorsey: Well, now that we know what Ignition is, Brad, what is an Ignition architecture?
03:01
Brad Fischer: An Ignition architecture simply includes Ignition and other services working together. Ignition's deep interconnectivity means almost every gateway is part of an architecture. PLCs, databases, and clients make up the usual connections, but this could also extend out to ERP, MES, warehousing, and other systems.
03:20
Brad Fischer: It could also extend to MQTT brokers, load balancers, reverse proxies, and other IT tooling.
03:27
Chase Dorsey: So what are the limits of a single Ignition server?
03:30
Brad Fischer: That can be a difficult question to answer because Ignition is so configurable and customizable. Perspective screens built to replace Andon boards or maintenance displays may take fewer resources than dense, complex forms built for laboratory data entry or quality analysis. Embedded views, queries, and the number of tag bindings all affect the load applied to the gateway and therefore the performance of the server hosting it.
03:57
Brad Fischer: The number of connected devices and their corresponding tag count that get pulled into Ignition also has additional load applied to the gateway, making for an infinite number of combinations that affect gateway performance.
04:11
Tom Goetz: That's right, Brad. To help with this, Inductive Automation put together a server sizing and architecture guide to aid users in understanding some of these limits.
04:22
Tom Goetz: It's important to note that these are conservative estimates, and each individual deployment may very well exceed what's stated in the guide. However, some systems exceed these recommendations and reach compute resource limitations. In that event, multiple Ignition gateways can be deployed to work together.
04:43
Tom Goetz: We refer to this as a scale-out architecture. As you can see, we've divided Ignition's responsibilities between a front-end and a back-end gateway. This allows us to handle PLC communication and tag history on the back end, while the front end focuses on client visualizations and reporting.
05:05
Chase Dorsey: Note that both gateways are connected to the same SQL server, improving query performance. Ignition's flexible licensing model and modular design makes it easy and cost-effective to implement this architectural change. For example, when moving from a single gateway to a back-end/front-end architecture, the only license cost is the Ignition platform for the new gateway.
05:30
Tom Goetz: Let's assume we retain the back-end gateway, leaving our devices and tag history as configured. We'd need to purchase a new Ignition platform license for the front-end gateway with a tag history query only, which is free, and move Perspective and reporting from the back end to our new gateway. The total cost would be $1100 and a quick call to your sales rep.
05:57
Brad Fischer: Yeah, that's right, Tom, and this is a super common architecture. We see lots of users that grow into this architecture, and we see just as many choose it to better align with their security posture. In many cases, customers wanna segregate their IT and OT networks.
06:14
Brad Fischer: The back-end gateway would still need an OT network to connect to the PLCs, allowing Ignition to generate alarms and tag history, get that real-time information. And conversely, the front-end gateway then sits in the IT network, allowing engineers, quality control, even C-suite personnel to access that data. Real-time data and alarms are shared between the two via the gateway network, an encrypted gateway-to-gateway connection.
06:43
Brad Fischer: If you wanna know more about how to secure Ignition, Inductive Automation has a Security Hardening Guide. In our scale-out architecture example, the gateway network connection made between the back-end and front-end gateways should be configured as outgoing from the back-end gateway. This means there are no incoming firewall rules opened on the back-end gateway protecting our critical production equipment.
07:08
Brad Fischer: This guide not only addresses secure gateway communication, it also discusses identity and access management, audit logging, environmental hardening techniques such as DMZs, and more. In an Ignition architecture, a DMZ, or demilitarized zone, is a strategically designed network area that creates a secure separation between external networks, such as the internet or other IT systems, and internal OT, or operational technology, systems. The goal of this architecture is to add an extra layer of security to the local area network, allowing the local network to access what is exposed in the DMZ and keeping the rest of the network protected behind a firewall.
07:52
Brad Fischer: The Enterprise Administration Module, or EAM in Ignition, offers several features that can be leveraged to enhance security monitoring and management across your Ignition architecture. While its primary focus is on centralized administration and system management, it provides valuable tools and data relevant to security, such as centralized audit logs, system health monitoring and alerting, backup and recovery, and remote system oversight. All of these help enhance security by providing additional visibility, ensuring compliance through detailed logging and auditing, aiding in incident response, and delivering proactive monitoring data to identify potential problems before they adversely affect gateway performance.
08:36
Chase Dorsey: So now that we've covered a few reasons why scaling out to multiple gateways is necessary, what do we use to keep track of these complex architectures?
08:47
Tom Goetz: Thanks, Chase. I'm really excited to talk about this today. For years, the team at Inductive Automation, along with our integrators, have relied on various third-party applications to build Ignition architectures for demos or end-user OEM and internal systems.
09:06
Tom Goetz: As sales engineers, we have daily conversations with Ignition users, many of you listening today. These conversations often involve discussing architectures. Historically, we've used standard static drawing tools to demonstrate how a solution might fit your organization's needs, which can be hard to picture.
09:28
Tom Goetz: Additionally, we would spend days after those discussions creating customized architectures, followed by extensive back-and-forth to finalize those designs.
09:39
Tom Goetz: But not anymore. Using Ignition, we've developed a feature-rich Perspective application that not only enables us to create custom architectures but also includes built-in rules, many customization options, and tools for both IT and OT environments, all within a single platform.
10:00
Tom Goetz: Initially, we considered keeping this tool for internal use only. However, after just a few discussions with our customers, it became apparent how much this tool could accelerate Ignition deployments. The Ignition Architecture Builder has quickly become essential in our conversations, transforming the way we support and plan projects.
10:21
Tom Goetz: So, let's look at a common scenario that many of us are familiar with, and how using this tool helps to track as the system grows. Here's a customer manufacturing site. Pretty simple, right?
10:34
Tom Goetz: It has a device, but no data coming out of it, other than maybe that clipboard the operator is carrying around.
10:40
Chase Dorsey: That sounds like a mess, Tom.
10:43
Tom Goetz: Exactly, Chase. The customer would love to find a way to record data from the PLC and visualize what is happening across their site.
10:53
Brad Fischer: And I wonder who could fit that role?
10:54
Tom Goetz: Well, Brad, I have a pretty good idea on who that is. Due to Ignition's unlimited licensing model, and the ability to develop and scale rapidly, Ignition is often the choice to make that connection. Our sales team encourages new users to download and utilize the free Ignition trial to develop and test the application and only purchase a license after you know what the application needs to do and what modules are required.
11:28
Brad Fischer: And this is a perfect time to remind everyone that having discussions around architectures and module selection is exactly what we sales engineers are here to do.
11:37
Tom Goetz: That's right, Brad. So what is next in many Ignition implementation journeys?
11:46
Tom Goetz: At this point, many users see the rapid growth of the architecture and applications on the platform. As a former manufacturing process engineer, I've personally experienced this. A license was purchased for a single specific use case, but we found that Ignition's land and expand concept was precisely what happened.
12:10
Tom Goetz: As other engineers discovered the platform's unlimited licensing and rapid development capabilities, we realized Ignition truly exemplified “Dream It, Do It.” Connecting to databases, devices, additional clients, new projects, adding redundancy on Ignition gateway for that automatic failover, and connecting up to other systems and protocols.
12:39
Chase Dorsey: Wow, this architecture is really getting use out of the unlimited licensing.
12:42
Tom Goetz: Exactly. And this is all possible with... This was all possible with a single license we purchased for what was a single use case. But at some point, we find ourselves maxing out our hardware or finding a need to add additional security layers between user interfaces and devices controlling the equipment.
13:04
Tom Goetz: Inductive Automation suggests scaling out here, splitting the front-end application or applications from the back-end tasks, like we've discussed a bit ago. In parallel, we often see entire organizations adopt Ignition, where new Ignition sites pull from the experiences of pre-existing or pilot Ignition sites, making the deployments much quicker. Ignition's gateway network supports this multi-site architecture, facilitating bi-directional communication via a single secure inter-site connection.
13:40
Tom Goetz: And growth continues across the board. At some point, a central gateway may be required to store long-term history, display enterprise dashboards, perform analytics, and manage these systems from one location. This is where the use of Ignition in the cloud or a central data center becomes very common.
14:04
Tom Goetz: And in the opposite direction, Ignition Edge reaches to point-of-use processes, easily allowing for expansion to remote assets, whether they are geographically remote or just remote within a building or campus. Now that nearly everyone in our organization has access to those centrally hosted dashboards, we may need to add multiple front-ends behind a load balancer to accommodate the large number of individuals hitting our central front-end gateway. Ignition Cloud Edition, combined with the auto-scaling capabilities of the major cloud platforms, allow for a potential cost-effective solution to manage client variability while reducing the number of Ignition servers required based on those demand fluctuations.
14:53
Chase Dorsey: Well, now that we've seen this expanding architecture, why don't we see this tool in action, Tom?
14:57
Tom Goetz: Yeah, absolutely. Give me a second here to share my screen. So this is the primary landing page of the Ignition Architecture Builder.
15:06
Tom Goetz: As I mentioned earlier, this application comes packed with features designed to accelerate the creation and modification of architectures on the fly. I'll start by highlighting a few of those key features, and then I'll dive into a demonstration of actually building out an architecture. While brainstorming what we wanted to get out of this tool, we knew it needed to be flexible enough to support the most basic architectures and complex enterprise solutions.
15:37
Tom Goetz: Luckily for us, Mike Bordikov, an application engineer here at Inductive Automation, developed a free pan-zoom Exchange resource that allows us to scale infinitely within this application. The file menu provides all the standard functionalities you'd expect for opening, saving, managing, etcetera. However, we quickly realized the need for additional features, such as inserting pre-built architectures that we could use as templates, either individually or at scale.
16:10
Tom Goetz: We've also added options for importing and exporting architectures from a single JSON file, making it as simple as sending an email attachment to share architectures. Next are the chart tools. These tools let us customize the look and feel of the system, from resizing your working canvas for accommodating those large or expanding architectures to specifying which components to render on screen.
16:36
Tom Goetz: So maybe I just wanna see Ignition gateways or databases, really gives you that flexibility to simplify what you're looking at. So now that we've walked through a lot of, or a few, I don't wanna say a lot, a few of those key features that we implemented in this project, I wanna start actually building out an architecture. We'll begin by placing the Ignition standard gateway on the canvas.
17:03
Tom Goetz: And what you'll notice right away is there was a toast notification on the bottom that guides users on various events during the build process. We saw a message stating that this interface is not designed to be drag and drop. So let's click on our gateway again and show you how it's placed by selecting the component and clicking on the canvas.
17:24
Tom Goetz: Great. Next, we'll add a database, a device, as well as a client. To make one of those very basic architectures.
17:37
Tom Goetz: Okay, but what about connecting these together? Within the Ignition platform, most of us know that we can connect up to nearly anything. In the bottom left corner, we have the connection legend, which defines what color each connection is and links us to the appropriate page in our docs manual.
17:56
Tom Goetz: Let's add those connections. We'll click on the connections icon and be presented with a new menu, and also see that the components on the screen are now displaying anchor points. It's as simple as clicking on the desired anchors for those targets, defining what the connection type is.
18:17
Tom Goetz: And a lot of this is pre-built within the application. It knows that that gateway connected to a database. So it's a database connection, but there are other options.
18:26
Tom Goetz: And then hitting apply. Sweet. But when we place many components on the screen, you can see how this process can be tedious, so we've added the ability to pin and auto-apply the default connection type, making things much faster, and that's how I’ll connect up the client and the device on the screen here. You can also modify those connections after the fact by simply clicking on the connection and adjusting it as you see fit, so we’ll go into this device connection, and within the connection type, let's change it to OPC UA, so we could see that color change right away, and you can see the modifications are pretty straightforward. So we've created a simple architecture, now we'll save this architecture file save into our templates folder, and let's call this Standard Architecture. It looks like I already have that in there. Similar to designers, users can save architectures and use them as templates in other projects, as I already stated, so you did see another toast notification that came up there and said it was saved as a confirmation. Now let's create a new architecture by navigating to File > New and in this case, because we just say we're gonna like, don't save, and let's make a very simple edge site will place an edge gateway along with the device.
20:08
Tom Goetz: Apply the connection between those two. And what we wanna do next is actually group them, so we'll group these components into an area by using the add area feature.
20:22
Tom Goetz: And then within all of these components, we have the ability to jump into those configurations. So in this case, I wanna rename this Edge Site, and let's just change the color of the background to a green with some opacity to it. Perfect. So now you could see we have those changes, everything is contained within that site, and we're gonna save this as Edge Site in that same folder. Alright, great, so I'm gonna clear that out. So that was a demonstration on building a couple of very simple architectures, now let's move on to modifying an architecture where we need to scale out Ignition due to, let's say, resource constraints. So we're gonna open a pre-built architecture that I've already built, and it's gonna be this scale-out site, what you'll notice here within this site, you can actually nest those areas as well, so you could see how this could work for a larger organization. Here you'll see that we have 40 devices and 30 clients connected to a single gateway. Given the anticipated future growth of my site, we wanna split it into a front-end and back-end gateway. Each component utilizes a context menu that allows us to perform various tasks, such as resizing, for example, I'm gonna resize that manufacturing site now, so I'll right-click, resize, and just drag that out to make room for that additional front-end gateway.
22:12
Tom Goetz: We can also double-click on components to move them individually, so I'll show this with the database, we can move that out of the way for right now. The Area Context Menu also provides an option to move everything within that area, so all of its contents. So let's relocate the devices now off to the right to accommodate some of those additional components we're gonna add. So at this point, I'm gonna move the standard gateway over and organize this in preparation to add that front-end gateway. The last thing that I need to do here is because I'm not gonna have any client connections coming into this back-end gateway, I wanna remove those client connections as well as rename this Standard Gateway back-end.
23:07
Brad Fischer: As Tom mentioned, we're now adding a front-end gateway, we have a scale-out architecture guide available for free in our online user manual, which outlines the steps for doing this. I'll explain some of those steps here. We'll start by adding the front-end gateway through the architecture and renaming it front-end, and next we'll connect all the clients to this new front-end gateway to make sure that they can see the data that they need. We'll also need to establish an outbound gateway network can actually from the back-end to the front-end gateway. We also need to set up a database connection to access all that historical data, which will be used for the visualizations that our clients wanna see. Ignition’s flexible licensing model truly shines here, users will need to contact their sales representatives to move the visualization modules. In our case, reporting and Perspective from the back-end license to the new front-end license.
24:04
Brad Fischer: Additionally, we will add one free module, the Tag Historian Module and query-only mode, which allows us to as the name suggest, query that historical data that we stored in the database, thus the only cost involved for the core platform and the appropriate hardware, the scale-out architecture guide also covers how to migrate additional resources from the back-end to the front-end gateway as well as where to place modules, because I know we haven't covered all of those individual things in this session. That would be a great guide to read for anybody looking to go from a single gateway architecture to the scale-out architecture.
24:44
Tom Goetz: Thanks, Brad. So now that we've scaled out our local site, let's add in several of those edge sites that we previously saved, so the first thing we're gonna do here is we need to resize our canvas to accommodate those edge sites, so let's make our height 1000 pixels and apply that to note here, if you do play something off the boundary, it's gonna resize automatically, so in our case, we don't wanna open that architecture, but rather we wanna insert it from our file menu, file insert, and we're gonna navigate to that edge site that we previously created, in our case, I know that I want four edge sites and instead of putting those in individually, we have the option for an instance wizard to where I can select the number of instances to find the space in between them and insert those at scale.
25:41
Tom Goetz: So I'm gonna change that instance four and insert those right into our architecture. Now you can see what we've pre-developed here: four copies of that have been inserted, and now all we have to do is apply those outgoing connections from edge to our back-end gateway, and then we're left with a hub and spoke architecture. And that's the last one applied, you can see how quickly we can develop and how much easier it is to describe what's going on. By having a visual representation of our system, discussions are much more productive. I'm going to turn over control to Brad, so he can discuss some of the additional features within the application.
26:31
Brad Fischer: Yeah, thanks, Tom. So here's that architecture that Tom had just developed, I've edited this a little bit, we've expanded the manufacturing site, given our lines some different names and color coding, but you can see this really is the same architecture. So I wanna talk a little bit about the BOM. So we have a bill of materials, it's included in the Architecture Builder. It's successful up here under BOM, open BOM. And so I've got that open here in another window, we're using session properties to share this information, so you could even have this pulled up on two different screens. It's up to you as to how you want to manifest that.
27:14
Brad Fischer: I'm also gonna zoom in a little bit here, so we can really see our gateways, so in our BOM viewer over here, you can see we have a similar file view kind of context menu set up, and so in file, we can go through, we can export the BOM view, we can change what's being displayed, EAM, we can go in and actually set up EAM unlimited if that's something that we're using in our deployment, but as you can see, I've got different entries here for the various gateways, so here's a standard addition, Ignition gateways in our manufacturing site. It's called Front-End, and here's our gateway configuration, so we could go through and specify the version license key if we have one, if we wanted to, we could set this up to be redundant, and you'll see that the price changes here to reflect that as well. We could also edit the description and things like that. I’m gonna go ahead and hide the configuration for these gateways just to make this sort of cleaner. You also see that we have all of our modules listed, the ones that we have selected, so for our front end, and we have the platform, OPC UA, Perspective unlimited, and reporting, and if we wanna do something that change this to five sessions, we could certainly do that from here, and we'd be able to see the price change, you also see an alert come up that says that the five-session limit has been exceeded because we actually have 30 clients that are connected to the front-end gateway.
28:45
Brad Fischer: We also have support plans over here in the BOM, and so this gives us just another place where we can go through and identify which of these support plans would be best for us, the cost of that, upgrades, and things. Again, if we didn't want to concern ourselves with support plans right now, we could certainly hide the support plans and their associated costs. You see, we have our back-end server listed here too, but let's go look at one of these edge gateways. I can certainly scroll down here, but in larger architectures, it can get cumbersome to find the gateway that you actually wanna target. If you use the context menu here, we can actually hit View in BOM, and it will scroll right there, so you can see this is in our manufacturing site, the area I call the expansion line number three, and this one simply named Edge IIoT. As you can see, all the functionality we have, the MQTT Transmission Module, and then that total cost, there is $900. Under View, I do wanna go back and choose to show our Computing Load and Resources section, so this is driven off of that Server Sizing and Architecture Guide that we had talked about earlier, which is available, if you click this hyperlink right here, will open that guide a new tab.
30:00
Brad Fischer: But the idea here is to allow us to capture some of the critical metrics about this particular Ignition gateway, so in this case, I'm on line three, we can see we have a one device that we're connected to, maybe we were subscribing to about 500 tags. I'm gonna use an ARM processor out there, there's not a whole lot of history coming from this one, and it's about 50 tag inserts per second. That said, my IT team has said that they need a 72-hour SLA on this particular device. If one of these goes down, they'll try to get to it, but it could be up to three days before I actually get a connection re-established back up to my main server. So I'm gonna go ahead and set this to be 72 hours of retention, and you'll see that I have a little exclamation mark come up down here, recommending that I have at least 11.21 gigabytes of disk space. We've done that by calculating the tech history per second and the retention time, but it's all kind of a moot point. I'm actually gonna have a 64 gig SSD on this particular machine that's also gonna be running Linux.
31:06
Brad Fischer: I'll go into 2404 at LTS, so we can capture all of this information in the tool. Similarly, if I go back up to of my, say my back-end gateways here, we can see that we have 40 devices connected, maybe I'm pulling in something like 55,000 tags to note that my CPU and RAM are both giving me alerts, and so for the CPU, it's recommending that we have at least eight cores, the memory, it's recommending at least eight gigs, I'm actually gonna put 16 on this particular server, give it a 500 gig SSD, and we could go through here and put in our history as well, somehow we're capturing close to 1800 tag history entries for second. There's another couple coming in from SQL, and then our retention time would be 24 hours, so again, that's gonna require something like 25 gigs of disk space. But I have 500 gigs. It's not a problem. I can also go down here and select the operating system, so we're gonna put this on a Windows server 2022. So anyway, the whole idea here was not only to capture the layout and the individual modules and how these different parts are communicating, but as well as the computing load and the resources as well, as a former system integrator, this was always something that I had to sit down and figure out after meeting with the customer was to develop that BOM and be able to provide it to them.
32:38
Brad Fischer: And so if we go in here and we actually look at exporting some of this, we have the ability to export this current architecture, and Tom referred to this earlier, this is the entire JSON driving all of the information you see on screen here, and so if you just exported that JSON, you could email that to someone else, they could do a file import, load that in be able to see the entire architecture, all of our connections, all of this information is contextual information that we've already added here. We also have the ability to export a third-party module library that could be really useful for some of the integrators out there that are creating their own modules.
33:19
Brad Fischer: And in the Bill of Material section, we also have the ability to export the Ignition module selections and their pricing, as well as a list of Ignition gateways, and so that can include their configuration, the system load computing resources, and if we select these things, we could do it as an XLS or a CSV. So once again, the idea is to make all of this information not only available in the tool but externally as well, so we could easily import that into Excel if we wanted to go through and graph something by region or by line or maybe a certain expansion and have that data available to be put into other programs.
34:02
Brad Fischer: Yeah, again, as a former system integrator, I really felt that including a BOM in the Architecture Builder would help users better understand and document the pricing as well as the compute requirements for their solutions.
34:17
Chase Dorsey: Yeah, thanks so much, Brad. As the idea for the Architecture Builder matured, it became clear that it should be shared externally, so we've actually listed it on the Ignition exchange. It's live right now. It's posted here. You can use the QR code to get to it. If you're not familiar with what the Ignition exchange actually is, it's an online website where you can host resources, templates, and tools that you can use in your own Ignition projects, and they all work with the free Ignition trial. This collection encompasses anything that can be built inside Ignition, including but not limited to screens, graphics, templates, views, reports, alarm pipeline, scripting functions, database backups. I could keep going on and on.
35:00
Tom Goetz: We also plan to continue updating this application as new features are requested and bugs are identified as noted on the exchange, this resource makes use of Perspective and the Web Dev modules, so make sure that you have both of them installed in your gateway if you plan to use the three source, there's also a post on the Inductive Automation forums with a link included at the top right of the Architecture Builder, where you can see what's new report bugs, ask questions, request new features, or just make general comments. We would love to hear your feedback.
35:32
Chase Dorsey: A little birdie told me that it's getting updated to use some of the new features that are coming in 8.3, which is really gonna expand the door to what is possible with the Architecture Builder. So if you’ve never tried Ignition, you can download the free trial today and go grab the Architecture Builder and try it for yourself. Ignition is quick to download, takes about three minutes to install, and you can use it in trial mode for as long as you want, so you can dive right in and explore. I'd also like to mention that we have Inductive University, which is a free online training website with hundreds of training videos so that you can learn Ignition step-by-step at your own pace, and it also comes with a comprehensive online user manual that you can refer to at any time. We have also just launched our new Inductive Automation Gear Store, so go check it out and browse through our selection of official IA clothes, mugs, water bottles, and much more. For those of you outside North America, we have a network of international Ignition distributors who provide business development opportunities, sales and technical support in your language and time zone. If you wanna learn more about the distributor in your region, please visit their website, which is on-screen here, or you can contact our international distribution manager, Yegor Karnaukhov.
36:44
Chase Dorsey: If you'd like to speak with one of our account representatives at our headquarters in California, please call 800-266-7798 to reach our office in Australia, you can call the number on screen. Now, let's get into the Q&A, and as a reminder, you can still type questions into the question area of the GoTo Webinar control panel, and we'll try to answer them right away. So to start off with, we had a quick one relating to where could we access it, we just went over, but just to reiterate, it is open and available on the Exchange right now, you could download it as soon as this webinar is over, but please stick around for some of the questions. Next up, let's go to Brad with Ted's question. “With a front-end and back-end gateway, how are the users synced between the gateway?”
37:34
Brad Fischer: That's a great question, Ted. So if you're using Ignition's internal user source, you typically wouldn't even need to synchronize those users. We would really recommend keeping the user source for your front-end to be on the front-end gateway.
37:52
Brad Fischer: There's really no reason to have your operators and such log into the back-end gateway. There's no visualization server anymore, so they would really only be using those credentials to get to something like the designer or the gateway web page, which is probably not ideal. That's something we wanna reserve for our control systems engineers, our integrators that are coming in to work on the system.
38:14
Brad Fischer: We would also recommend having two... Go ahead, Chase. Yeah.
38:19
Chase Dorsey: I was just gonna say, it's a great time to mention the Security Hardening Guide actually covers this topic extensively.
38:28
Brad Fischer: Exactly, exactly. Yeah, there's a lot of details in there that would be great to read through. And we even recommend having separate profiles for your back-end and front-end gateways because you typically don't want one set of credentials to work for the other.
38:43
Brad Fischer: Again, that defense in layers, defense in depth, the idea of segregating these systems as a security posture is one that's pretty common.
38:53
Chase Dorsey: Great. Well, moving on, let's go to Francois' question for Tom. Do we need to split out a project into a front end and a back end?
39:05
Tom Goetz: Yeah, absolutely. So the short answer, depending on what is in your project, is yes. Our scale-out architecture guide actually defines this pretty well.
39:17
Tom Goetz: And it covers a lot of what Brad was also mentioning there in regards to identity providers and user sources. So that guide covers alarming auditing, reporting, visualization, tags, and I can go on and on. And it is available on our user manual in the tutorials and helpful tricks area of the user manual.
39:40
Tom Goetz: So I suggest looking through that guide. And if you have additional questions, that's a good opportunity to get a hold of the sales rep, and they'll get you on a call with somebody like Brad, Chase, or myself to where we can go down into the details on your project and how we can split that out into a front-end and back-end.
40:01
Chase Dorsey: Nice. Gonna the next question by Andy for Brad, system integrator here, what does the BOM look like when it's exported into Excel?
40:11
Brad Fischer: Yeah, let me show my screen here. I've got that export actually pulled up. And so you can see that we basically, for the gateways, we have this listed out by area using slash to denote those different nested areas.
40:34
Brad Fischer: We've got the name of the gateway, the type, version, license keys. Is it redundant? Is it a development gateway trial? The number of devices and tags and history.
40:44
Brad Fischer: So all that information has been captured here. And so you could even go through and do something like, you know, specify a sum, pulling all of the history or the number of tags together, things like that. In terms of the modules, that's gonna look like this.
41:00
Brad Fischer: So we have it broken up a little bit differently. So in the area, we have a specific gateway, we've got its type, and then the module that's included. If there's any selection that goes along with that module, such as unlimited for Perspective, and then the pricing that's there as well.
41:17
Brad Fischer: So the idea, again, is this information is just available in at least some format that you can get out of the Architecture Builder and into another tool, again, to make a submittal request or even an RFP, something like that. We wanted the information to be externally available.
41:34
Chase Dorsey: That's really cool, Brad. Thanks for showing that off for us. The next question is for Tom, and it says, “How relevant is the pricing? Meaning if a module's price changes, would that reflect in the app?”
41:49
Tom Goetz: Yeah, so that's a great question. And as Brad and I were building out this application, that was one thing that became very apparent to us is that we want this to be a dynamic tool. As of today, it's a static number coded into a project script.
42:09
Tom Goetz: Our goal, and what you'll find on the forum, is we are doing some release cycles on this, adding new features, fixing bugs. But our goal is to actually reach out and hit an API endpoint to pull in those prices as they are right now today. We aren't currently set up for that, but keep an eye on that forum post, and it's gonna give you some insight on what's being released, what has been released, and potentially what's coming.
42:37
Brad Fischer: Yeah, I do wanna add on to that briefly. So one of the reasons we also kept it in a script within the project today was so that this tool could actually be used completely offline. I remember as a system integrator, I sometimes would go into customer facilities, and while I was pitching Ignition or talking to them about, you know, something that might be going on with their control system, they didn't always have internet connectivity for me.
43:03
Brad Fischer: Maybe I was the new guy, they wanted to establish a rapport with me before they just threw me on their corporate Wi-Fi. So I wanted this tool to be able to be used completely offline so that you could walk in, have this running on your laptop and Docker, whatever it might be, and be able to have up-to-date pricing. So yeah, it's absolutely something that Tom and I are signed up for.
43:30
Brad Fischer: We wanna make sure that this resource and the pricing within stays updated and current. So whenever we do have a pricing change coming here at IA, we'll have a new version of this resource available in the exchange.
43:45
Chase Dorsey: That's awesome. While you're talking, Brad, another question for you came in. “If alarming is on the backend gateway, then how does it know what phone numbers to send the alarms to if the user sources are not synced between the gateway?”
43:54
Brad Fischer: And that's a great question. In that case, we would actually need to put the alarm module on both the front-end and back-end gateways. And so then we have the ability to have the alarms created on the back end, but leverage the pipelines that have now been defined on the front end, and that would give us the ability to get to our SMTP server, maybe our VoIP gateway, and of course, access all of our user information.
44:24
Chase Dorsey: Great answer. For Tom, “Is the Architecture Builder able to calculate other currencies other than USD, or do we have to convert and speak to an area supplier?”
44:35
Tom Goetz: Yeah, and I am gonna kind of go back to the last question I answered is that is an awesome feature request for the Architecture Builder because we're not just based in the US. Inductive Automation and Ignition is global. If you have an opportunity, visit the forum and put that in there as a future request. We'll get that into our system and get that implemented, hopefully sooner than later. I do wanna make note that, like Brad and I talked about, is those are static values currently within the application. So it's always best to reach out to your sales rep to confirm that the pricing that this application has output is the same as what we have listed on our website.
45:25
Chase Dorsey: Thanks, Tom. Another one for Brad. I am planning to deploy Ignition to a new customer site. “I'm planning to use Ignition Edge at a field facility and a gateway with most of the modules at a gateway with most modules. As the Edge license has a retention period for the history, can I use the central gateway in order to store all tag history generated by the edge?”
45:51
Brad Fischer: And that's a great question. That's one I think all of us here in the sales engineering division answer a lot. Yes, absolutely. That's one of the primary use cases for Edge is to have that more limited version of Ignition out at the edge of your gateway, the edge of your network. And yeah, in the event that we don't have a connection back up to that standard gateway, it's got 35 days of history that it can buffer there on the device. So operators would still be able to walk up in the case of Edge Panel and see their alarms, see those 35 days of history on various charts.
46:31
Brad Fischer: Once that connection is re-established, all of that information will automatically be synchronized back up to the standard gateway. And that's done over the gateway network. Again, that encrypted gateway-to-gateway, point to point connection between two Ignition gateways, and then basically sync services is what we call it in Edge. So we're able to point at another gateway and say, “Hey, I wanna leverage the standard gateways Tag Historian Module. This is the profile that I wanna use.” And that's how all of that data would be synchronized. It's very quick to set up. And again, with all the buffering that's in place, it's been a very good solution for a lot of our customers for a long time now.
47:15
Chase Dorsey: Yeah. And this is a great point to just remind everybody that having conversations like this is exactly what we as sales engineers here do at Inductive Automation. So if you want, reach out to one of the sales reps on screen, and they'll be able to help schedule you a time to get to come talk with us about some of these questions. But while we still have some time, let's keep answering some more questions. The next one is for Tom and asks, “Is the Architecture Builder autonomous, or is it part of the main gateway web page?”
47:46
Tom Goetz: Yeah. So the Architecture Builder is actually a project on your gateway. We suggest because it is a little bit more resource intensive is actually spinning up a separate gateway to run the Architecture Builder on. But again, it is just a project as if you were building out a project for maybe one of your other applications at your site. I hope that answers your question well enough.
48:17
Chase Dorsey: Yeah, I think that's a pretty good answer, Tom. And just to remind everybody again, you can just get the project and put it on the trial mode of Ignition because if you need to spin up that new server and you may not have a license for it, you don't need one. You can just use the trial and design out your whole architecture that way.
48:35
Tom Goetz: And one final thing to note there, Chase, is we just wanna make sure that you're aware that you need the Perspective and the Web Dev Module, both available within that trial.
48:46
Chase Dorsey: Yeah. Good note, Tom. Continuing on, we have another question. “Can the different team members work on the same architecture model simultaneously?”
49:00
Brad Fischer: Yeah, I'll take this one, Chase. So currently, the way we have the tool set up, this isn't completely possible. There wouldn't be a way to open up the exact same file and have multiple people dragging and dropping components into the same workspace.
49:16
Brad Fischer: That said, you could both have the Architecture Builder installed or even on the same server and have multiple sessions against it. And just like Tom showed us earlier, you could go through and build a smaller portion or the expansion part of the plant and such. And then you'd be able to save that to disk, send the raw JSON to your coworker. They could then import that part of the diagram and put it together. I do like the idea of having multiple team members work together. But today, that's not how the tool was developed. Yeah, great question.
49:57
Chase Dorsey: Awesome answer, Brad. Tom, for you, somebody in the chat is asking, “What's the best way to become Ignition certified?”
50:06
Tom Goetz: Yeah, absolutely. We have a couple different routes that you can take to become Ignition certified. And really, the best way is gonna depend on what your schedule looks like and what your availability is. So as we mentioned in the presentation, Inductive University is going to walk you through everything you need to become certified. And then it's as simple as taking a certification test to become core certified. After that, there are additional steps in the certification process.
50:37
Tom Goetz: The next step would be gold certification. Again, there's a test related to that. But all of the information regarding training and certification is available on our website under the support drop-down. I suggest checking that out. And if you have additional questions regarding that, get a hold of one of our sales reps. They're really good at these conversations and can help you on your way through to becoming certified.
51:07
Chase Dorsey: Yeah, this is a great time to remind everybody that you can also take some of our in-person or virtual training classes as well to help get those certifications. The next question we have is, “What is the main benefit of separating the front end and back end? Is it only CPU load?”
51:23
Chase Dorsey: Brad, do you think you can handle this one?
51:26
Brad Fischer: Yeah, yeah, I can take this one. So in some cases, it could be for reasons such as compute resource exhaustion, right? We're seeing really high CPU usage. Maybe we don't have any more memory on that particular hardware, VM, Docker container, whatever it is. We aren't able to give the gateway any more compute resources to use to meet the demand that we're seeing Ignition need that to be able to leverage. So in that case, that can be a really good reason to move to the scale-out architecture. You could simply buy another full server and put it next to it, but now you have two front-ends and your PLCs are split between the back-ends. It doesn't really make a lot of sense.
52:08
Brad Fischer: That's one of the reasons we kind of talked about trying to... When you move to the scale-out idea, putting similar modules together. So now that we have a single front-end that's handling just the clients coming in requesting visualization sessions, and we have the back-end that's really just handling our PLC subscriptions, getting those tags in, making that real-time data available, handling alarms, tag history, those kinds of things. And like we mentioned earlier in the webinar, some customers choose to do this purely from a security posture, an architectural point of view.
52:43
Brad Fischer: They want to have those two systems separated, even if there aren't any compute resource limitations that they're bumping up to today. I've also seen customers choose to go with this during maybe a phase one rollout, knowing that they're gonna start to expand in phase two or phase three, and they just wanna go ahead and have that architecture already set up and everybody be comfortable with it.
53:07
Tom Goetz: Yeah, Brad, and that's a very common scenario in maybe additional sites coming online, but that land and expand comment that we made earlier, people can foresee this growth, and helping to separate out those resources on the back end and front end are often acknowledged early on in those multi-site implementations.
53:31
Chase Dorsey: Okay, well, we're just about out of time, so I think we can answer one more question and then wrap it up. So the final question is for Tom, and it is, “Can you suggest some extra things to learn to get myself more proficient with Ignition besides the Inductive University?”
53:49
Tom Goetz: Yeah, absolutely, and there's some... I personally think one of the best ways to learn Ignition is find a problem that you're trying to solve either in the manufacturing site or the organization that you're in, download the free trial, and build something out, or my favorite is utilize Ignition Maker Edition at home. I have a server sitting behind me right now where I'm running, trying to build my house out to be a smart home, for instance. Within there, there's a lot of different applications that I've built that have pulled from the Ignition Exchange. Again, our exchange is a huge resource that you can utilize to pull in all kinds of different ideas to kind of spark those ideas as well. Brad, I don't know if you, Brad, or Chase, I don't know if you guys have anything to add to that.
54:44
Brad Fischer: I would say, yeah, check out the exchange, maybe pull down some of our online demo projects or the Build-a-Thon challenges that have been published for the last few years. That would be a really good way to go through and look at what some of the application and sales engineers here at Inductive Automation have built and the processes that they used.
55:06
Chase Dorsey: Awesome. Well, that's all the time that we have today, so I just wanna give a big thank you to everybody else. We'll be back on December 12th with a new webinar, but until then, you can stay connected with us on social media and subscribe to our weekly newsfeed email.
55:21
Chase Dorsey: Thanks everybody for joining us, and have a wonderful day.
Want to stay up-to-date with us?
Sign up for our weekly News Feed.