About this Webinar

To adapt to a changing business landscape, industrial organizations need SCADA software that can expand with them without overwhelming their budget. A growing number of industrial organizations are choosing to build their architectures with a SCADA platform that is modular, web-launched, and server-centric. Why? Because they can deploy this new SCADA platform effectively anywhere, whether they run it at one site, use it to connect many sites all over the map, or use it in the Cloud.

Webinar Transcript

0:00
Don: Good Morning, everyone and welcome to today's webinar. My name is Don Pearson, I'm the Chief Strategy Officer here at Inductive Automation, and I'll be working today with Travis Cox who I'll introduce in a couple of minutes on today's presentation. Topic is building your architecture with the new SCADA proven deployment strategies for Ignition. Just a little bit of a look at what we're gonna cover today before we get into it, I'll do a little bit of an introduction to Ignition. A little bit of overview on the subject of SCADA software architecture. We'll talk about the advantages of building on a modular platform, then we'll discuss logging and visualizing your data. We'll talk about commonly used architectures for Ignition. Meaning deploying a single Ignition server, multiple Ignition servers, hub and spoke architectures and also hosting Ignition in the cloud.

0:46
Don: A little background on us at Inductive Automation, we were founded in 2003. It was founded as the first really database-centric HMI/SCADA MES Software that really... And now it's going to be used in over 95 countries. We've built up an innovative program which is approaching 1300 integrators now serving those countries. And really it's used in about any industry you can possibly imagine, from oil and gas to water and wastewater, food and beverage, government, transportation, packaging databases, just almost every industry you can think of. And across thousands of companies too around the world. I think now we're sitting a little north of 30% of Fortune 100 companies that actually are using our software to build pretty flexible and innovative HMI/SCADA and MES systems for their enterprises.

01:39
Don: Just to comment on that, I think one of the reasons it's being adopted so quickly and across so many industries is because both industrial organizations and the integrators realized that Ignition really has the power to really almost build anything they could possibly want. It's unbeatable as an HMI/SCADA MES solution, but the technology, our innovative licensing model, the architecture, make it different from other SCADA softwares, as you're gonna see a little bit as we go into the discussion today. It's powerful enough to use on just about any project, and flexible enough for just about any architecture. And we're going to cover a number of those architectures today. So we'll go into detail about some of the features in Ignition that really help it to be deployed in so many industries. I'd like to introduce Travis Cox. He and I will be working together on the webinar today. He is the Director of Sales Engineering here at Inductive Automation. He's been with the company actually since the very beginning. And previously led our training and support teams, and has overseen very many successful project launches. So Travis, could you just take a minute, introduce yourself. A little bit about your background and what you do here at Inductive.

02:52
Travis: Well, as Director of Sales Engineering here at Inductive Automation, our team is responsible for being that technical presence for our innovators and our end users. So architecture is a big part of our discussions that we have with customers as they determine the best fit, and potentially how many servers they need and exactly what they need to put in place to achieve their overall enterprise solution. And from me personally, I've been with the company since the beginning and trained hundreds and thousands of people on Ignition, and I've also done successful projects myself. And that experience really leads into what we're gonna be seeing here today about different ways you can deploy Ignition.

03:30
Don: That's great, thanks, Travis. I mentioned the modular architecture, but I wanna take a couple of minutes and talk about what it means to be building on a modular platform. One of the most basic rules of architecture is that for a structure to be strong, obviously, it has to be set on a pretty solid foundation. But with today's enterprises, obviously, there's added challenges of building technology infrastructures that aren't just solid foundations, but also have to be extremely flexible. Just mentioning it, when you're talking about a modular architecture, one of the things that you really need to do is help one handle change in what is considered to be a pretty unpredictable world right now, where the internet is continuing to transform the way business is done. Industries are in transition, new markets opening, consumer habits shifting, it has to be adaptable also 'cause a lot of organizations now are asking themselves the question of what are they gonna do to have that flexible architecture that allows them to move forward when changes occur out in the environment.

04:31
Don: Ignition actually as a platform is uniquely scalable SCADA software. Can be deployed in many different architectures because of this modular nature. And if modular software sounds like an odd concept, it simply means that you customize the Ignition platform by just adding the software modules to it. But I also wanna be clear here, in explaining this, it's one unified platform that you install one time, have one designer and then you just add modules to increase its functionality. But you don't have to install or configure the modules separately, you configure everything in one single designer application. So that's important, I think, to emphasize is sort of, I guess like apps on your smartphone. You add the apps right on your phone, it's the same phone, but now it has a new feature because you can use it to do different things 'cause of that application.

05:17
Don: So it's similar to the way this architecture works. The platform includes a variety of functionality listed here you can see. It's a web-based industrial application server. It includes a built-in designer also provides connectivity to databases as well as OPC connectivity, it allows it to communicate with thousands of different devices. And it comes with the store and forward feature, core alarming security and redundancy features as well, and real-time tag database and application program interface, and just a whole bunch of other powerful features that go along with it. So here you have a platform with the capabilities, most of the things that industrial organizations do with Ignition are accomplished by using modules along with that platform. You can use the Ignition platform to connect with PLCs and databases. But if you wanna capture and display the information from those connections and make it accessible on different devices all over different places, or do other useful things, you'll need to add certain modules to that.

06:23
Don: And what do the modules do? Each Ignition module performs a different, specialized function when you install a module onto the server, the functionality of that module resides on that specific server. Because Ignition supports an unlimited number of modules, you really... That's what gives the flexibility to build just about any architecture. So you can deploy to one site, multiple sites, host it in the cloud, and I think that's one of the main reasons for such rapid adoption is because of that flexibility. There's a whole lot of modules that users can add, but there are two core modules which are particularly important to its ability to build different SCADA architectures, the SQL Bridge module and the Vision module. I guess SQL Bridge has a variety of uses. I'm gonna let Travis comment on a couple of them in a couple of minutes, but the most important one is providing connectivity, Geno PC data and SQL databases.

07:21
Don: The module accomplishes this through its high performance historian, which logs historical data into a database and its transaction groups, which move data bi-directionally between a PLC and the database. If you're writing, you got the Ignition server running and you only have the SQL Bridge module installed on it, you'll have an excellent historian and data logging solution, but you wouldn't have any way to see the data. So Travis, I know the SQL Bridge module has a lot of other capabilities beyond history and data logging. Our CEO likes to call it sort of the Swiss Army Knife for integrators. Can you just talk a little bit about explaining more about how it does that.

08:00
Travis: Sure, yeah, a SQL Bridge module for Ignition is really... The transaction groups are the first thing that we created here at Inductive Automation, it was our first product, and it really is a bidirectional data Bridge between an OPC server and a database, and we can move data back and forth any way that we want. So of course, we can take data from the PLC and log that to the database with the group or the historian, but the groups also have the ability to do rescue management, load things from a database to the PLC, to put real-time values in the database, to have that bidirectional control, to be a sequencer, to create a lot of different logic engines that we could do very easily because of how often we can run the groups and trigger the groups to run and how to do calculations with them. So they're a very powerful part of the Ignition platform, the SQL Bridge module is... When you learn more about it, there's a lot more you... That opens up for you.

08:52
Don: Thanks, Travis. I just wanted to share... Have a little more perspective shown on it, 'cause it's a really powerful tool as far as the modules that come available with the Ignition platform. Now, just a bit on the Vision module. It brings visualizations to the Ignition platform, provides web launch clients, displays historical data, provides windows, components, templates, and of course, design tools for building your projects. Even on selling the Vision module provides tools, a lot of tools you can work with. Actually, we use the Ignition platform in our own company for our own CRM, which really it does is connecting to PLCs at all, so you can make a fun application to a database that has no PLC interactions and make a real-time SAS control screen that interfaces with devices. It can also make graphs, charts and a whole bunch more.

09:39
Don: So if your Ignition platform only has a Vision module and not SQL Bridge however, you could display data but you couldn't log it. So I think in a nutshell, it's a combined power of SQL Bridge and Vision, really those two modules on the server to log visualized data is really what gives the optimum for building customized architectures. No matter what you need to build or how you need to scale it out, Ignition has a practical and sort of cohesive way to do it, which we're going to talk about as we get into deploying these architectures, but I wanna give Travis maybe one more time to just comment 'cause you've worked intensely with both of these modules and the platform, what are some of the things you can do by using these modules in combination?

10:24
Travis: Well, certainly the obvious things are to do a real-time SAS control application, to log history data to a database, the SQL Bridge would log the information, the Vision Module would simply graph and summarize that data and tables, and it'll give you the ability to view that information but you could have a full-on alarming system, you can have a rescue management system, you can do downtime tracking, and there's the sequencer, not only can you see the data, but Vision can actually interact with the groups and tell them to do various things, and the idea is with these two modules, you can achieve 90% of the applications out there. Other modes, we have Ignition, just keep giving some more functionality that are important, but these are two core modules, and as we go through the different architectures today, these modules we'll be focusing quite a bit on, because they are the core. They are the most important ones.

11:14
Don: Great, thanks, Travis. Just to comment on people listening, and I'm still getting a couple of people, most people seem to be fine, but some people are not seeing... They're still not getting audio. I guess you could try phoning in also, 'cause most people are getting the audio right now. If you're still having trouble try phoning in. We will certainly provide a follow-up. There's this one question that says, with the full presentation after we're finished we'll make it available on our site. So let's get into some architectures first on a single Ignition server, given sort of a basic overview of Ignition and two of its core modules, let's take a look at how we might want to deploy it. Standardization architecture is really a single Ignition server installed at a single site. A single server or single side deployment is Ignition and all the components are installed on a single machine, and that is really having it here on this single machine connecting to your PLCs and having our visual clients here, connected to a database. That's sort of your basic, most users begin with that for one site.

12:19
Don: Modules used in a standard architecture, typically Vision, SQL Bridge, reporting, simple fact, alarming notification, the ones just listed here. So bundled together in what is known as the Ignition works package. With that platform, you as a user can connect to all of the PLCs and databases to real-time SAS control, alarming, use premade vector graphics, great professional reports, etcetera. Display optimized data screens and do that all on the same machine. It's actually a pretty simple set-up, it's one server license, and you have to place all those data installation configurations and back up for an entire facility over when you have only one service. It also means you have a single point of failure, it's a good idea to set up a redundant pair of servers so that if the master server fails, the backup server will actually take over.

13:14
Don: Just as a quick note on that, that single server does have that liability of a single point of failure putting redundant pair of servers so that the master... If the master server fails, it kicks over to the backup server. It's what's known as a fault tolerance system and any server you have for Ignition can be fault tolerant. Travis, can you maybe also comment a little bit on the facilities or enterprises that you'd recommend use the single server or single site architecture? And what's the architecture that... I know a lot of customers start with, so your thoughts.

13:49
Travis: Yeah certainly it's the most common architecture having one server for the facility, a lot of other applications out there split up the historian and alarming and reporting and HMS gate and various packages. With Ignition, with it being modular, we can accomplish all that on the same server and so it's perfect for a single facility, a single site to be able to accomplish many of the applications that are out there. But when you do connect to devices over from multiple locations over the WAN is really when you wouldn't wanna use that architecture. You kind of wanna put a server at each of the sites, which we'll talk about some more.

14:24
Don: Good. Thanks Travis. The standard arch of the simulation server, even with that architecture, you can use it for multiple sites. If your organization installed Ignition in a central site and then wanted to use it for two remote sites over here and like other parts of the country, you could certainly do that. Connect all three sites to a corporate wide area network and through that WAN you've got all the connection you need. With that one Ignition server connected to the PLC to the remote site over the WAN, you collect information from all PLCs onto one database here at the central site. Now I'm gonna ask Travis to basically do a little demo to show that standard architecture, maybe I'll just do one little qualifier here on a drawback of the single term of multiple sites, and then pass it over to you, Travis. I guess you could say in a perfect world one Ignition server to connect to many devices as you want no problem. But in the real world, you end up running into problems, and I think there are really two major ones.

15:28
Don: One is losing connection to PLCs or handling extremely large projects which typically demand that you have a server at every location. So the drawback of using one Ignition server for these multiple site solutions is that if the corporate WAN goes down and causes a central server to lose connection to the remote sites, remote sites will lose historical data and visualization. So as is commonly the case, if access to historical data and visualization at those remote sites has to be maintained at all times, it's recommended, obviously, to use an architecture with more than one Ignition server. With that, just as a caveat, let me just kick it over to you, Travis.

16:04
Travis: Right. I just thought I'd do a quick little demonstration, as far as just kind of showing I... Here I have a single Ignition server on one machine at a location. Just to show, I already have it connected to a database, you can connect to one or more databases at the facility and to store historical data or to retrieve information, I also have connected to a couple of different devices here, 'cause the idea is, we can bring in those tags. With the one server, we can connect to as many devices and databases as we want within that facility, we can open up as many clients and designers and of course, we can achieve a lot of different applications from real time SAS control to history and alarming and much much more that's there.

16:52
Travis: A single server is a very simple architecture, it's the most common that we have out there. It's what customers start with, and they can expand and build on that. Now as we get more needs throughout the organisation and as it gets a little bit more complex, it will involve essentially some more servers and we're gonna look at these different ways we can deploy it in that way. But a single server is very, very simple. Here, you can see the modules that are installed or the modules that I can actually configure here and typically that's where you install all of them, the works package, have a server that can do everything there and perform all the functionality that you require.

17:25
Don: One of things I'd also say is that one of things we noticed on that SQL Server solution is as soon as people get that in the main... The number of people inside an organization who want to launch clients who wanna access information, it starts proliferating inside the organization because they don't have to think about anything with the unlimited client licensing model. So let's shift to deploying multiple Ignition servers, wide area SCADA. As you expand your system, and then you're deciding to use Ignition at more than one site, it's best to acknowledge Ignition server and have that Ignition server installed at each of your locations. Some advantages to that obviously, the main advantage to having a server at each site is the remote sites are able to continue performing those essential functions, even when communication to the central server is lost. Using multiple servers also offers a wide degree of flexibility. Depending on the modules you select each Ignition server in the network can perform the exact same functions, or they can each perform different functions. So your organization kind of gets to pick and choose which modules to run in which sites in order to sort of make the whole system the most effective it can be for the needs that you have.

18:33
Don: You can deploy a variety of Ignition architectures that use multiple servers and mobile sites, the most basic is the wide area SCADA architecture. I mentioned that the organizations using wide area SCADA, three sites would have one Ignition server. At each of the sites, all three servers would be connected through a corporate WAN and all three would have the same modules installed and so they have full functionality Ignition application available at every one of those sites. When you're working with a wide area SCADA architecture, at least from the perspective of an operator, Ignition appears as if it were a single cohesive application, even though it's actually distributed across three sites. Through a method that's called client retargeting the operator could quickly switch from one project on one Ignition server to another project on another Ignition server and this makes managing different projects at geographically dispersed sites much simpler, certainly simpler than it used to be.

19:32
Don: But what if your organization decided it should start analyzing data across sites that require the data to be logged not only locally, but centrally. In this case, we advise you to use a variation of the wide area SCADA architecture that includes a central database and the central database is where all three Ignition servers could log data. So data can be logged to both the central and the local database and basically databases do that by adding the tag history splitter modules so you basically log simultaneously putting the data from the PLC, here at the local database at site C and also to the central database. This actually gives you a setup that has the ability to get more insight from your data because you can compare sites to each other on the same trend, you can aggregate data from all the databases into one report. So with that, as a basic introduction to that, I'm gonna turn it over to Travis to do a little demo on that.

20:26
Travis: Alright, so this is a really popular architecture for a company who has multiple sites and they... Of course, each site needs to be independent, they need to run but we wanna see data centrally, at a corporate location, potentially we wanna see what's going on. And so if we look here, I've got two Ignition servers, site one and site two, these two different tabs, these two different IP addresses as you can see here. One is installed at one location, one is installed at the other location and on these, of course we're connected to one or more devices at each of the locations independently, it's connected to down the bottom here on the databases to a local database and to that remote database. So using that splitter, we can mirror data to both at the same time, so both of my sites are doing that. They're logging locally as well as to a remote location. So of course, if I'm at site one and I'm on the plant floor, I wanna look at the the projects for that site, same for site two but there are times where we wanna switch back and forth and go from site one to site two, or look at a graph from both of the sites, and so by having site... A server at each location, doing their work there and being able to centralize that data, we get a complete system there.

21:37
Travis: And so this is just the actual gateway here, the page's showing that I have two Ignition servers with a project on them. But if I look at the actual project itself, here is a simple project showing some real-time SAS control, all history of the tags for that location. So right now I'm at site one, I can see the IP address here and I'm logged in as admin. So with the retarget feature in Ignition, a user could be at any location, or it could be an owner, CEO or plant manager or whatever could go from one project at one location to another project at a different location through retargeting. And that's a way for them to jump around from server to server as if it was one big application, but it's actually distributed. And it uses the same credentials that passes it through and of course the security we have at each location could potentially be different based on who that person is.

22:28
Travis: So if I click on the target to site two, you can see it's gonna simply switch the project over to site two, so without having to go to the webpage and launch a separate client, we can all do... We could do it within that same client. And so after we do it the first time, we cache it, then we can go back and forth very quickly between those two. So here I'm at site two now, I'm looking at slightly different projects, different IP addresses here, same user I'm logged in as and I can go back to site one there. So it's a great way to jump around between these different locations.

23:00
Don: Travis, you mentioned security, but I also noticed a question here. Maybe you can answer the question now 'cause somebody else has probably got, besides just Bernardo. What kind of security or encryption Ignition provides on multi-site data exchange?

23:15
Travis: So currently, each server would be installed at each location and they can be... It's the web servers so they could actually run it on HTTPS or SSL. So you can encrypt the actual gateway and the gateway is gonna send data to a database and that database essentially, you could also encrypt that connection as well so that way nobody can see the data that's going between the different sites. So it does have the ability to encrypt the information and furthermore, you have security built in, so that based on who you are and where you're at, you can lock down what people of course can do in the application.

23:49
Don: Good. Thanks Travis. So let's move on to another architecture here. Organizations that have a large number of remote sites, such as oil and gas companies that operate hundreds of rigs out in the field. Those organizations need to have some reliable and economical means of logging that remote data. For some companies, having a fully fledged Ignition server at every site would be cost prohibitive, and they would need to have some sort of a more economical solution to accomplish what they needed to at those remote sites. The most effective solution for this is hub and spoke, which is a type of multiple server architecture that is ideal for organizations with hundreds or actually even thousands of remote sites. The hub in the hub and spoke architecture of course, it's a central site with an Ignition server that has division and reporting modules.

24:41
Don: The spokes are at the remote sites, some advantages, it's ideal for organizations, like I said, hundreds of thousands of remote sites, historical info from many remote sites, it's collected at a central location and also, as I mentioned, if you need an economic solution this keeps costs down by just using a minimal number of modules at each site in order to accomplish what you needed to accomplish, to handle those essential functions that need to be performed at those sites. So just to look at it, then the basic hub and spoke architecture, each spoke has a data logging computer with Ignition and only the SQL Bridge and OPCUA modules that way the remote side connects to the PLC locally so that data will not be lost when the connection to the central server actually goes down.

25:32
Don: The Ignition store and forward feature on the embedded data logging computers ensures that data is recorded at the remote sites. When the connection to the hub goes down it records when it forwards after the central hub, once again gets connection and it's restored, and then it can forward it to the hub database. Usually the most critical need is for historical data and this basic hub and spoke system takes care of that need for those customers with lots of sites. You can also log data locally and remotely in the hub and spoke architecture by installing a local database and tag history splitter module at each site. So with the tag history splitter module, you're gonna be simultaneously logging to this remote site database here and to the hub database there.

26:23
Don: If you need to maintain local visibility on your projects, that's another question because if you lose Internet connection, it goes down, you have to have that local Ignition client with a limited version of the Vision module at the remote sites in order to maintain that visibility. That way those remote sites can fall back to their local client at a time, if they fall back to a local client, when they lose connection, when the connection to the hub is restored, then of course, they can go back and not be using that local client fallback feature anymore. It's really an economical system for ensuring local visibility here when the connection is lost to the central hub. So you've got history, you've got data logging, and you've got local visibility.

27:06
Don: But what if you also need alarming in the remote sites? You can also add alarming to your architecture by adding the alarm notification module to your remote sites. So obviously, as I mentioned earlier, you're really trying to be economical, but cover whatever those essential functions are that you need to have happening out here at your remote sites. So Travis question to you, maybe just you can comment on your experience on types of enterprises, who would benefit overall from the hub and spoke architecture, and how do you end up in your analysis determining whether they keep fairly limited functionality there, limited in terms of modules and clients, whether they should make more independent from the hub site by adding more functionality like alarming in this case.

27:49
Travis: Well, it really comes down to one simple fact. You have PLCs out there in various locations. Some companies, of course, just have one site. So for them, one Ignition server is gonna be perfect. Some have multiple sites, but they need the full functionality at every site and there's PLCs at each of the sites there. So what's important is to understand at each location where you have PLCs, what's the critical functions that we need to perform. And if the critical function is simply just data logging, then the SQL Bridge module, we can keep that cost way down by just having that one module at each location, we can log data to a central database. But if you also need a critical client or alarming or various things, you start adding more modules to that license at each of the locations where the PLC is. So you always wanna put software close to the PLC. You are mitigating the risk of losing that communication.

28:39
Travis: As we lose communication, obviously, we lose data and lose visibility, that can be a bad thing. So the idea is to where you have PLCs, determine what your critical functions are, and you could put a server with the right modules to handle that. So companies like water, waste water, when you have remote sites, remote tanks and things like that, you know nobody's typically out there, so you may not need a client, but you do need to log data and guarantee that's there. So you just gotta ask yourself the question, "What do I need at that location?" Oil and gas company, same kind of idea. Lots and thousands of remote wells and things that they wanna collect data from, or whether you're just a facility with three different buildings and you have the potential of a forklift driving into your fiber and cutting one of the buildings off, you may want software getting close to the PLCs to figure out what critical functions you want. So it really comes down to the critical functions and making a determination where your PLCs are and what you need.

29:36
Don: That's great. Since I had commented on alarm notification in the last comment here, can you also... I know there's examples, if you have alarm notification, you have it essentially and you lose connectivity, you have the same problem if you need it at remote sites, give an example or two of why you think that alarm notification module should be done at the remote site, not just done centrally.

29:57
Travis: Well, some customers, when you add the alarm notifications to the remote site, you are adding that to every possible site that you want to do alarming at and that could increase the cost of it. So some customers decide, okay, well, I'll just do alarming at the... The notification at the central, and if I lose communication to a remote site, no problem. What I'll do is, I'll just notify somebody that I lost communication and say, "Hey, go out there and... Looking at the data locally." But if that is just simply not a good requirement, if you have to be notified there, and nobody's typically out there, that's when it justifies putting the software at the location.

30:33
Don: Sure.

30:33
Travis: I wish there was a magical solution that would just take care of it without software there, but the idea is, we have to put something close, and what we put out there can be dependent on which modules do you want there.

30:44
Don: Sure.

30:44
Travis: It's a way of determining what you need.

30:46
Don: It's always an analysis to make something work based on what the needs are at that site. Okay, so let's leave it to you for another demo.

30:53
Travis: So I've got one more demo here that shows, I have two spokes here. Spoke one, spoke two, and they are logging data locally and to the remote database. What's important here is that this SQL Bridge module, they are logging data to that remote database and there are sets of tags in each one of those spokes. It's going up to an essential database that we happen to have. Then I have a hub here, and the hub simply just has a Vision module. So the hub has no device communications whatsoever, it's not talking to any devices. It's simply talking to a single database. And by talking to the database, because both of my spokes are logging data into it with that SQL Bridge module, then we can simply just have a project up there centrally where I can look at the database and see I've got two sites of tags. And if I look at the sites, I can see their individual sets of tags for each of the sites, and this is where I can actually start comparing and looking at history from both sites because the spokes are logging the data.

31:50
Travis: So if I took a tag from site one, I took a tag from site two, and I basically started creating a trend of that data, looking at it various times, I can be... I'd be getting the information from multiple locations. So it's a perfect use of the hub and spoke here to have that central visibility of all the data you have in your location, at different locations. And if there was a need to have a local client or local alarming, that would still happen there locally, but this is a great way of getting that central visualization of what you have out there. And so this is just kind of a little template that we include in Ignition to see all the different tags you have, and with having a central system, you have tags all over the place.

32:32
Travis: You may want to store configurations of these tags, so you can come back and look at particular time periods or different combinations of pens that are gonna be very important. So by putting into a central database, you get a lot of power as far as you can see a lot of data in one place. And having unlimited clients there, it means anybody can look at that data, export that, do reports off that information from multiple locations. That's really what's so powerful about the hub and spoke. And you could do the same thing with that wide area SCADA, but the wide area SCADA is every location simply has all modules, 'cause they need all the critical functions, but we can still have central visibility of the historical data and real-time data in a corporate location. It's just really a matter of what critical functions you need in each location there.

33:15
Don: Yeah, if the spokes happen to be in the hub and spoke, these are full different sites with full functionality needed, and that's what you do there. But sometimes you only need just what you talked about, just a store and forward functionality for that. So great, let's go to... That's it on that demo. Let's move now to Ignition in the Cloud or software as a service or SaaS. Certainly Ignition can be used in a hosted environment and used in the Cloud. It's got a certain number of benefits, obviously, of Cloud-based systems and some drawbacks. It's simply very scalable, it's got simple scalability, it's easy to access data, and it definitely has lower IT cost. So how does a Cloud-based Ignition architecture work? Usually the integrator will host Ignition on their own servers or through a Cloud computing service. The integrator would set up two redundant Ignition servers in the Cloud with a firewall and public IP address. The customer's information gets collected in the Cloud, and then the customer can open a run-time client, while, again, and see their screens, reports, trends, any other features provided on the Ignition Cloud server, which is being hosted by that integrator.

34:24
Don: If you look at it though simply, in order to host the customer's information, anybody needs to collect it from the customer's PLCs. Smart way to do this, is to install Ignition with the SQL Bridge module at each customer site, so that the data can be logged to the databases in the central location hosted by the integrator. Another method, obviously, you could connect the Cloud server directly PLCs to a cell tower or satellite or secure VPN, or by pulling, a round robin type pulling, although this method causes significant security concerns for a lot of customers. So that's kind of one of the caveats too. Cloud computing is possible with Ignition, those who deploy that kind of architecture should be careful about what they put in the Cloud. It's best to handle real-time SaaS control data and not do it in the Cloud, so that you don't create the possibility that someone would be able to turn parts of your system on or off from the integrator. You wanna keep that control locally. But let me ask Travis to broaden out a little more advice from his wealth of experience in this area. Any other advice for those who are considering using Ignition in the Cloud?

35:33
Travis: Well, certainly integrators have found this to be a very nice way of hosting a server that they could, customers could pay for our service, keeps the cost down. They don't have to pay for the hardware at the locations, and we can collect that... Typically we wanna know about data, so we want the information there. As we collect data and put it up into the Cloud, and store in the Internet, and then the customer could access that application pretty much anywhere that they want. Effectively, what we're doing here is we're doing a hub and spoke architecture, but we're putting the hub in the Cloud. And whether that Cloud server gets data directly from the PLCs over a secure VPN, which some customers do, or like a satellite or some private network, or it goes and has software at the location that pushes data up to the Cloud, the idea is that we're gonna get that historical data typically, again, not real-time SaaS control data, just information that we can look at and report off of, so we could see what's going on.

36:32
Travis: The Cloud, it's a buzz word, people are talking about it, but certainly for integrators and for some end users who don't have the cost to put a... To buy a license and to pay for the implementation time of their project, and to get hardware at that, they like to pay for our service with some hosting company like some integrator who has chosen to do this. It's an option that's out there, and if we're gonna demo anything, it certainly is... The hub and spoke that I had shown here earlier, happened to have the hub in the Cloud. If all of you guys here on the call today, you typed in this address right now, which is 54.212.96.80:8088, you guys will be able to access this project and you can launch that runtime, that project I show with a little trend, where you can select trend, the data from multiple different sites.

37:24
Travis: So go ahead, feel free. It'll be available for probably an hour after the webinar is there, then we're gonna shut down the servers. They are hosted in Amazon's EC2 Cloud, and we're basically putting... We have spokes that we're logging data up to that central database set-up that's in the Cloud, and we can view that information. So it just gives a sense of how you could put it in the Internet, but again, just be cautious. Use judgment as to what you wanna put up there, and if you are gonna go down that particular route. The idea is that an Ignition server can be anywhere. It could be at the site, it could be in the Cloud, and what you put on that server is a combination of modules, and those modules give you functionalities. So you determine by overall, for enterprise, where you have PLCs and where things are, what are the critical functions again, and that just determines how many servers you have, what's on those servers, and how they're gonna work together in a broader sense. And we are coming out with some new things, I'm gonna talk about in just a few minutes, that are gonna make this type of architecture even more robust and... So anyways, we'll look a little bit more about that.

38:29
Travis: But that's the basic idea with architectures, determining those critical functions, trying to keep it as economical as possible. If you could certainly get... If you had money to get licenses for every location, everybody would do that the full blown license, but when you have thousands of sites, or hundreds of sites, it can be a little bit costly so the idea is to get what you need out of the system, but the price point is gonna work, that still is gonna give you some unlimited nature.

38:55
Don: Sure, and I think overall, if we take a look at just even, what we're trying to do with the Ignition platform and the modules is to... As you can see from these different architecture options, is to give you the flexibility, so that you have the decision-making power for whether you're an international organization, or you're an integrator working with industrial organization customers. You have the flexibility to choose the architecture you need that is unique to that organization's needs. As Travis said, he's gonna talk about as Inductive Automation's customer base expanded more and more globally, and more and more enterprise wide solutions. He's gonna talk a little bit about some of what we're doing to even make that level go easier as that architecture becomes more common for international organizations. But every organization, you have unique needs, the whole idea is to build any architecture from that single data logger to a SCADA network that stretches across thousands of these geographically dispersed sites and almost anything in between.

39:52
Don: The idea is you leverage the modules, and you just use what you need. As Travis was saying, try and keep it as economical as possible to make it work for your organization's not just functionality but also the budget. Just if you're interested, you can download free Whitepaper here and such as we discussed today, go into more detail on scalable SCADA deploying Ignition and the architecture, you can find it ignitionbuild.com along with a lot of other content on SCADA development and deployment. So, Whitepaper is also available at inductiveautomation.com. Always wanna say this, if you're ready to try Ignition for yourself, download the full version for free, you get a two hour runtime, you can develop full projects, you can do a whole lot of opportunities, sort of build any system you want before you even have to purchase it. So now we're gonna move into the Q&A, there's quite a few questions in the queue. We leave ourselves at least 10 minutes at the end to try and get to all those. We're gonna start going through them, I'll just read them off or Travis will read them off either way, and we'll just... You can keep adding, what was the IP address again? So Travis is sharing the IP address again.

41:00
Travis: It's up here, I'm gonna also put it into... I'm gonna reply to your question there, send it to everybody, you should all have that IP address there you can look at for that particular server. Alright, so let's go for...

41:13
Don: Some other questions here. Okay, does Ignition have recommended databases for its users? Tyler's question.

41:20
Travis: Certainly, we can use any standard database that's out there. The big three that we see are MySQL, which is a free Community Edition database, Microsoft SQL Server and Oracle. We see customers use Postgres as well. As far as performance between the three, between all of them, they perform pretty equally, it's about really what you standardize on what your IT department standardizes on what you understand, is what we recommend. The most common two are MySQL and Microsoft SQL Server out there.

41:48
Don: Great, cool. Unix or Windows based?

41:51
Travis: Ignition is cross platform and runs on Windows, Linux, or macOS 10. You can find it in stores and on website for all that both on the server and on the client side.

42:00
Don: Cool. We're just gonna go through these fast. So keep asking them, you got quite a few in the queue here. Is it recommended to use a separate server machine for the databases and gateway?

42:08
Travis: Absolutely, we definitely recommend having a database be on its own machine using its own resources so Ignition can be dedicated to Ignition, and of course, they could talk to each other because it's connection from Ignition to the database is through TCP there. So that's what I've done. All my examples, I had another server that would be for the database there.

42:27
Don: Cool. Next question is, is there a specific reason why the gateway might be dropped, when it might drop out? Is this preventable?

42:35
Travis: The architecture we're talking about here, it's not that the gateway would drop out, it's that the connection between sites would potentially go down if you have a corporate WAN and let's say you lose that internet connection you can't see the other site. If you didn't have any software location, when that happened, you would potentially lose data and visibility to the application. So it's... There's redundancy built into Ignition so if a gateway dropped out, we could have another gateway take over. But outside of that, it's typically communication problems that cause different architectures to be thought of.

43:07
Don: Cool. Thanks, Travis. The next question is, is an Ignition server a VM? How do you update it when a new release comes out?

43:15
Travis: Ignition can be installed on a desktop, a laptop, a high grade server or virtual machine, and the case that I have here I... All my examples I showed you today were installed on Amazon, VMs I have, but certainly it could be VMware, it could be a simple desktop, it could be a high grade server. We do recommend server class machines over desktops and laptops, you can run your entire facility, or you know, a good virtual machine. But if you use virtual machines, one thing to be cautious about is make sure you have resources dedicated as far as CPU and memory. So that you don't potentially overtax your server.

43:51
Don: Okay. So can this architecture be used in real time business situations like financial transactions? With real times or business analytics etcetera?

44:00
Travis: Certainly could, Ignition is HMI SCADA and MES software but it's also much more than that we could use it as a front end to a database, it could be a CRM system, a point of sale system, it can be inventory tracking, could be document storage system, there's a lot of things it could do. These architectures would still be very similar in those kinds of approaches.

44:20
Don: Sure. One thing I will say is I mentioned almost any industry at the beginning here, we are being deployed in a variety of those kinds of industries in that kind of a situation. Next question, what is the highest number of tags that Ignition is scanning and what has been the scan rate?

44:38
Travis: I personally have seen most of the systems... That the average system out there is between 25,000 to 50,000 tags, I've personally seen systems that were quarter million I've seen one system that was a million tags all on a server. The scan rates are gonna be dependent on the protocols you have. Basically, the number of tags is one thing but how often you can get those highs from the PLC is gonna determine what kind of PLCs you have in that protocol. For example, Modbus is just slower than say control logics as far as that protocol. The examples we have most customers are between 25,000 and 50,000 they're commonly... All of them are one second or 10 seconds or somewhere in between there. So that's typical.

45:19
Don: Cool. Alright. Next one is, how much bandwidth do you suggest if we go for multi-server hosted across different sites?

45:28
Travis: Well, so that's a good question. Bandwidth is gonna come into concern when you have Ignition servers at every location, and typically it's gonna be... Everything is gonna be local, so you're not using the bandwidth over the WAN necessarily, if you do have those sites that are logging data to a central database, you could potentially be using some bandwidth and that depends on how much data you wanna transfer over the WAN and how fast you wanna do that. We do have a store and forward system in Ignition that can forward data as soon as it has it or at particular times of day, so we have customers who are at remote sites, they forward it at night time between certain hours, so that they could mitigate the bandwidth during actual business hours, you have control over that as well as when we do open a run time, we try to minimize that bandwidth, make sure that data that's being sent between the client and the server is a simple by exception data as it's needed.

46:20
Don: Okay, next one is on control, can you set different levels of control when you have numerous clients either setting or viewing PLC data?

46:28
Travis: Sure, so the security in Ignition, you have... There's two things you can look at, you can see the roles that are assigned to a user, based on the roles, you can determine what they're allowed to do, if they're just read only, they're allowed to write, and it could be on a per tag, per window, per component, per project basis doesn't quite matter when you're looking at those screens and so you could really control that. You also have the ability to control where they're at, so by the IP address of where they're at, if they're on-site, you may allow them to do the control if they're appropriate people, but if they're over another site, you don't want them to turn something on or off because they're not there and they can't see what's going on, so you can control it quite a few different ways.

47:07
Don: Okay, cool. Could you pre-package into a PC "black box," it could be installed at multiple sites with the standard set of apps, user interfaces and integration hook-ups, drivers for a plug-and-play approach within a client's architecture?

47:26
Travis: Absolutely, and so especially when customers do, integrators do a hosting solution, they will create a black box that they could go and for pushing data up to the cloud, they can send data up there, it's better to send than to pull, then they can just put a box out there... Well, that's part of the service that the customer is paying for monthly, and that has everything to talk to the PLCs and send data up and can be configurable remotely. You could configure what tags and what things are being sent up, because Ignition is web-based, it can be controlled from anywhere if you wanted to do that.

48:02
Don: Cool. So in a single-site scenario, can Ignition software and database server be on the same hardware, and what are your recommendations? You answered that before but separately, maybe a little more expansion on it.

48:12
Travis: I did. I did. I certainly recommend having it on separate machines, however, if you can't do that and you have to have the same hardware, please, just make sure you have quad core or higher. I'd recommend like an A core or 16 core machine and have more memory, the more memory, the better, so 16 gigs or 8 or 16, the ability to give the database and Ignition it's resources so that you can scale. You can allow it to grow with Ignition we're unlimited in nature, unlimited tags, screens, clients, etcetera, however we are limited by the hardware, so the better hardware you get, the more you can scale, the more you can do on application, so the example I gave of a million tags certainly was not on desktop, it was on a very high grade server, a 16 core, 64 gig machine, that could handle that particular load and had a lot of redundancy built into it, so it was a very good piece of hardware.

49:05
Don: Okay, for the hub and spoke architecture, what kind of PC hardware would you recommend for the remote sites for the server, would a rack mountable PC work? Any recommendations?

49:16
Travis: That's a great question. Certainly, you don't have to have a computer that... A lot of times with the hub and spoke, the spokes, nobody sees them anyways, there's no actual monitors out there to view the data, so a rack mounted embedded PC running like Windows 7 or 8 embedded not XP embedded anymore, but 7 or 8 embedded or Linux operating system that of course can install Java 8 and you install Ignition, you could run that. So it can actually be a lower... Because you're just logging data, typically, it could be a dual core, it can be two or four gigs of memory, you could keep the resources being a lot lower because it's not gonna be doing a massive amount of work, 'cause the servers control the entire facility every possible feature, is just typically the history piece of it, now we can keep that down a little bit.

50:06
Don: Sure. We just got time for a couple more questions here. How is the data replicated to a remote site between database servers, what port is it using?

50:16
Travis: In Ignition, we can connect to any database and we could log it to that database, and so we connect over their standard TCP port, so for example, MySql is 3306, and Microsoft and other such different ports, and so what we have in Ignition is the ability to... We have a tag history splitter that mirrors data to two database at the same time, so we're not replicating them, we're just simply putting the data in there, we're not guaranteeing they're exactly synchronized but we are guaranteeing that we put the same data in there twice in both databases, there, of course, databases have techniques to replicate or be redundant as well and be synchronized outside of Ignition, you could do that, but for a simple solution, Ignition has this ability, and we guarantee that data gets in the database.

51:04
Don: Thanks, Travis, last question here. Where can I access that historian... Excuse me, historian template, looks really nice.

51:13
Travis: Yeah, so that historian template I showed you earlier, that is a template that we have in our cloud template system, if you were to go into the Ignition designer and in there, it's all Ignition go to the designer, up on the top on our tools, you'll see a cloud templates browser, you can search for one called ad hoc chart, it is one that I created, it's up there, it basically uses our easy chart component and a couple of other things around it to do some more, and you can just import into your project and put on to window, it's simple as that, and you can just use it right away.

51:44
Don: Great, plus you got a chance to talk about a cloud template, so that's great, for an opportunity for people. I think we came to the end of our time, there are still a number of questions in the queue. I just wanna say thank you for being a very engaged audience today, apparently this topic is of use, so please take advantage of the email that you're gonna get from Travis and sign up for next week's training. And also if you have any other information you want from any of our account executives or Melanie Moniz who's account services manager. If you want a more in-depth demo, you're kind of new to Ignition, please give us a call, we will follow up and make sure we do it, we're also gonna follow up on the questions to get answered for you that are in the queue, 'cause there were quite a few we weren't just able to get to in the hour that we had today, with that I think we're finished with today's webinar, I wanna thank everyone of your attendance and have a great rest of your day.