Design Like a Pro: Essential Steps for Enterprise Architectures

About this Webinar

Before the rise of IIoT (a.k.a. Industry 4.0), it was normal for industrial organizations with multiple plants to treat each plant separately. Now there's a growing demand to see and analyze data from all of the plants at the corporate level. How can organizations begin developing enterprise-wide architectures that provide useful data and are easily manageable? It starts with a shift in the way many companies think about industrial architecture.

In this Design Like a Pro webinar, system-architecture expert Travis Cox presents concepts to help you build a solid framework for a future-proof, enterprise-wide system from the plant up.

Learn more about:

• Best practices for scalability, reliability, and security at the plant level
• Increasing data access by decoupling systems from devices
• Integration with tools for business intelligence, machine learning, ERP, and more
• Enterprise analysis and management
• Developing standards across the enterprise
• Expanding your system while keeping costs down

Webinar Transcript

00:00
Don: Hello, welcome to our webinar today, Design Like a Pro: Essential Steps for Enterprise Architectures, building the framework for an open and scalable multi-site system. Thanks so much for joining us today. My name is Don Pearson with Inductive Automation, and I'll serve as the moderator for today's webinar, and in a couple of minutes, I'll introduce the presenter for today's webinar. On the agenda, we'll introduce you to Inductive Automation and the Ignition software platform, then I'll introduce our presenter, who'll discuss enterprise architectures. Specifically, he's gonna talk about why we should shift from thinking about plants to thinking about the enterprise, about using open standards and open architecture, about the results you can get once you've got this type of system in place. He'll also tell you about an available solution for accomplishing those kinds of architecture evolutions now. Just a little bit of company background, Inductive Automation was founded in 2003. We certainly have been extremely pleased that enterprises in now over 100 countries have chosen Ignition for their HMI, SCADA, MES and IIoT needs. We have over 1500 integrators who've joined the integrator program. Ignition is used and it's trusted by thousands of companies, including 44% of Fortune 100 and 26% of the Fortune 500 companies.

01:20
Don: If you want more information just on Inductive Automation overall, please go to our website, inductiveautomation.com, and About Us section, and you can take a look at that and there's case studies to look at, and you can really get yourself educated on the company should you have an interest in that. The platform Ignition is used by leading companies really across almost every industry you can possibly think of, from oil and gas, water and wastewater, food and beverage, government, transportation, packaging, and the list really just goes on and on of where people have found the application for our platform. There's a lot of reasons for that, I'm just gonna leave you with a few bullet points, then turn it over to Travis. Our signature product is Ignition, it's really the world's first truly universal industrial application platform for HMI, SCADA, MES and of course, IIoT. A lot of reasons for that. One clearly is it has an unlimited licensing model, no limitation on tags, clients device connections, concurrent designers, projects, whatever.

02:24
Don: Cross-platform compatibility based on IT standard technologies with a scalable server client architecture, it's web-based, it's web managed. We have launched Designer and Clients, and the modular configurability allows you to start wherever you start and grow your system, scaling both horizontally and vertically across your enterprise. And it's really a rapid development and deployment tool to accomplish any task you may want across that enterprise. Those are sort of little just bullet points, like I said, you can go to the website if you want more information. I think what we best do now is get started 'cause there's a lot to cover today. Presenter today is Travis Cox. He's Co-Director of Sales Engineering at Inductive Automation. He's been with the company from very, very early days and has really made great contributions in training, support and sales, lots of experience in assisting companies with this type of architectural scale-outs that we're gonna be talking about today. So I think that's enough introduction, Travis. Throwing it over to you.

03:28
Travis: Alright, thank you, Don. Well, welcome everybody to the webinar today. Today we're talking about enterprise architecture. It's a relatively new concept, but everyone's heard of smart factories, industry 4.0 or the Industrial Internet of Things. Industrial organization is basically a tree to each of their plants separately. Every plant did its own thing, each had different data, different PLCs, different software, different budgets, and so on. I can't tell you how many sites or companies that I've walked into where I've seen completely different implementations across each site, where they just treated each site completely separate. Most companies didn't even realize that they didn't really have a way of getting data back to the corporate level, so they can look at it or analyze it. But since the concepts of industry 4.0 and IIoT have swept through manufacturing, there's been a big demand at the corporate level to get more data from the plant operations and to convert that data into actionable information.

04:26
Travis: Now, the corporate wants the ability to see and analyze all that data at the top. Just think of the possibilities. The company could save millions of dollars, make better decisions, manage things centrally and go into new areas like machine learning, business intelligence, predictive analytics and more. That would be great, but needless to say, this is no small task. This presents lots of big challenges and questions, like, how do we get from the current landscape where every plant is different to the promise of turning data into real information, analytics and central administration. Where do we start? How do we go about getting the data into common format or standard, and where does that work take place? How will we manage it? Will it be manageable or it'll be harder to manage than what we have now? How will we handle the increased quantities of new data coming in, how can we plan for that?

05:17
Travis: How can we scale this? And of course, there are many other questions that this brings up. To get more data, to do more with it and to turn it into actual information, we need to take a different approach than in the past, and ultimately we need to use a different architecture to connect it all together. To meet these new demands, we need to aggregate data up. Specifically, we need an automated process for delivering information from the site to the corporate level. You don't want manually entered data, we need to get the data from our systems and send it in an accurate, standardized, efficient and secure fashion. Companies have started to do this, or at least they're trying. The problem is that they're trying to attack it from the top down, there's a paradox here. The demand for a centralized enterprise system architecture is coming from the top down, but it can't be built from the top down. It has to be built from the bottom up. Think about it, have you ever seen a construction crew building a house from the roof down? No, you can't build anything good without having a strong foundation.

06:20
Travis: To have a centralized system where you can gather up all this plant data and to do all of these great things with it, you need architecture underneath to support it. In most companies now, there's a gap down at the plant level. At the top, they might assume that operations has all of this data, and you can get it to them without any problem, but they may not have thought about where the data is actually coming from or who's verifying it. It's gonna require some careful planning and some investments of time and money to build the right way, but as we'll show you, it's worth it.

06:52
Travis: We need to start shifting our thinking. We need to stop thinking of the plant as an island unto itself. We need to look at the plant as part of a larger corporate system. Think of your plants as the foundations or pillars of your enterprise architecture. When you think of it that way, it doesn't make sense anymore to have different standards and different ways of transporting the data. We should ask ourselves, "What do we need at the plant level to support the enterprise?" One thing we definitely need at the plants are best practices for security. We need to make sure that data is encrypted and otherwise secured when it is shared across sites.

07:26
Travis: One of the big issues here are the PLCs. PLCs are a big source of data, arguably the number one source of data, so we have to be able to get their data into an open format. At the same time, we need to keep our PLCs secure. We can do that by keeping them behind a secure layer that translates the data into a standard format. We'll talk about this more later through the use of edge gateways. One security measure that a lot of companies still use is air gapping, which basically meant keeping secured networks physically isolated from unsecured networks, but we can't have air gaps between OT and IT anymore. In order to get data to the business, we need to converge these two worlds. We need a balance between the need for security and the business's need for data. We need to get data up to a central system in an open format in a way that doesn't compromise our operations by allowing bad actors to cause harm. Fortunately, these technologies exist today to effectively get data from the plant floor up while keeping it safe and secure. Again, we'll talk about more approaches here later.

08:32
Travis: Now, let's shift gears to talk about standards in open architecture. One of the major things that we need to do to get a system with central visualization and administration is to use an approach of open standards in open architecture. End users in the industry recognize the need for open standards in architecture, and a number of them have started an open process automation group or standards body to confront this issue. However, there are existing technologies that we can use to solve these problems. Let's talk about standardization first. Without standards, the architecture is complicated and intertwined. It's all one-to-one communication. With standards, it's cleaner, it reduces the complexity and makes the systems a lot easier to upgrade, especially with some type of middleware. You can upgrade or swap out any part of your architecture quite easily, as long as you make sure the middleware is functioning the same.

09:25
Travis: So we need to start developing standards across our entire enterprise. So what are some common open standards? Well, there's OPC UA and MQTT, which are primarily about getting data from devices, and on the IT side, you have SQL for working with SQL databases and APIs either SOAP or REST, for integrating with other systems. We're not here to recommend one in particular today, but it's important to choose an open standard that is universally known and widely adopted. Different plants have different PLCs, different tags and addressing schemes. To bring all of that into a system where we can standardize, you must use a protocol that's open source and that's supported by a lot of applications. You really cannot achieve interoperability without using an open standard that's widely known and adopted. I'm not saying here that we need more standards. There's already a whole bunch of them, alright, in the world, especially from the device level.

10:20
Travis: What we really need to do is just choose one or two that are really well established. Today we're seeing a mass of companies going to these standards as a model for their data, and we should do that likewise. You are also seeing from the vendor perspective, companies like Inductive Automation as well as hardware companies who are using these standards. There's companies like MOXA, and BMB, Smart Works, Hilscher, ALEXUS, Bedrock Automation, Siemens, Opto 22, who all see these standards as being very important from the device level, and then moving that way up through the enterprise. So once you choose an open standard, you can standardize their data models. That way when you can send data from different plants up to corporate, it will all look the same because you're translating it down to the plants using an open approach.

11:11
Travis: It sounds simple enough, right? Nevertheless, many companies have taken the opposite approach. They try to build enterprise solutions that gather different looking data from different sites, and then do all that translation up at the top. That creates more work at the top before we can do anything with that data. Instead, you should translate it close to the source. If you choose your standards and stick with them as you grow the enterprise, when you open a new plant, its data will immediately fit in with the data from other plants. Again, build from the bottom up, translate your data at the plants, and then send it up.

11:46
Travis: I have a pretty good example of this with a customer that I'm working with, and they have many, many sites across the US, and their first approach was to just simply get data collection at the enterprise level, and what they did is they developed a schema, a standard that they want the data to come into at the central location, then all they had to do was go down to each of the plants and figure out how to translate the data at those levels and bring it up to this standardized approach at central, and they were able to then do cross-site analysis, and really understand what's going on across their plants at a central level. And it's really the data model here that's important to get correct.

12:33
Travis: Another reason that we use an open source standard supportive protocol is that it allows plants to be a single source of truth of their data. The plants can translate their data into a standard model and send it to the enterprise solution without having to know the true differences down at the plant. And as we know, every plant is completely different, and this basically means that everyone sees and uses the same data for making business decisions. When you have data silos, it's hard to get a single point of database truth throughout the organization, but when everyone is using the same data, you can make better decisions, you can save lots of man hours, and you can reduce potential errors.

13:09
Travis: Now, let's talk about the open architecture approach. As I said earlier, the amount of incoming data is increasing with time, so we need to think about how to set up our systems to be ready. We also need to think about how we can enable the enterprise to do what it does without stifling innovation to plants, or without interrupting the operations system. This calls for an open architecture, and that means decoupling applications from devices, and you'll hear us talk about decoupling a lot. So what does decoupling actually mean? Well, if you look at these diagrams here, on the left, you see a conventional system architecture where you've got intelligent devices such as PLCs, coupled to applications through their proprietary protocols. It's a tangled web where any application can interact with any device. Now, commonly, SCADA is the one that is typically talking to these PLCs, and SCADA is the one that has the data.

14:11
Travis: But if you look at a decoupled architecture as seen on the right, we don't have applications connected to the devices. Instead, devices are connected to the infrastructure. We've got middleware here. In this case, we're talking about MQTT. So there's an MQTT broker or server there in the middle that can be either on-premise or in the cloud. This is an example of a publish subscribe protocol. Here we're talking about MQTT, which is a widely known open source data transport. So to explain a little bit, we have our devices that are going to publish data by exception up to that central broker. Then we have all the applications who are gonna subscribe. As you can see here, SCADA is one of the applications that can subscribe, but since we're using an open approach, we can have many other applications like ERP or MES or maintenance management systems or business intelligence systems that can also get access to that same data.

15:11
Travis: So by using the pub/sub methodology, we can get more data to more applications. Note that SCADA here is not being used as middleware. That's not what SCADA was made for, and we need to get away from that. I see far too many companies who will look at the left-hand architecture here, where SCADA is the one talking to the PLCs because of course it has the protocols to talk, and in the IT world, OPC UA is not a very well-known standard. So we see that they've basically tried to turn SCADA into the system that delivers data to the IT world, whether that's through a database, or whether that's through having, putting a lot of scripting in the solution, writing to files, whatever it might be. We've gotta get away from that approach because if we need to get access to more data, then we're gonna essentially have to continue going down to the operations level and requiring that from the SCADA systems, and we need to get away from that.

16:06
Travis: So you gotta think of another way. How many times do I need to translate data until it gets to its final destination? With the decoupled architecture, there's simply no translation. The single source of truth of data is delivered to all the applications that are interested. So we can't get the type of architecture that we need using a traditional poll response protocol. Coupled architectures are hard to keep secure and to maintain. They take up a lot of bandwidth, you can't innovate if you have your system talking to all the PLCs, you're not able to expand other systems, and it's very difficult to scale an architecture where you're polling for data by directly connecting to devices. So we need to move to a publish/subscribe protocol. By using pub/sub, we'll be able to update data more quickly, and significantly increase the amount of data that we can monitor and control. Now, earlier, the two protocols I mentioned, MQTT and OPC UA, MQTT is natively pub/sub, OPC UA has also developed a pub/sub version of it because we see the need for this kind of architecture. And really roughly 90% of data is actually spread in field. So by decoupling, we can get that data and turn it into information.

17:23
Travis: You can think of decoupling as being like putting your data into a buffet, and all these various systems and tools can take advantage of the data they want. Many applications can access and work with the same data. The data doesn't have to be tied to just one application. The SCADA system can get access to the data, and you can try and do different things like getting data to business applications such as your ERP. With a decoupled architecture, here's one of the big advantages: You can bring on new technology and new applications, and get access to the real production data, and if it doesn't work out, we can simply disconnect and we would not have affected any of the existing systems. That shifts us away from having to think about how to make programs integrate with each other while letting them have access to the data directly.

18:11
Travis: And there's a really good story here of an oil and gas customer who has started with this architecture, has transitioned to this architecture, and by doing so, they can bring on new versions of any application in parallel with the existing versions, and they can completely test against the real production data, and if everything looks good, they can simply just switch over immediately. There would be no need for a cut over in this case. Where we would have to worry about cutting over, seeing if it worked and if it didn't work, go back to the old system, we can verify both of them in parallel because we can actually get access to the same data on both systems. It is a very important approach, especially when you want to upgrade any piece of that architecture. The decoupled approach gives you that ability.

19:03
Travis: Another major benefit of having an open architecture is plug-and-play functionality. And this is really what we wanna go to. This is the true promise of IIoT, is to be able to plug in a new device, a PLC, or a sensor and have it automatically be a part of the network. Just think about it. When you plug it in, you just want it to work. You don't wanna have to go and configure it in SCADA and other applications that you have. It's a lot of tedious work if I have to go to 10 different places just to bring on new information. You want to instantly be a member of the architecture.

19:37
Travis: When you're choosing a protocol as your model, you want one that has security built into it, and there's a couple of really important things here we have to look for. So, for example, MQTT and OPC UA, the two that I've mentioned here, both have encryption and that protects sensitive information over networks by encrypting it. Also, make sure your protocol has stateful awareness, which is the notion of knowing whether or not you are connected to the device. There's a lot of other protocols out there in the world that do not have stateful awareness, and for SCADA, in our operations world, we have to be able to know if we can trust that IO on the screen. Well, we should be able to have that same protocol or have a stateful awareness that can also deliver data to other applications in the business, having the best of both worlds. So with these two things, encryption and stateful awareness, you can provide the data that the business is asking for in a standardized way without compromising how we run SCADA and operations. In fact, you'll be supplying a superior operation solution, because it's a lot less complex, and both OPC UA and MQTT here have a security and stateful awareness, and they do exist today.

20:50
Travis: Another important reason we need to open standards in architecture is that a lot of companies are brownfield. They already have multiple locations that are probably all different. In order to take what we already have and build a real enterprise solution on it, we need to standardize our data and our data models, as I mentioned. The reality is that it will require some financial investments to put tools in at the plant level that can convert the data to a known interoperable format, but the ROI is great, which we'll talk about here in a few minutes. This is a sticking point for a lot of companies. We look at the business from the top down, and we have money there at the top for IIoT and for doing analytics, but we completely ignore where the data is actually coming from. So we gotta put the financial investment down at the plant level. When we do that, we can actually then implement the systems we want at the enterprise level, and that's where we start seeing the ROI. So you gotta look at it from a different perspective.

21:49
Travis: It's also important to acknowledge that no one solution is gonna do everything that we need. I know, we tried. We want that one beautiful solution that's got everything on a screen and everything that could... It could do everything for us, but that's just not how the world is today. We want to have the best in the class for everything. I want to use best-in-class for SCADA, I wanna use best-in-class for intelligence, I wanna use best-in-class for machine learning, and there are lots and lots of tools out there today that we can start taking advantage of. So it's vital that we integrate with other tools for these things. And you can see some of the things I mentioned on the screen.

22:26
Travis: So here's a mental exercise. Think about what you have in your plant right now, is it possible for you to take advantage of these other tools I have listed here, with the solutions and architecture that you have right now? Can you integrate with these kinds of tools, and what kind of work would it be if you have to integrate? Is it gonna be seamless, or is it gonna be completely painful and gonna cost you more money than you really want? So I would suggest that going forward, you buy solutions that are already interoperable, and this typically comes down to the data formats and the standards, and using standard data formats like MQTT to be able to move data around from application to application.

23:12
Don: Travis, can I interject a question here? I just wanna... I can't help but think as you're going through, you put a whole solid foundation on open architectures and the need for standards and how to approach it, but I don't wanna skip quickly over the brownfield point you mentioned just before, because if you think about brownfield companies, and how they should start thinking of the plant as part of the enterprise and build the future with that future in mind, but they already have these plants, and they have... And that's what most of the work is, is brownfield, they're not starting from scratch. So I'm sure some people are wondering, "This all sounds great, but how in the heck do I get... Actually get started?" I know you do this every day, you're talking architecture, you're talking migration strategies with our customers, but can you dig in a little bit, maybe share an example or two of how the heck could somebody really start in the real world on this kind of migration or transformation?

24:04
Travis: Absolutely. I mean, I think it's a great question here, and when you look at this, there's lots of legacy equipment in PLCs, all have their different protocols, and we've had to work with this in the world of SCADA for a long time. And so OPC UA, we have OPC UA servers, we can get data to our SCADA system, and SCADA system has a lot of device drivers built into them. Well, that's connecting directly to the devices. So like I said, we had to get the devices to be a part of the infrastructure. So really what it comes down to is investment of hardware and then getting what it's called an edge gateway, an edge gateway that you put right next to the PLCs. They talk to the PLCs through the proprietary protocol, right there, and that's the firewall, if you will, that's that secure layer I'm talking about. Behind that edge gateway is the PLC. You cannot get to the PLC directly, because it's behind that edge gateway. In fact, the edge gateway there, because it's pulling the PLC, will publish the data up to the infrastructure where we can get that information to applications, and that's secure.

25:05
Travis: So these edge gateways exist and we would need to put them down to plant level to be able to get that data into a middleware, to the infrastructure that we can work with. We're gonna do that at the same exact time in parallel with the SCADA that are talking directly to the PLCs, and then eventually, we can get to a situation where we can start transitioning over and all being a member of that architecture. Like I said, investment's important here because you have to get that hardware. I'll show you an architecture diagram pretty soon, Don, where we can actually see a picture of what that looks like.

25:40
Don: So I don't wanna push too much, but I wanna push just one step further here, 'cause I can't help but thinking that some people listening to this may be just a little bit skeptical about the scope and the problem you're talking about solving here. So it's fine for real-time data coming from PLCs. Then how about you start getting to the MES, like you start going up to the enterprise, you're gonna be blending historical data and real-time data and it's not as simple as it sounds. How do you reconcile that notion of building from the bottom up, the edge, like you're describing here, and blend that data found in all different types of layers all the way up to the ERP enterprise level?

26:20
Travis: You're absolutely right. There is a lot of different kinds of data out there. There's the real-time data from the PLCs, there's historical data in the sense of OEE data or downtime data or just production information. Whatever that information might be, the main, important thing here is that we are at the plant level doing the translation and putting it into an open standard format, and we're delivering that through a standard way. So whether we use SQL databases and have a standardized format at the corporate level, whether we're using web services, SOAP or REST-based APIs, there's gotta be some way that we can easily get this information from the plant to essential systems. Now, I'm not saying there's no work involved here, but with MQTT, as far as the real-time data at the plant level, we can deliver real-time data anywhere and have that information. You could also deliver historical data through MQTT as an option, but when you have applications out at the plant level, they can be publishing historical data as well, just like we'd be publishing the real-time data, again through a centralized standardized format.

27:28
Travis: And that's important. If I was to go into any customer's infrastructure, that's how we would start, is start looking at what the commonalities are across the plants. What's our first win? What kind of data could we get up there that's gonna make the most sense? And then it'll start evolving as you...

27:44
Don: You can build, step by step, from there. Anyway, thanks for taking time to comment on those couple of points. I think they're critical, so thanks.

27:50
Travis: They are critical. And we're gonna show an architecture diagram here very soon when we talk about the solution. So, so far, we've talked about what you need to build a solid enterprise architecture. Now, let's talk about what you'll have when it's all in place. You'll have a beautiful perch for central administration, you'll be able to look down and check on performance at your different plants, you'll be able to manage projects and templates centrally and push them out to your sites. If you see a good idea at one of your plants, you can decide you can roll it out to other plants. You should be able to do roll-outs from a central place if you built it the right way. You could centrally automate backup and recovery, and centrally coordinate many of your administrative tasks. You can handle deployments, project synchronization and updates centrally. You'll have more information and intelligence. If you want to go into new avenues like machine learning and predictive analytics, you can now approach them because you've got an architecture that supports it. You could not have done that before.

28:49
Travis: All of this will increase your speed. You'll be able to make decisions faster, you'll be able to upgrade things quicker and upgrade pieces of your architecture, which will make you more agile and it'll be able to make you improve your process. A lot of benefits here. Like I said, it's not easy to get here. So there's a road, but once you do get to that kind of architecture, there's huge results. So we mentioned ROI a few times. Every company is gonna be different, so it's hard for us to give a meaningful estimate of what your ROI would be, but you gotta think about ROI when you look at doing this kind of approach. You'll have a much better idea of what your ROI would be if you just think about simple questions like: What would be the return for your company if you can get all of that data from different locations into a standardized format centrally to start leveraging the new tools for things like business intelligence and machine learning? What the enterprise, what the actual business needs and what they're asking for today, what would the ROI be? Especially if we can deliver that automatically and we can have them verified from the source. I'm sure the benefits will be very significant. We're talking about thousands of hours and dollars saved, at the very least.

30:03
Travis: Another thing to consider is that you're probably already doing something like this on the IT front. You probably have a corporate front-end business system like SAP, and SAP gets rolled out everywhere. Essentially you'd be doing the same thing from an operations standpoint, but in order to get there, you've gotta build it from the ground up, you can't do it from the top down 'cause it's simply not gonna work. And if you look at, in my humble opinion, especially in the manufacturing sector, if you look at the supply and demand chains, very complicated, the idea of getting more data so we can understand what we have to optimize the process even more and deliver data to our supply chain or to our demand chain. The companies that do this are the ones that are gonna crush. They're gonna win, and they're gonna crush all the little guys because they're not taking investment to go into this kind of architecture.

30:53
Travis: So to get there, you have to seek out software that is made to do things that we've discussed. So, does it support open data formats, can it be deployed effectively at multiple sites, can it connect and leverage the cloud? Which is increasingly important here. Also, you need to scrutinize the software licensing. You don't want to get into software that you can't expand because of licensing restrictions. If a corporation says that they want to achieve and do something new like X, Y, Z, and I have to buy more licenses for that location to be able to do it, then I've doomed myself. Lazy software licensing is an impediment to this. You need scalable licensing as well as scalable hardware and software. Remember that you're not just building for today, you've got to build for the future. There's an investment to get to the new architecture, but once it's in place, you'll have a lot of benefits.

31:45
Travis: Now, Inductive Automation is a leader in enterprise architectures. Our ignition software is built for interoperability, it leverages these standard protocols, MQTT and OPC UA, and it leverages open source standards like SQL databases and web services. The current version of Ignition, version 7.9, has distributed services through its gateway network. This gateway network is a secure high-performance network that allows multiple ignition gateways to share large amounts of information with each other. The distributed services allow you to provide tags, history and alarms remotely and centrally, and that really facilitates new architectures and horizontal scale outs.

32:22
Travis: Now, if you look at this diagram, here we're actually getting to the nuts and bolts of what we're talking about with the edge gateways and how this can be brought into a central system. So this really shows how to leverage MQTT and where you can have Ignition centrally, but you can also have Ignition out at the edge of the network. So if you look at this diagram here, at the very edge where the PLCs are, here are the edge gateways that we're talking about putting in front. Now, we have a software product called Ignition Edge MQTT, which can be input and installed on an embedded PC that can pull the PLCs locally and publish that data up to the infrastructure. There's also hardware out there. Companies like Moxa, and BMB, Smart Works, Hilscher, ALEXUS, Opto 22, E1, and many more have the ability to publish data from their devices into middleware as well. And that's the piece that we have to get out to the PLCs.

33:17
Travis: Then, once it gets into the middleware, we can have applications that can subscribe to that data. Whether it's real-time or historical data, it doesn't matter. So with Ignition here centrally, we could subscribe and look at all the information, but the business systems can do the same thing. So with Ignition, we can actually fit really any part of the architecture. Whether you need to supply data to the infrastructure, or whether you need to consume the data from the infrastructure, we have the tools that's necessary to get the data into these standardized formats, and that's a really important thing is making sure that we're actually moving to that kind of architecture.

33:55
Travis: So, this architecture here really has everything we've talked about: Open standards helps setup protocol, security, interoperability, plug and play, and the free flow of data. Now, from a cost ROI standpoint, Ignition's unlimited licensing minimizes the costs of growth and of future-proofing. Every Ignition server and license includes unlimited clients and tags. This gives you the freedom to add as many clients, screens, tags, connections, and devices as you need. I know I might be sounding a broken record, we've talked about this a lot, but it's completely vital with this kind of architecture.

34:28
Don: When you think about it, Travis, the scale people are talking about here, we're talking about potentially on this kind of enterprise, millions of sensors, thousands, if not tens of thousands of PLCs, RTUs. There is no possible way that you can scale and have a project ever get through the CFO's pending basket. These projects with traditional licensing models will simply get buried in finance and never see the light of day for a migration strategy like you're describing.

34:56
Travis: And I would be remiss if I didn't talk about being realistic. Unlimited licensing model, Ignition, there are some limitations as far as hardware. So one server could not just get at 18 million tags. So realistically, we might have to add some more servers as the demand and as we have more information, but Ignition minimizes that cost because it's licensed by that server, and it is unlimited, it's not buy everything else. So in the long run, you're paying a lot less and it's a lot more interoperable because of course it's using open standards. So that's an important thing to mention here. With Ignition, it's scalable on both fronts, as well as it's using open standards to get into data systems, other systems, and you need that with any system you're talking about, whether it's SCADA or whether it's business systems as well.

35:50
Travis: So let's end by recapping the main points here, the big picture steps towards an effective enterprise architecture. Don't try to build from the top down, build your enterprise architecture from the plant level up. So crucial here. Deliver plant data to the corporate level in an automated, standardized and secure manner. Choose open standards and standardize your data format. Importantly, standardize your data format. Decouple devices from applications using publish/subscribe protocols. Realize that there will be some expense along the way but the ROI will more than make up for it. Integrate innovative tools for intelligence, analysis, IIoT and more. Again, leverage these different systems like Microsoft Azure and IBM Watson IoT and Amazon AWS systems, because there's a lot that we can benefit from, as well as other business intelligence tools that are out there. Use software that is conducive to enterprise architectures, both from the technology standpoint and a licensing standpoint. So really, thank you guys, for watching. We're gonna get into the Q&A here pretty soon. I'm already seeing some questions coming in, so I will start looking at those, but Don, back over to you right now.

37:03
Don: Thanks, Travis. Yeah, Travis will look at the questions. We'll get to as many as we can, as I said. I just wanna mention, first off, anybody who wants to check out Ignition, you can download it, full Ignition platform, at inductiveautomation.com. It downloads in just three minutes. You can use it in trial mode for as long as you want for free, which allows you to really... The designer never times out, so you can actually design an entire system to see if it's gonna meet your needs, and take a look at some of the points that were made today. You can clearly tell, I think, that based on the work that Travis and the team in sales engineering, and the team at Inductive Automation have done, we've become more and more and more committed to the fact that this architectural transformation is vital, the decoupling of devices from applications is critical, and you have to build from the top up and you have to deliver a superior operations technology, or it's simply not gonna go anywhere.

37:57
Don: Incidentally, for those of you who are joining us for the first time on Design Like a Pro series, we've been doing this for quite a while. We offer more Design Like a Pro webinars and white papers. They're all on our website. Design Like a Pro, it's really all about providing fundamental ideas, the tips, the practices, to just help you build the best systems you can for your HMIs, SCADA, MES, and your IIoT projects. If you want a personalized demo, if you wanted to take a look deeper at 7.9 and some of the functionality, at the edge for Ignition Edge products, please call us. These are numbers you can reach from our director of sales to the account executives, and in keeping up with what's new. We'd also encourage you to go to inductiveautomation.com and to sign up for our free weekly newsfeed email. Now it's time to get into the Q&A. Travis had the time to look through some of the questions. How do you manage communication from SCADA to PLC, push from SCADA in a decoupled architecture?

38:57
Travis: So that's a really good question, right? In traditional poll responses, SCADA is literally making connections to the PLC and sending information to get information back up, polling that PLC on a frequent basis. With a publish/subscribe protocol, the actual device or the edge gateway is publishing data up by exception, so there's no connection down, the information is going up and going into middleware. Now, of course, Ignition is subscribing to that through MQTT, but MQTT is also bi-directional. Of course, we can write back by publishing an outbound topic that does end up going down to PLC, but you're not having to make any connections open down. So if you want, for example, to leverage the cloud and put real-time data in the cloud, you could have an edge gateway publish data to the cloud through MQTT and can have complete SCADA in the cloud that is certainly secure because MQTT has TLS security. There might be a lot of people that are afraid of going to the cloud, but the important thing here is how the actual protocol works and the direction, it's going outbound only, and it's by exception.

40:03
Don: Thanks, Travis. Next question here is... Here's a question from Anton. Will Ignition support/implement the OPC UA Pub/Sub extension? If so, when can we expect it? This is Anton from Slovenia would like to know the answer to that.

40:21
Travis: Anton, absolutely, we're working on that. We are working with the OPC Foundation right now, as well as working with MQTT and OPC UA, trying to make sure all of that is covered and working well and similar in architecture. So you can expect that very soon when we have that all worked out. We're still in the talks with them right now.

40:40
Don: Great, I'm gonna go fast 'cause we've got a lot of questions, Travis, and we'll get to as many as we can. How many of the mainstream devices, Rockwell, Siemens, Schneider are supporting MQTT? Steven wants to know.

40:52
Travis: So not too many at this point. Siemens, as a lot of you probably know, have moved into OPC UA, which is great, and we can translate OPC UA to MQTT very, very easily as well as we do have the edge gateways that poll these native PLCs. Now going forward, I think that Opto 22 is moving this in direction as well as B+B Smartworx part of Advantech with their new sensors will have MQTT on board. Maxwell will have it on board. So we're gonna start seeing more vendors. When you look at Maxwell and Opto 22, two of the bigger players, I think it's gonna force the even bigger players to switch as well. I think Siemens is gonna be really one of the next probably 'cause they're usually on the cutting edge of the innovation.

41:39
Don: Good, thanks. Next question here is from Karen. She says, "Do you have an example of a customer using Ignition HMI through MQTT down to a PLC? What type of performance differences do you see? Is it faster/slower than traditional poll response methods?"

41:57
Travis: It's a fantastic question. And we do have lots of customers who are using MQTT and down to PLC and, of course, Ignition as the HMI. We're able to get at more data because if we're doing poll response, there's only so much that we can pull at any given second to the PLC. If I want to add 10 more tags to it or 100 more tags to it, can I poll the PLC fast enough to retrieve all that information? A lot of times the answer is no. Here with the edge gateway publishing data up by exception or the device publishing data by exception, we can get a lot more data, plus it can be just as fast, if not faster than the poll response because we're not having to send a lot of this extraneous information over the network there.

42:43
Don: I wanna add on that because we had some folks speak at a conference we did in Calgary last year from Plains Midstream on a project they did. And with traditional poll responses, they were talking about poll responses on their pipeline that were 15 minutes or more to complete their whole poll response circuit. They did it with MQTT and Ignition. They were able to move that project down to sub 15-second response times. I don't know if they added more data or the same data. Really was talking about the same kind of data that they were getting before, but they were able to take it down by 98%. That's one example I know about 'cause the project managers on that told us those were the numbers that they got.

43:23
Travis: In that particular case, of course, was over a radio and telemetry network initially, and then they had the edge gateway publish data up to the central through cellular or through some other mechanism. Again, we're moving the polling. In a manufacturing plant level where we don't have to worry about latency over the network, we have a fiber network internally, we still see a lot of benefits here of using this decoupled architecture using MQTT, and we can get that data very, very quickly. MQTT is just low bandwidth that's published by exception. We can do a lot more than we could before.

43:53 Don: Sure, you're right. It's totally different from field devices spread over...

43:56 Travis: I just wanna make sure people realize that in both scenarios, it's a perfect solution.

44:00 Don: It's a perfect solution for both. Okay, next question. Would you please comment on preparation of unstructured and structured data and methodologies? Please, thanks.

44:12 Travis: Well, there's a lot of unstructured data out there. I mean, a lot of information from PLCs that we just simply wanna have available. Of course, there's a lot of structured information, and you kinda think of it in two ways, of course. There's user-defined data types and PLCs as well as your own structures or schemas you have developed as far as data formats. Now, as far as MQTT does support UDTs from the edge device, and we can get them delivered as an actual user-defined type inside of, say, Ignition or any application that's using MQTT for that matter. As far as structured data outside of MQTT, I was mentioning earlier when you have that challenge to be done about real-time or historical data. Well, historical data is gonna have some structure, but it's MES data in particular. But understanding that we can make sure that we are delivering all the information to a central system in the same format and do the translation at a plant, we're gonna have a win.

45:08
Don: Sure, sure. I think this is a good question about this OT, IT and people shuddering. This question is from Karen. Clients we talk to shudder when "cloud" is mentioned. Is this a fight we need to fight at the OT level or will it get resolved by IT in time?

45:26
Travis: It's gonna be a fight, I think, on both sides, more on the OT side, of course, than the IT side. Chances are, your IT is already leveraging the cloud today for a lot of systems. The OT side, of course, has traditionally been very against that because PLCs are not secure, the network is not secure. But like I said, we could put protections in place or we can have these edge gateways that make it so, we cannot talk to the PLCs directly, and approaching the cloud, being able to leverage it now, is something that the IT people would be doing with their other systems. They could secure it in the same fashion they are securing the systems they have today if we moved to this kind of architecture. So, the world definitely has collided, if you will, the OT and IT have to work together in order to get this data to the business. And that you're gonna see that the companies that have the two systems working together really well and are putting security measures in place rather than trying to just say, "Let's not do it at all," are the ones that are gonna start seeing the benefits.

46:28
Don: Great. Thanks, Travis. Just trying to get to a couple more here with a couple of minutes we have left. Does moving to a Pub/sub decrease the processing time of ignition to the PLC for the operators? Brittany asks.

46:39
Travis: So, is a question that we had earlier. Absolutely, it can decrease the processing time because this is more like an ignition. We're not having to pull the PLCs when pulling, because we're doing a lot of socket communication, it eats up CPU cycles. And so the more we pull, the more CPU we need to do that, and the more connections that we have to have open. And so with the Pub/sub, we're not doing that. The data is instantly available. It is literally if... With MQTT, with Ignition, subscribes to a broker, then all the data that's in that broker is instantly available, there's no configuration ignition, whatsoever. The tags are there. You can have millions and millions and millions of tags with this architecture and the processing time and ignition would be nil, whereas before it would be a massive amount of work to be able to get that data from pulling. So there's a significant difference when going to something like this.

47:36
Don: Good, thanks. I'll let you look at a couple of other questions here, but I'm gonna pull one while you're doing that here. And this is really about a strategy question, I think. And the question is, "What is the influence of data in control systems operation? And how does IoT influence control strategy?" I think you talked about this when you talked about the bottom up and the whole building and the strategy here. But what really is the influence here, as one looks at the control strategy that one has from a control systems view point in building this architecture?

48:12
Travis: Well, from the control systems, down... From a PLC level of course, the strategies are all the same except for that we want to be able to get the data into this open format. So really it's just about translating. It's just about getting it into the middleware that would allow us to do a lot more of it to get that data into more systems. Especially machine learning and business intelligence, we see a lot of need for that and moving into those kinds of systems.

48:43
Don: Okay, great. Thanks, Travis. Here's the question, "So, if open architecture is so important, why does your software use Windows?"

48:51
Travis: So that... Great question. Well, as you guys may or may not know, Ignition's written in Java which is cross-platform, so it works on Windows, works on Linux, works on Mac. It's cross-platform, and that is important. In fact, our whole entire OPC UA server and our drivers, and of course our MQTT implementation can run all entirely on Linux. So, it's not just Windows-based, we are both on the standard, we could be inoperable on the data formats as well, of course, the operating systems.

49:22
Don: Here's one I think I'd like you to respond to, depending on what you thought. I don't know if you thought about this. Are you going to offer an advanced class, of some sort, based specifically on implementing a distributed enterprise architecture? I know you do that with your architectural discussions, one-on-one, with our enterprise clients, but I don't know, have you ever thought about advanced class on that?

49:42
Travis: It's a good idea. You'd have to really have a lot of specific use cases and different examples to have that class effectively. In this particular webinar I use a lot of high level... If it's talks and a lot of looking at different protocols. But there's not much as far as the real technicality, how we could do some of these things. Now, it's easy to get to this kind of architecture and it's important to start shifting our thinking, but there are... For different customers, there are gonna different ways we can actually start getting data into this system's flow. And it's just about looking at how that works and what those formats are gonna be, and it's different from customer to customer. So I'm happy to take on any talks with any discussions before we have an actual class on this, so that we could start really looking at the infrastructure and how we can approach something new.

50:31
Don: Travis, earlier on in the talk you mentioned when you were talking about standards, the open process automation initiative, that was actually... You didn't mention a lot about it but you mentioned it was going on. Because industry is taking a look at it in process industries. I know ExxonMobil played a very big role in instigating this open process automation group getting together, they presented on it in multiple different events. So, their goal is to get away from traditional DCS systems and to change the architecture with open architecture, which historically has not been that. Question here from Hector is, "Can this schema be applied to DCS systems?"

51:10
Travis: This idea... DCS systems are... While they are closed, they do have a lot of benefits. Everything immediately works together, simple to configure. And that idea is what open standards and open architectures are really all about. But the thing is, to be able to use any kind of software and hardware that work together. So it's being able to have these things really effectively, know how to talk to each other natively, and be plug and play, where we can use the best of class of all of that. So we can certainly build a distributed system with these open standards and architectures so that we're not locked into one particular thing. And that's the... I'm talking about MQTT here. Whether you buy Ignition or not, or OPC UA or these other protocols. Whether you buy Ignition or not, getting to an architecture like this allows you to use any kind of software or any kind of hardware. And that's what this open standards body is trying to get to, is to... So we can start looking at different options and best-in-class, so we can have some old and some new. As we buy, everything plays together rather than having to replace everything.

52:17
Don: Yeah, at least the person in the driver's seat, making choices as they go forward to continue to do best-in-class, as they're evolving their architectures. Okay, we're kinda coming down to the last two minutes that we got. So I just wanna say to those of you... 'Cause we have incredible responses from questions, thank you very much for all your questions. I reiterate what I said at the beginning, we will get back to get answers to all of them, but I wanna give you maybe the last minute for anything you wanna say in wrapping up, or advice or thoughts or anything to this audience, as we finish up here.

52:50
Travis: So, I guess I wanna say that this is... I've worked with a lot of companies over the years and this is something that, while every company thinks of the enterprise, has a corporate level, it's still treated where plants are independent, the plants are different and have their own budgets, they get their own software, they get their own PLCs, they have their own control engineers. There's not much governance at the enterprise level. That is changing quite a bit though. Rapidly, discussions are now going to the... Where the enterprise is gonna start having some governance, is gonna start maybe buying licenses there and having the plants buy the licenses. The shift is already happening, and so it really is just a way of... Let's just think about it and get prepared for it. And while it's gonna be hard and tedious at the beginning, there are vendors out there that are here to help. Whether it's us or whether it's hardware vendors. And there's ways we can get to this without having to rip and replace everything. We can transition. And I encourage every one of you to just start that process, have somebody look at just what the current landscape is and what their ideal scene would be, and where they wanna go. And I'm happy to talk to anybody who wants to learn more.

54:04
Don: Travis, thanks a lot. Thanks to you, our audience, for all the questions. As I said, we'll get back and make sure they all get answered. With that, we've come to the conclusion of our time and we're finished. Hope everyone has a great day. Thanks again.