Build Anything with The New SCADA
How to Speed Up Development Across the Enterprise60 min video / 54 minute read
About this Webinar
Forward-looking enterprises are always searching for quicker ways to develop new software applications that can sharpen their competitive edge. Because, let’s face it, the usual process of software development can take forever (they don’t call it “development hell” for nothing).
Old SCADA software makes development relatively simple for non-programmers but it’s too limited to really work as an enterprise-wide development solution. But what if you could combine the drag-and-drop simplicity of SCADA with the straightforward licensing and deployment of IT?
Watch this webinar to find out why The New SCADA has everything your enterprise needs to build anything.
What you will learn:
- How rapid application development (RAD) tools let you build a SCADA project without scripting
- What it’s like to work on separate applications and modules within a single design environment
- How to spend more time on project definition and less time on implementation
- How connectivity between PLC data and SQL databases enables you to build innovative applications throughout the enterprise
- Why it’s best to develop on a modular SCADA platform
Don: Well, good morning everyone, and welcome to Build Anything with the New SCADA: How to Speed Up Development Across the Enterprise. Thanks for joining us today. Just in terms of introducing myself, my name is Don Pearson. I'm Chief Strategy Officer for Inductive Automation, and I'll be the moderator for today's webinar. You'll also be hearing from a number of other speakers, and I will take the time to introduce them shortly. We're gonna talk about some specific ways to speed up SCADA development as well as development for projects in other parts of the enterprise, and we're gonna look at four specific features of our software that can really save you a lot of development time when you're working with it. Just a little bit of background on our company, Inductive Automation, founded in 2003, we've had an amazing amount of growth since then. I think we're very comfortable saying that we're the fastest growing HMI/SCADA and MES software company in the world and continue to be year after year.
Don: From the very start, we had a goal to really fundamentally change the industrial software market, and that's why we actually do things differently and have a different business model and approach things differently in terms of licensing and how we work with our customers. So I think those of you who are familiar with us already know that. Those who are not, you'll become more familiar as we go forward. Actually, the software is being used in over 90 countries right now and enterprises across the globe, virtually every industry you can think of, oil and gas, water, wastewater, food and beverage, government transportation, patching databases and the list just goes on. We have a team of over 1250 integrators around the world, and really it's trusted by major companies. 30% of Fortune 100 and over 20% of Fortune 500 are using Ignition right now to build HMI/SCADA and MEM systems for their enterprises.
Don: I think one of the reasons is because when you take a look at Ignition and its rapid adoption across so many industries, it's 'cause both the end user and the integrator realize that Ignition has the power really to build almost anything. Certainly, it's unbeatable when you look at HMI/SCADA and MES solutions, but its technology, licensing, and architecture are really different from any other SCADA software. So it's powerful enough, really, for any project you're looking at, flexible enough for just about any architecture you're looking at, and capable enough to be applied to almost any industry. So in this webinar, what we're gonna do is go into detail about some of the features in Ignition that actually make what I said true. They empower enterprises to build any kind of industrial automation software that they need for their organizations. So with that, let me introduce a couple of folks. Travis is Director of Training and Sales Engineering here at Inductive Automation. He's been with the company since 2003, and a variety, he's established many parts of the organization over the last dozen years. So Travis, introduce yourself a little more thoroughly about some of the things you've worked with and give the audience a little sense of your responsibilities now.
Travis: Sure. So, as Don was saying, I serve as the Director of Training and Sales Engineering. This year, I'm really focused on sales engineering and growing our integration program and being there as a technical presence for both pre-sales and post-sales for our customers. But personally, I've been with the company since 2003, since the beginning, and I'm an expert in the product. I've trained thousands of people on Ignition, and I'm happy to be here today.
Don: Great. Thanks. Glad you could do it. Also, I would say that we have... We're really pleased to have three guests from Sherwin-Williams, Ryan Beno, Jeremy Kipper, and Dan Trudeau. And I'm gonna let each introduce themselves a little bit more. Could you take just a minute to introduce yourselves, a little bit about your experience, background, I know Jeremy, you've got some varied background in a variety of different systems. So you've got a good perspective to bring to today's webinar, but also what your current role is and maybe how long you've been working with Ignition. Let's start first with Jeremy. Then I'll go to Ryan and Dan.
Jeremy: Thank you, Don. I have about 17-18 years experience in working with SCADA systems and distributed control systems. Initially, worked as an integrator doing software development and configuration at Invensys. I've moved on. I've been with Sherwin-Williams for nine years and working with Ignition for the last five years.
Don: Great. Thanks for the intro. Okay, Ryan, yourself.
Ryan: Well, good morning, everybody. My name is Ryan Beno. I am a software developer here at Sherwin-Williams. I have been with the company for about seven, almost eight years. I come from a manufacturing background. I used to be our site IT admin for one of our larger manufacturing facilities in the United States. I have been working with my current team along with the Ignition software for about four to five years in various different aspects of the application.
Don: Thanks, Ryan, and thanks for taking the time to join us. And then Dan, your introduction.
Dan: Yeah, I've been with Sherwin-Williams for about 11 years now as a software developer. I've been working on the Industrial Applications Team and working with Ignition for a little over five years since the Ignition beta. So before it was released, we were able to get in, right at the start. We're responsible for SCADA systems, enterprise manufacturing, intelligence, and a lot of different systems that integrate business clients with the shop floor and equipment. Before joining the Industrial Applications Team, my background was actually in data warehousing and business intelligence, so basically took a lot of that knowledge of SQL databases and was able to apply that with the Ignition software to build a lot of very valuable solutions for the company.
Don: Great. Thanks. I know you guys are just minorly busy to understate it. So for all three of you to take time, much appreciated. Thanks so much. I'd like to get a little more perspective from each of you really on sort of a high-level overview of how Sherwin-Williams is using Ignition, maybe a little bit how it evolved, how it developed over time, and maybe where you see it's going. I know it's a unique system, and I think it would be helpful to the audience to really get a sense before we go into discussing some specific capabilities of Ignition. Where does Sherwin-Williams sit with it and how did you get to where you are now? So I think I'll just start with you, Jeremy then ask Ryan and then Dan, between the three of you, we'll probably get a pretty good picture.
Jeremy: Sure. Well, at a high level, our team's mission is to modernize manufacturing at Sherwin-Williams. And the way we've approached that with Ignition is we started off using historizing data for some of our batching systems and gradually expanded on that to bring in OEE and work with productivity. We've expanded that from the plant floor to across our entire enterprise, now making data visible from the operators all the way up to supervisors and at the executive level.
Don: Great, thanks Jeremy. Ryan, why don't you add to that from your perspective?
Ryan: Okay, great. Well, to add on to Jeremy's point, also to expanding enterprise-wide, Sherwin-Williams is actually starting to also look at communication protocols. I'm sure a lot of the folks on the call have different hardware or different devices that they are attempting to interface with, and one thing that we're looking at right now is not only looking at brand new technologies that Ignition interfaces very well with, but hardware and vintage, antiquated hardware that have some sort of means of pulling back that communication or some sort of methodology for getting data out of old equipment. So that's been a solid focus of ours as well, and that just enhances the Ignition experience within our environment.
Don: Great, thanks, thanks a lot. And Dan you got the full history of the Ignition involvement with Sherwin. Give your addition to this.
Dan: Sure, and I'd actually like to continue off with what Ryan said about some of these... The legacy equipment out there. Sherwin is a large, mature organization. We have dozens of manufacturing facilities out there. We have many systems in place already. We have MEM systems, control systems, business intelligence systems, and a lot of new equipment, a lot of old equipment. So there's been a lot of work and effort put into basically all of our manufacturing and supply chain operations. However, there was always this missing piece, and we were always searching for a solution to fill in those gaps 'cause we didn't even necessarily reinvent the wheel completely, but there was nothing that was bringing everything together into one well-oiled system that would give that whole visibility. So on top of what Jeremy and Ryan have said, we have replaced a lot of data islands, one-off systems, really integrated them into a larger audience, really just given this common language and system for everyone to speak the same language, to really bring in past investment to increase ROI on them and really just bring an enterprise-level view that we've been searching for for a long time before Ignition came along.
Don: Great, thanks. I think with all those three viewpoints put together, it gives us a little idea of what you were trying to deal with and where you are right now. So with that, thanks for the overview, gentlemen. What you've been doing with Ignition is... We've watched it. We've done case study work on stuff and have been pretty impressed with it, so what you share today is really gonna be, I think, valuable to our audience. On the surface, it might appear that Ignition is just like another software for HMI/SCADA, and MES, but as companies like Sherwin have discovered for themselves, it's actually software for building software. Ignition's a software platform, and it diverges so significantly from what might be old SCADA licensing and deployment and technology models that it occupies its own new category. And we just frankly here at Inductive Automation have come to refer to it as "The New SCADA" It was built to be a flexible, powerful toolset for building just about anything from SCADA and beyond, and that's what we're gonna be looking at today.
Don: This also comes from cross-pollination of SCADA's rapid application development capabilities with the straightforward licensing and deployment models of IT. If you haven't heard of cross-pollination, really, it simply means combining a concept or practice that comes from one industry and just some from another industry, so from these different industries you can create something that's really groundbreaking and invaluable. And our CEO, Steve Hechtman, really, from the very beginning, wanted to bring IT technologies and the controls engineering world together. So as you look at that, you might ask, "Why did we cross-pollinate SCADA with IT?" There's a few reasons I just wanna mention. It has favorable licensing and deployment models like I mentioned, but you really have to be trained in software development to build an application with IT tools. SCADA software by comparison makes development relatively simple for non-programmers, helps control engineers to modify SCADA projects and their displays even if they don't have extensive training in the software development world. But unfortunately, old SCADA was too limited to be effective for the development solution across an enterprise.
Don: Old SCADA is really just based on '90s technology, and its licensing model by the tag and by the client makes so many projects just cost prohibitive, you just can't scale them, and the deployment model is just too convoluted to be effective going forward across an enterprise. Problems of old SCADA all increase... If you add them all up, they're just gonna increase the time it takes for a project from an idea to an up-and-working solution or the project is just gonna get trapped in what some people call "development hell," which just means the project gets stuck in the painful and that endless development process before it ever sees the light of day or it gets scrapped 'cause it's too expensive or won't have enough ROI. So there's a lot of things that can make a project not go forward. If you really wanna go forward, you have to think of all of those and bring things together so it will actually work. So I'm gonna ask Jeremy and Ryan, and even some comments from Travis on this one, but in your experience, you first, Jeremy, what are some of the factors that can slow down the development process, make it drag on for a long time, or come to a total stall?
Jeremy: Well, oftentimes, sometimes there's a clear definition of the requirement or even what some of our users truly want, and one good thing about Ignition is that it's very easy to prototype. So early on we could come up with different prototypes, whether it's screens that help software function, and be able to communicate these and would then get feedback from our users. This speeds up the overall cycle then because then we can take corrective action if there is new enhancements or new functionality, new business data that we need to bring into the system. And throughout the entire development life cycle, we found that, it's very beneficial. Also some of the designing for roles is we found that what fits best for one role in our organization doesn't necessarily fit best for... At another level in our organization.
Don: So you're designed for roles when you're thinking about your project development?
Jeremy: Correct. So how can the data that we acquired for the operators, for the equipment, how can we replicate that or roll that up across the organization to benefit supervisors, traceability, tracking, process equipment. And at a higher level then we have productivity goals that we can now set and historically show our organization how well we can perform.
Don: Great. Thanks for that. Ryan, add your perspective to that.
Ryan: Well, to kind of elaborate a little bit further on Jeremy's point there, when dealing with a prototyping approach, you're also looking to create almost like pilot groups when you're doing this prototyping because depending on the size of your organization, the way that you're able to develop and especially in Ignition where you can keep developing further and further, whether it be a dashboard or widget, some window and keep adding business data on top of business data on top of analytical data or mechanical data. You can keep adding all these pieces and parts in, but when you start doing that, you start letting scope creep into your project. So working with small pilot groups really helps eliminate the scope creep because you can actually focus on what is the task at hand and what you're trying to accomplish, and then with that smaller group, if it meets the requirements of that group, then it could get published to the larger organization itself.
Don: You guys have worked the pilot small project strategy really well, I think forever, haven't you? Since you first started out with Ignition. That's great. Travis, from a broader... Thanks, Ryan. From a broader perspective, Travis, you've worked with clients in multiple industries, what would you like to add to this perspective?
Travis: Yeah, I mean, I see a lot of projects from small to extremely large, and I think in all of the situations, all these projects, it's really understanding the overall requirements, getting a really good requirements documentation to understand the scope. And what I mean by that is not just understanding what you're gonna be building, but also understand the infrastructure you're building on top of, understanding what you're gonna be connecting to and what protocols are there, so you have a clear plan from point A to point B. And we see what Ryan is talking about there is when you're developing, you wanna think of the entire picture. A lot of people wanna go and think, "Okay, I gotta build this entire massive system," and so they're going down that path and they very much divert all over the place. And they could go on this path and think, "Oh, I gotta go work on this," they go to that path. But what happens is you start like you're saying, scope creep, you start developing so much that you lose focus on a piece.
Travis: And so I think being able to, along the way, create yourself wins, understanding small requirements that lead into a larger scope, but getting into a completion on things where you can actually demo it and show it to get a win, then move on to the next one. Take your small low-hanging fruit items that you know you're gonna get ROI or something on, and then build onto it. If you do it that way, you'll fully understand the scope and to build small increments along the way and be demoing them with the customers, meaning the people who use the applications, you're gonna get buy-in from them and you're gonna be very successful with the project at hand. It sounds very easy to say what I'm doing, but I mean, a lot of times, I think this... I'm from the software realm, I think the integrators in the industrial realm can benefit from a process called, like Scrum, which is used for enterprise. It's a way of running your software organization as far as how you develop. So that's my perspective.
Don: Sure, sure. Dan, you wanted to comment on that?
Dan: Yeah, and to just kind of talk about what Travis was saying with the licensing model, that the incremental approach works very well especially when the more you learn the software, the more you realize what it's actually capable of doing and the creativity starts to flow that once you have that license, you don't have to keep hitting someone up for additional costs to keep adding to that. Ryan mentioned that and then Travis. Also one thing, the way that Ignition software is set up, before you purchase that license, you have that two-hour trial mode. And I know initially when we started, we were able to take that. You can design a fully-functional system. It resets every two hours, but you can actually prototype and show what you want to deliver. Instead of just writing it down on paper, you can actually show something tangible, and that will probably morph a little bit from what you originally envisioned. So then you really know what you're getting when it's time to purchase and actually deploy.
Don: Yeah, I think those are really good points. The first one you made is something we see all the time, is when you establish the Ignition platform inside your organization, multiple projects going forward, it's strategy like Travis is talking about. You're not paying for a new project, new project, new project costs. You're able to leverage that investment because of the licensing model as well as some other things it supports.
Travis: Yeah. I wanna say one more thing. I've worked for sure with these guys before and what they've done really successfully with their organization is, they make the operators at the plants feel like they're part of the application. In that they're developing and they're on-site with them, showing them the application, downloading it to them and allowing them to provide feedback and input on where it should go. And when you're making a big system, a lot of times you often overlook that piece 'cause you enterprise-wise, you have a goal in mind, you wanna achieve that goal, and you're not realizing exactly who's gonna be using the application. And I think that's another big piece about it, is to interact with those guys who are using it and get that feedback. Yeah, it's gonna change your scope and your goals, it's gonna change a little bit. But if you still focus, like with the scrum process does really well, you focus on small things, you get them to completion, and if you find out new items along the way, that's fine. That's gonna fill your backlog. You then take out of that what you're gonna be accomplishing in the next cycle, and you get these to completion where you can demo it. I can't tell you how important that is for any products that are out there.
Don: Oh, absolutely, and the point you made about operators... Yeah, it may adjust your budget, but after all, these guys are stakeholders. If you want adoption and you want the darn thing to work, the operators are in the loop for God's sakes. It has to work from their perspective, so you have to have that bottom-up view that allows you to be able to get that kind of input. Okay, great, so, I think that's a good perspective and to launch into this next slide here, 'cause obviously we don't wanna get stuck in development hell, we wanna make innovative new applications to do it quickly, avoid scope creep, include everybody in the process that should be included in it. So, in Ignition, there are four distinctive features that are gonna help you to build any type of solution your enterprise needs. Those features are rapid application development tools or RAD tools, uniform design experience, a modular architecture, and seamless connectivity. So, what we are gonna do is talk about each of those features and how those features help streamline the big task to development which our guests here have laid out as a big challenge.
Don: So, starting off with the RAD tools in Ignition, the designer application that is included with it, it's object-oriented, development environment, it's got drawing tools, powerful scripting engine, these tools save time, and they make it like really simple to make dynamic projects, whether you're talking about SCADA or some other type of project for your enterprise that Ignition is capable of. If you don't have much knowledge of scripting, making a screen can actually seem to you like it's going to be a seriously daunting task, but in Ignition with the Vision Module, you can build projects by using windows, components, and templates. You can open a window and begin dragging and dropping in components such as lines, shapes, buttons, tables, and more. You can select pre-configured components to represent your tanks, your pipes, your pumps, all the other objects that are in the manufacturing facility you're working with, and you can easily import various types of graphics just by dragging them in.
Don: Also, leveraging components and templates, you save a lot of time by reusing components and templates across separate windows. If you decide to change the design of the template, the change you make will automatically be reflected in all uses of that template across all of the windows. So once your visual components are in place, you can make them active by binding their properties to information, the real world, you know, the tags, the other component properties, SQL, your SQL query results and more, so that's sort of a backdrop of this one RAD tools support for Ignition platform. So Jeremy and Ryan, let's start with you, Jeremy. What are some of the ways that this particular idea of leverage templates, how do you use leverage templates in your system? Have you made projects easier with these pieces of the tools?
Jeremy: At the simplest level, it's definitely reusability, we can design one component, one look or one feel and reuse it in multiple areas in our admission clients and windows. When we come back and if there's a component, if there are color changes or even pieces of logic that need to be changed for the display, we can make it in one place and it's replicated across the board. This is important too because... Very important for us because we have a centralized design for our applications efforts, yet we're communicating with up to 30 sites. The other part of it is not just the object-oriented aspect of Ignition too. Sherwin-Williams is very data-centric, so we could store most of our configurations in a database and then easily... By the way we've designed our templates, we can pull these in and model them based on our data models and database. We have similar equipment from site to site and similar production areas.
Don: Sure. Ryan, your thoughts on this question?
Ryan: Well, I would have to say in terms of templates, just a quick example, I guess, would be when you're talking about something as simple, like Jeremy mentioned, as a color change, and you have something coming in for a color change and you have this component that needs a banner color change from blue to red, well, in your template, you can make this change in one spot, whereas if you don't use the templates, you would have to change it however many X times that you have throughout your entire application. So, let's say you change it 30 or 40 times and this takes you 30-some odd seconds each time, you could see where this time for development expands when you get away from the template. But if you're using the template, you're saving time, you're saving money, and of course development, overall.
Don: Great, thanks. Thanks for that perspective. Let's go a little further and take a look a little bit at scripting and scripting made simpler. Ignition's built-in scripting engine actually includes graphical script builders which you'd use when scripting responses to events, mouse clicks, property changes, etcetera. With script builders, you end up being able to create a whole project by pointing and clicking instead of scripting. If you know how to script, of course, you can also do that in Ignition. But you save time with script modules. You write a block of code once and then use that code anywhere. You can also combine scripting with drag and drop design, those kinds of things. So, for Jeremy and Ryan, what's been sort of the scripting features that have been most useful and how have they impacted your development time? Jeremy?
Jeremy: Well, I think especially with the Java platform and then Python, I find it extremely beneficial and powerful, and that's coming from someone that has a software development background. It allows me to extend the system and fit our needs. Also, it's... One, is not just extending the system, being able to connect to our different database systems or business systems, but it also has facilitated our development and, as I touched before, being able to take a data module on the database and then basically generate our dashboards, generate our equipment, generate SQL tags, and it's very powerful. It gives us the capability to replicate and automate a lot of these otherwise tedious tasks with other systems.
Don: Sure. Ryan, your thoughts?
Ryan: Well, I think in terms of the scripting functionality, one of the big things to myself and our team is when you're talking about things like legacy systems or legacy hardware, a lot of your communication formats are gonna be pretty standard and you're gonna have one way or another and it's gonna be pretty vintage. When you're doing that, the script library and the script modules inside Ignition and working with the Python libraries themselves actually opens those bastions pretty wide where before you didn't have options to pull anything back. Whereas now here at Sherwin-Williams we're working on pulling back all this old antiquated communication protocols where it's much easier now for us given Python and the libraries that are out there and there's a ton of white papers and so on, so forth, in regards to these certain libraries that for as easy as it is to use the script modules in Ignition, your options are pretty wide open.
Don: That's great. Thanks for sharing that perspective. Let's move to another of the ways that Ignition could speed up development. Uniform design experience, a little bit closer to Ignition's RAD tools, the designer application. The Ignition designer, it's actually one of the things that makes Ignition truly unique from the whole rest of the SCADA world. It's the only SCADA designer that provides a single environment for you to be working on separate designers and applications and modules. And I say that it is the only one period, so it really adds a lot of power to speeding up development time. If you think about it from the viewpoint of a controls engineer and designing a project with old SCADA, what does he have to do? He has to switch between many different windows. For example, say the engineer may have a designer for templates, another designer for windows, a deployment application, maybe a licensing application, a panel view application, they're all open at once. Working in different applications is much more straightforward when you have an Ignition designer. It's actually... You can literally design in different applications without having to leave the designer window. It's one workspace where you end up being able to design anything that you want.
Don: If you think of old SCADA... Also, designers are often sold separately and you have to purchase individual licenses for each design client, which puts a prohibition to get people working together. Ignition, sold by the server, the designers included as part of the software. You get an unlimited number of design clients when you buy this software. So if you think about concurrent development, it really isn't supported very well with old SCADA systems, so Ignition totally does support it. Ignition example would be you can configure an alarm notification pipeline in one design client, go into sequential function charts, SFCs in another design client, and easily switch back and forth. It also allows multiple users to design at the same time and it has a screen locking feature so that two users won't override each other's work, so it's really set up for facilitating concurrent development in development time. Jeremy, let's ask you that. What's the biggest difference being working in other SCADA designers and your experience in the past and working in the Ignition designer?
Jeremy: Well, having unfortunately or fortunately experienced working in some of the old SCADA systems, what I can truly appreciate with Ignition is that it's a very open architecture, an open platform. One is the platform independence, being able to run it and have Linux servers work with Microsoft clients, iOS, Permobil, and just having that open architecture, that really helped. On the software development side with the scripting, it's very... Once again, there's a tremendous amount of resources, and I found it much easier than other SCADA systems to be able to create these custom interfaces either with equipment or a business system, whereas in the past with those SCADA systems, it seemed like there was a very limited knowledge base and oftentimes the key knowledge bases was centered with the SCADA vendors. With Ignition, I found a wealth of knowledge amongst the community. There's always other people out there that have new ideas they can share. They probably even solve the problems that we may be looking to solve at times.
Don: Sure. Great. I really appreciate your background in sharing that kind of perspective. I think what we would like to do though, since we're talking about it, is I'd like to step out of the way here, and let Travis sit down and give him a chance to use a demo of the Ignition designer and just show some of this stuff that we're talking about here, Travis.
Travis: Yeah, absolutely. So we talked a lot about how the Ignition designer is a rapid application development tool and has a single designer to configure everything and I wanna give you a sense of that here as well as how you could do concurrent designers, how you can have multiple of these things open. So I have the designer here open and I'm already connected to a couple of devices, and so as far as if you're just creating HMI screens, somebody who doesn't have necessarily a programming or a software development background, you can easily come in here and in the same designer, you're configuring your tags, your windows, your templates, your alarm pipelines, your alarms, your history, everything is done in this one tool. So I can go in and I can connect up to our various devices we have and I could basically take tags that I find from browsing all of the devices in the OPC servers that are at Ignition, drag them over. It creates my tag database and I can start seeing live values. That's important when you're developing so you can see what it's gonna look like before you go into the designer phase. And taking tags from multiple devices and bringing all the different applications... All these different controllers into one application is also really important. You can work with any protocol that's out there and we can bring these in and we can bring them into Ignition.
Travis: And so the idea again we just create our tag database and then once we have our tag database, it's easy to work with. We can take tags and bring them on the screens and the drag and drop allows me to basically drag things on the screens and view it in different ways, and it gets me going quickly without having to know a lot about Ignition in the development environment, whether it be for real time or whether it be for control. Maybe I wanna take some tags on here as multi-state buttons or two-state toggle buttons, things like that. I know we have lots of rich components and things that you can bring on to screens. The idea again for rapid is just drag it on, take a tag, and just drag it over to the tag, and buy it up to that value. And of course, if you're looking even more powerful with templates and UDTs, is to create objects, you can reuse over and over again that has interaction built into them. And so we look at templates, it's really important to build these things out, and with that, you have the ability in Ignition to actually upload that to an online repository where you can keep track of your templates, and it happens to be one that's open to the public. We call this Cloud Templates.
Travis: So I haven't made any templates here on my system. I'm gonna go to Cloud Templates, and I'm gonna go look for... Let's see some gauges that are up there, so some nicer gauges that happen to be there. I'm gonna take this one right here and import this template into my designer. And so as the template shows up here, I can use that template over and over again. But part of the rapid environment is that I could take a tag and I can drag it onto the screen, and I could make those templates. So if I take this ram tag now, I can see a drag and drop, that gauge is now available for me to create out of that. And so I can make several of these and bring them on the screens, and of course, the idea is that it's configured in place. We go back, we make a change, it updates everywhere. So it's important to be able to use that kind of... To be able to easily rapidly create these screens and work with various tags. And I'm not showing user-defined tags as well. You have objects for tags that you can create and has a bunch of configuration built into them, such as history and alarming, and things that you take advantage of, again, by easily creating instances and having all that logic in one place in the build once and use philosophy many times.
Travis: So that's important for the actual designer phase. And when you're ready you can save an Ignition designer and, of course, you can open up runtimes and have many of them out there. With that being a client server model, all of those clients would be updated automatically. And so I can see that screen that I just made has it pushed out and deployed, whether it be in that production or staging environment, and we could have people actually using it as we're making changes. Being able to make a change and press save and know that you have all the clients algorithms updated, without having to walk around with a backup, is a big deal in that way. And from a software development, I know Sherwin-Williams has certainly used this feature a lot and that designers have concurrent development. You can have multiple people working on the same designer at the same time. And so if I go and launch another designer from the web interface, so I'm gonna go ahead and do it right now, 'cause you can launch the designer anywhere in your network by simply going to your web browser and going to a web page for Ignition. It allows you to get access to it.
Travis: There's no insulation on the designer or the client. That's also important because that means I can go anywhere. I can be on my laptop, I could be on my PC, I can go in the server room, I can go anywhere in my facility, and open up the application and make some changes and get access to it. So I'm gonna log in to the designer. I'm gonna have two of these designers open side by side, and so I'll show them up here, and you'll see that with this, that... So I have two here. In the left one, I already have a window open. So with Ignition, of course, with having multiple people designing, you don't want to allow them to overlap each other and make changes. So if I go and try to open up the overview window, it's gonna tell me that, Hey, it's opened up by admin at this IP address, so I get that sense of that. But I could be going over here and adding some tags. I'm working with tags. I can can be going adding some templates in here, I can be going up to alarm pipelines, maybe I wanna configure a new alarm pipeline, but I'll be working on the same project at the same time, and of course, if I make change to the application, let's say, for example, here I go to another screen and I wanna make a change to this screen.
Travis: On this roster manager screen, I make this component a lot smaller and I put a tank graphic on here and I save the application there. Well, my runtime, of course, is gonna stay updated. So if I go to roster management, I update it, you can see that both of these people can be saving and have these clients update allowing us to develop applications much more rapidly. And if you talk about some of the things I was mentioning earlier with understanding the scope of a project and breaking it into small pieces, you can't... One developer can't work on everything at the same time, it's impossible. Everybody tries it, it doesn't work. So breaking it up into teams and having people dedicate themselves to various aspects of the project, being able to go into one designer for the entire tool allows you to really break it up and save and build your application out and test it along the way and give people, the operators, the ability to provide feedback. That's what this tool allows you to do.
Travis: And Inductive Automation uses this tool internally. We use it for all of our applications. We use it for our customer relationship management application, to manage our accounts and our contacts, we do it for our university, we have a way of adding videos and challenges and all that stuff from here. We use it for pretty much any front-end to a database, as well as we can use it for HVAC in various systems within our organization as well. But it's important for us, just like any other company, like Sherwin-Williams, to be able to develop in one environment and be able to save it and have an update and to not have to have specialized software because we can bounce around here and have multiple people working on it. It does become a nicety and something that you... Once you have it, you don't want to ever not have it.
Don: Never not have it, that's right. Thanks, Travis. So this is what I'm gonna do, I'm gonna do a quick overview, so you get a little bit of reality on what we're talking about when we're talking about that capability. So let's go into another way. The third way that we started off at the beginning, talking about modular architecture, another way Ignition can end up speeding up development time. If you look deeper into the Ignition platform, this characteristic, it really distinguishes also from traditional SCADA, this modular architecture. It was built to support from the beginning an unlimited number of modules, and each Ignition module is built on the Ignition platform. So there's a wide range of Ignition modules already that provide features like designer workspaces, gateway settings, drivers, SQL bridges, just a whole bunch more, and you can choose from a range of Ignition modules to build any kind of HMI/SCADA and MES system. Or even one that's outside of those categories, because the modules are built on a common platform, the user plugs them into Ignition, and they integrate seamlessly. This also means that the system has fewer bugs and greater overall stability. So I'd like to ask our panelists now, in your experience, how's the modular architecture Ignition helpful to you, from a development standpoint? You kind of alluded to it a little bit in your first introduction, Jeremy, but elaborate a little bit more on it now.
Jeremy: Well, I think it was, that was a key thing in... Being effective and being able to get the corporate buy-in at Sherwin-Williams to do our job. Hand-in-hand it's a nice thing in the modular architecture that was very beneficial for us. The way I look at it is, there's a lot of other systems out there, it was difficult to be able to justify the cost because essentially we would have been paying for everything that everyone else needs, and not just what we needed to get our job done, and accomplish our goals. Coming in there at a modular level, we were able to start small, get a foothold in, focus on a pilot site. We had the modules that we needed to accomplish that task. Then from there, we were able to prove the return on investment. Expanding from there, that leads to corporate buy-in and we were able to extend the platform and development from there. Each of these modules fit together. So with that in mind, when we did our initial development for maybe some historical data, we were eventually able to expand on that to ODE. And from there, more other productivity solutions that we did there.
Don: Sure. Ryan, I'm not saying you have to have, but anything you wanted to add to what Jeremy was saying about the modular architecture?
Ryan: Well, I think in terms of... For a modular approach, not just the overall architecture, but as well as your projects having modular pieces to them. Like if you have a baseline project for some function that is similar across every site that you have. And this is a big piece, especially when you're dealing with communications, for example. You could have three different pieces of hardware, same manufacturer, but they all have some baseline that is similar to them, they just have different functionality that can do X, Y and Z. So taking a modular approach, building your baseline, and then adding pieces to it as needed, makes that development time much more quick, much quicker, and much more efficient.
Don: Great, thanks. So I think that's what we'll cover in terms of that particular one. I'd like to go to the fourth way that Ignition speeds up development, talking about seamless connectivity across the enterprise. Imagine that we have seamless connectivity between the various modules that plug-in, it also connects seamlessly with devices, databases, other programs throughout the enterprise, which has been mentioned in some of the comments and the answers from the team from Sherwin. It was intentionally based on standard technologies that IT professionals were familiar with, that's why we're using Java, and you mentioned Python and connecting to all SQL databases. So with those IT technologies, Ignition really has the power to handle advanced data management, processing, and reporting. And it's web deployable and compatible with different operating systems.
Don: So this has a huge effect on it, so you really end up... Because it can put PLC data into SQL databases, Ignition lets you run queries of PLC data. It also enables you to lay your PLC data with information from other areas of the enterprise, such as your ERP data. You can directly update, plant foreign information from the ERP. This is all just adding power to connect your whole enterprise. Ignition has the OPC UA module installed, again that's OPC UA server and client functionality. So Travis, you go, as you said, back to the beginning with us. Could you just at least briefly explain what OPC UA is, and why the OPC UA module is beneficial in connecting the enterprise together?
Travis: Yeah, absolutely. There's thousands of devices out there in the real world, and every device has its own protocol and its own way of working. And so it's... For an HMI/SCADA and MES company, at the beginning, it's a very daunting task to come into the market and to think, how are we gonna be able to connect to all of these different devices? Are we gonna have to build device drivers for all these different protocols that exist? And so luckily, there was a standard out there, which is OPC, and that standard allows other companies and organizations who have that knowledge of those protocols, and those devices, whether it be the manufacturer of the PLC, whether it be just another company like Kepware, or Matrikon, they've built a product that has these drivers in place, and then they expose those PLCs, those tags, into a standardized format, which is OPC. This allows us as an application to connect to any OPC server that's out there, that knows the standard. And then we can technically work with any controller that happens to exist in OPC. And we've found that to be true, because Ignition has one built-in. We have Kepware, and Matrikon.
Travis: We have thousands between them, thousands and thousands of drivers that we can work with, and there are also special OPC servers that are provided by manufacturers. So it's a very good thing for us as a vendor to be able to have OPC UA 'cause it's a standardized way of communicating to these different controllers.
Don: Thanks, Travis. That summarizes it very well because if you look at the bottom line with OPC UA, SQL connectivity, Java, Ignition allows you to connect all of the systems in your enterprise from SCADA to ERP, and the device is really critical to have that functionality. You can build a sort of automated system for any department that you want to. So instead of trying to get by with just some pre-packaged solution or trying to make incompatible programs work together, basically you have the ability to just build exactly what you need, and you have the ability to build it quickly. So you start getting the idea that Ignition could bridge the gaps between IT, controls and the C level inside your organizations and give each of them... Like you talked, Jeremy, about programming to different roles. Each of the roles in the organization can have what they wanna have to do their work, but it's part of the overall platform. So to give you a little idea, here are some things, just a brief list of non-SCADA Solutions you could build with Ignition.
Don: You can read the list: Alarming system, centralized data login, centralized CRM systems. The entire CRM system for Inductive Automation is built in Ignition. That's all we use. So you've got documenting systems, executive dashboards, and I know you guys have worked a lot with executive dashboards at Sherwin. So I think the possibilities are wide open. That's what we're trying to communicate. As you look at it, as what you've done at Sherwin, you guys also did a session last year at the Ignition Community Conference here in Folsom about developing executive dashboards. So just kind of pulling that out maybe as an example about how your company takes sort of a systematic approach. They look at the whole systemic challenge and put the process together. So I kinda wanna open this before we go into Q&A to a final thing. We could talk a little bit about executive dashboards and maybe also any final comments you wanna make about how Ignition has fit into your unique processes at Sherwin, how it's contributed to the enthusiasm for building. So it's kind of a... Talk about executive dashboards and we're bridging any final comments, and I'll call on you, Jeremy, Ryan, and then also Dan on this one.
Jeremy: Okay, going back to the systemic approach, and we really tried to take a look at... We have a number of different systems at Sherwin-Williams. There's manufacturing. There's ERP business systems, maybe lab systems, but they're all inter-related. Each one has an effect on the other, and going into that leads back to our roles. We tried to extend what was a traditional SCADA system where there was real-time plant equipment information and how can we start recording productivity? What's happening in real time? How can we start showing long-term trends? And that's how we started to extend it into our dashboards and growing that information is that using templates we can focus on individual areas. What does the operator need to see? Quickly develop and get displays, so operators on the plant floor have feedback on whether or not they're having a good day or bad day. Do they need to react to that, do they need to get more information from their supervisors to do their job and perform well. And there's also... It allows us to make intelligent decisions at the higher levels too, supervisor management position 'cause we could bring this data then we have true real-time data instead of emotional decisions, make sure that we're meeting our goals and productivity across the enterprise.
Don: Cool, thank you, and Ryan, your thoughts on that too.
Ryan: Well, in terms of dashboarding and in terms of what we presented last year, a lot of these organizations and especially Sherwin-Williams itself, you know that you have a core group of individuals who are gonna make decisions within the facility, whether it be a site manager all the way down to a supervisor and then eventually to an operator or floor technician. And basically dashboarding or opening these avenues of communication across your entire site like for example as Jeremy was mentioning, you have your lab and then you have your distribution or manufacturing and all of these other pieces that have different processes that they do in order to complete their job, but all of them go... All of them are tied together in the fact that from start to finish this is how we get some sort of product or our product out the door. So when you talk about dashboarding, being able to watch the start to finish of basically a product, your product coming out the door allows you to make those critical business decisions in a very timely manner that you need to get more product out the door.
Don: Thanks Ryan. Dan, how about any wrap-up thoughts from your side?
Dan: Sure. And just to kind of extend on what Jeremy and Ryan said, they've spoken about these executive dashboards. Those are kind of the culmination, I think, of a couple of years work as we kind of built this enterprise system. And how did we get there? We didn't just come right in and say, "We're gonna build this gigantic system that goes everywhere." We started with these smaller purpose-built solutions that were very database-centric, and I think that's very key to why Ignition was so pivotal to our success is that we're able to use the database to make repeatable solutions that once we did it once, we're able to repeat over and over and over again, keep bringing back value with very little additional investment. Basically, we were able to identify those gaps that you mentioned before and continually bring more information to our plants. There was a slide before they had that puzzle piece, and I think that that metaphor has worked very well for us on multiple levels. First off, we're to find those gaps of information with our customers and bring together business intelligence controls, existing legacy business systems, but also fill in that gap for us as IT developers that bring together the webwatch client's database connectivity, OPC servers, data logging.
Dan: All of those... All that software exists already. And there's a lot of options out there for connecting to database log and OPC getting a device tracker, but nothing else out there has really brought together so seamlessly and made it so easy for us to use, to do these things quickly. So when you talk about building enthusiasm, I think all of us are motivated by the fact that we can go to a site and say yes, very rarely do we have to say no, we can't do that. And I'm like, can we say yes and deliver, but usually if we go for a week to make a trip, by the time we leave, they already have something that they can start playing with and getting us feedback on. I think that's really kind of helped to keep us motivated, we've received great feedback and also just been involved with Inductive Automation, as they keep adding more features that allow us to keep being creative and keep being optimistic about it for the future.
Don: Sure, thanks, I appreciate all of you guys. We have a few questions here, so just a couple of things I wanna say before we move into the Q&A, just to kinda summarize, when you're working in Ignition, you've gotta stop driving endless development time, you can see all of these tools and how they help out. All of these things make Ignition an ideal development tool, not just on the plant floor, but really and truly across your entire enterprise, and I wanna just come back to the theme of build anything, if you'd like to read more or watch more about how to build anything with Ignition, go online to ignitionbuild.com. We have a lot more content there that's focused on the development features of Ignition, including a white paper that covers a lot of the topics that we've talked about today. Also ready to try Ignition for yourself, if you haven't already, please download it, it was already mentioned there's a full version there for free, you got two-hour runtime, you just reset, develop whole projects, and try before you buy. With Ignition, that's always there for you. I don't wanna skip the opportunity to always mention Inductive University, it's an online training service that offers Ignition courses for free, there is one to five-minute video training, and then challenges to test your knowledge, you can earn Ignition credentials and get prepared to pass your certification tests.
Don: So check out inductiveuniversity.com. And again, it's free, so take advantage of it, it's a great tool for new people understanding this or people who already are just trying to get more information on specific functionality and videos that support that. So now let's get into, I would like to get into some Q&A, 'cause we got some great questions. I wanna rush through so we can get some time with Q&A at the end. So let's move into the questions, starting with the first one, can Ignition be used... I'm gonna throw this your way Dan, can Ignition be used to query edit records in SQL Server, also can it use SQL tables to store recipes uploaded and download them to a PLC.
Dan: That's pretty much 90% of what we use Ignition for. We have the screens, but the database is the key, I mean, Travis showed how we can build screens and templates and push it out, and Jeremy mentioned with Python, and we really dug in deep, we have the database build a lot of our systems for us, we build screens dynamically, we build text dynamically. So the answer to this is yes, you can do just about anything in the database using JDBD that you can use... That you're probably used to using with any other software.
Don: Great, we've got just as many questions as we can, so thank you for a good answer, now, I'm gonna go to Jeremy and to Ryan with this one, how do you use the designer... Mrs. Ross asked this question, designer in a Dev Test Production cycle environment, you need to test the screen before releasing to the production environment, that kind of thing. So start with you, Jeremy.
Jeremy: Yeah, we've set up separate development environments, and it depends on what type of system we have, if it's... Some of our systems are primarily historical read-only data, so those are actually somewhat simpler because we can actually have a Development Gateway that connects to our production data and we can make changes in different windows and build new templates, test them out and then migrate them over easily, very simple with Ignition to migrate them over to production Gateway. As far as the SCADA system here, what we have is, well, we also have a development PLC set up and using that environment, we'll test the interoperability as far as writing values to the environment.
Don: Good, great. Ryan, your thoughts on that?
Ryan: Well, it's something that I'm gonna allude to what Dan mentioned earlier about the two-hour trial, I know that some facilities might not have the ability to think that they can purchase a license, that this is just gonna be a dev environment, just remember the two-hour trial comes in very handy when you're doing dev work, especially if you're able to point at any sort of production data, whether it be read-only or something that you're just looking to see what it looks like before you put it out there. Just remember the two-hour trial comes in very handy, you can do all the things that you can do with the license, in those two hours.
Don: Great Ryan, thanks. Okay Travis, Karen has a number of questions. I'm gonna take the first one and Karen if we don't get to all these questions, we will follow up afterwards, but this question says, Do you have a tool kit so I can create a custom module for the Ignition platform, and then she has some other ones, let's start with that.
Travis: Yeah, absolutely. So that's one thing that's probably way different with Ignition from others... Our competitors, that we do have, we're very much open architecture, we have an SDK, a tool kit from Ignition where you can build modules, it's a free SDK, you can download it from our website, you programme in Java using Eclipse to do that, and you can make any... You can extend Ignition any way you want by adding a driver, a component, a new workspace, new scripting functions, you name it, you can add it. It is available.
Don: That's great. So we'll pick a couple more questions here with the time we have, but like I said, we will follow up and make sure we get to all of them afterwards, we're trying to stay close to our time, but let's go a couple more here, and I'll take it, another one of yours, Karen. Is the cloud-based template storage global or only for my application space for my company?
Travis: So that's a good question. There's actually two spaces, there's a public space and a private space, so you can log in to your account, have your private module or templates only you can see, and you can also share it with your company, but there's also the public space if you wanna put it up there where anybody in the community could look at that template and bring it into their system.
Don: Cool, so we got time for maybe another question here, so I'll throw this one your way, Dan, does Ignition have a connector for SAP. Has Sherwin-Williams done any Ignition to SAP connections?
Dan: No, we don't have SAP directly, but again, as long as you have access directly into those tables, I love to use staging tables, sometimes the ERP is kind of locked up a little bit, but any basic database access should be able to get in there also, I would imagine there's a lot of services exposed, they use service-oriented architecture and integrate with a lot of those enterprise systems. Ignition also has a web services module. So basically, there are a lot of different integration parts to get in there, so usually if your IT department has security concerns, there are multiple ways to get around that.
Don: Okay, great. I think the web services module answers the question beyond it, hopefully for Karen that there's a way to get around and a way to make it work. Okay, so here's another question. Maybe just, I think this will be our final question. So does Sherwin-Williams use a mobile viewer, smartphones? How has this worked out? Jeremy you wanna comment on that?
Jeremy: We've done quick prototypes of that, we had... Some of our users... Actually it was very simple, as far as exposing in a mobile, especially the iPad, we don't have a large user base that's more of a corporate device issue with us right now, but for some of our power users, we were able to just spin up a gateway, copy it over and set up the mobile module and it was a matter of an hour or two hours to expose our applications.
Don: Yeah, great. Okay, I think we're actually a couple of minutes over our time, but I really wanna say that I really appreciate all the time from Sherwin, from all you guys, Ryan, Dan, Jeremy, Travis, thanks for your time. As I mentioned, also, we'll follow up and make sure we get to all... There's a lot of great questions today, we really appreciate the participation of the audience in today's topic, apparently, it's of value to you, so that's what we're trying to do with webinars. We're concluded with today's webinar. Have a great day. Thank you very much.