The New Ignition v7.9
See, Maintain, and Manage Your Enterprise With Ease63 min video / 51 minute read View slides
About this Webinar
The new Ignition version 7.9 raises the bar for security, performance, and ease of use for the industry, and it removes all the friction that users encounter when developing projects with traditional SCADA packages.
The Ignition industrial application platform features a completely revamped Gateway with an intuitive user interface design, robust troubleshooting features, and an improved ability to share information between Ignition Gateways.
In this webinar, take a guided tour through Ignition v7.9 with Inductive Automation’s Co-Directors of Software Engineering Carl Gould and Colby Clegg, and Chief Strategy Officer Don Pearson. Discover exciting new features like the fully rebuilt Gateway Status section, Distributed Services on the Gateway Network, and many user-requested improvements.
Learn about all this and more:
- How the Distributed Services feature unlocks new architectural possibilities
- Why it's now easier to get status information at a glance
- How we've made the logging system more powerful and easier to use
- How to use tags from Ignition installations in different locations at a central site
- Why it's never been easier to identify trouble spots and resolve system issues
Don: Well, good morning everyone and welcome to today's webinar, The New Ignition, version 7.9C, Maintain and Manage Your Enterprise with Ease. My name is Don Pearson. I'll just serve as the moderator for today's webinar. I'll introduce our panelists in just a couple of minutes. Quick look at the agenda, first off, we'll have an introduction to Inductive Automation for those who happened to be new to our software Ignition and to our company then, I'll introduce our panelists, then we'll have a discussion about the new features of version 7.9, we'll look at status and diagnostics, attributed services, and of course, the community requested features that are included in 7.9. As always, we're gonna have a Q&A session at the end of the webinar.
Don: A little bit of company background for those who are new to Inductive Automation. We've been founded in 2003. From day one, we've been an independent company, there aren't any outside investors, and very pleased to have the response we've had from enterprises around the world that have chosen Ignition for their HMI, SCADA, MES, and IIoT needs. So far, it's been installed in sites in over a 100 countries. Our Integrator program has over 1400 integrators. And our revenue, since the launch of the Ignition platform in 2010, revenues have continued to grow at about 40% to 50% annual growth rate. If you want more information just on the company itself, just go to inductiveautomation.com and go to the About Us section and you can see anything you want about the company, more history about the management team, anything you might wanna know there.
Don: As I mentioned, lots of companies use around the world, and those thousands of companies happen to include 44% of Fortune 100 companies and over a quarter of Fortune 500 companies. As far as industries, really because it's a platform, can be used in virtually every industry. Some of our top industries are oil and gas, and water and wastewater, food and beverage, automotive, but also government, transportation, packaging, and really the list goes on in terms of where it's been utilized. Just to set the stage for today's presentation, I just wanna explain just a little bit briefly about what Ignition is. We describe it as an industrial application platform, and it really is the world's first database-centric, web-deployed, 100% cross-platform unified HMI, SCADA, IIoT, and MES solution platform.
Don: A couple of things that I think I need to at least emphasize about it as to why it's so unique, first, I mentioned, it's web-based deployment and it's cross-platform, as I mentioned. The unlimited licensing model really is critical, I think, particularly when you start doing large deployments, because we have unlimited tags, unlimited clients, unlimited device connections, unlimited concurrent designers. We really take an unlimited approach so that we basically give you the freedom to create and innovate the systems that you need to meet your organization's needs or your customers' needs. It offers security and stability, and its modular architecture makes it easily expandable. I think it's really critical to know that you basically have a platform there and then you take the modules that you need on top of that. It's made for rapid development and deployment and offers real-time control and monitoring, and these features actually and a whole lot more, but as a base introduction, really set it apart from other SCADA and IIoT solutions.
Don: I think you need to look at it as sort of a communications hub. It's built for connecting all of your industrial devices, your databases, your business data and business applications together in one central location, so you have the ability to do what you need, you can connect touch panels and databases and PCs, mobile devices and PLCs and RTUs and flow meters, doesn't matter, you can connect to those devices. It also connects them to LIMS and MES and ERP systems, Web Services, MQTT, and almost any OPC server. So the whole idea is that Ignition sits in the center and gives you the opportunity to make whatever connections you need to build out that enterprise and have... Sort of plan for and field data all the way to the top levels of the enterprise connectors.
Don: It's a modular software platform, and it offers a very high degree of customization. So it's developed in a modular way so that all of the Ignition modules work seamlessly together. You never need to shut down your system to add functionality, and Inductive Automation, as you see the orange level there on our software stack here, makes these core modules for Ignition that sit on top of the platform for HMI and SCADA needs. And then we have third-party modules that are created by strategic partners, Sepasoft and Cirrus Link, and they make these modules for an MES module suite and IIoT module suite that work together on the Ignition platform. So that's a quick brief introduction. Certainly, if you wanna know more, we can do whatever you need for the new people, but the subject today is really Ignition version 7.9, and our presenters are Carl Gould and Colby Clegg. And Carl and Colby are the co-directors of software engineering at Inductive Automation. They've both been with the company since day one, and they really are the ones who developed the Ignition platform along with their team. So with that, I think I'd just like to turn it over to, I guess, to you, Carl, and you can take it from here.
Carl: Our latest release is Ignition 7.9, which has features that address both current needs as well as lays a foundation for future growth.
Colby: In 7.9, we've focused on three main areas. First, we've completely revamped our status and diagnostic systems for the gateway in order to lay a foundation that provides for more efficient troubleshooting and problem-solving. Next, we've introduced a number of new services that help the way gateways to interact together called the Distributed Services, and then finally, of course, we've included a number of features that have been requested by you, the community, so we're gonna dive into each of these in more detail right now.
Carl: So to get us started, let's take a look at the new status section of the Ignition gateway, and I think the best way to do this is just to take a tour through some of the pages, so let me switch out here. Alright, so here we are. Now, the first thing you'll notice is that in Ignition 7.9, you have to log in to the status section. This is because the new status section contains so much new information, some of it may be of a sensitive nature. And when you first land here, you're gonna notice a number of things right off the bat, and one of them is that the whole look of the whole Gateway has changed. And so what we did with Ignition 7.9 was really take a step back and look at the Ignition Gateway web interface with a whole new set of eyes. What we really wanted to do was to sort of think of the ignition process itself, almost like you all think of your industrial processes.
Carl: So we wanted to think about what are the KPIs that people need to monitor as they run ignition? What kind of alarm conditions can we automatically detect and present to the user? What's the most important information that people need to see at a glance when they're running their ignition gateway? And how quickly can we help you arrive at figuring out the root cause of any issue that you might find? So to that end, we've introduced this whole new section with all these new pages, and it starts here at the overview page, where you really get a great at-a-glance sense of what's going on in your Ignition Gateway. So immediately we can get some quick reads on performance information, we get everything we need to know about what this gateway is configured to do. Is it configured to be a redundant pair and is that working? In this case, you can see that the redundant peer is missing, so that's an issue we might need to deal with.
Carl: Is this gateway hooked up to a broader gateway network, which is something we'll talk about a little bit later. And if so, what kind of performance metrics are we seeing there? We've got a bunch of information about environmental conditions in which the Ignition Gateway process is running. This is the kind of information that previously you probably would have needed to gather from maybe four or five or six different places to try to gather all this information to get this really good understanding of what's going on with your gateway. Now it's all brought in here into one place, you can see it really at a glance. What's my gateway doing? What's configured, what kind of connections do I have? Which ones are working, which ones aren't? That's the kind of information that we get right away on this first page.
Carl: So going a little bit deeper, let's take a look at the new performance page, because troubleshooting performance is a big part of what people need to do as they're working with an ignition gateway that they're building upon and scaling. And so here in the performance page, we can get quick reads on the gateway's performance metrics, as well as a historical view of the last 24 hours of the CPU and memory usage of the gateway. This is a really useful ability to be able to look in the past. It can help you correlate CPU and memory usage to events, anomalous events that may have happened in the past. And if we scroll down here, we've got this new number. This is a new concept that we've come up with as part of Ignition 7.9 that we call the system response time. What this is is a measurement of the time delay between how... So what we do is we ask the computer to run a task very quickly, and then we measure how quickly the task is actually being run. And then what we display here is the difference in milliseconds between how quickly we want it to run and how quickly it's actually running.
Carl: So zero would be the ideal number here, right? Meaning that you're keeping up your timing perfectly well. And so this is a great way to get a feel for whether or not the computer that's running Ignition is overloaded or not. We see a lot of systems that are configured on virtual machines that maybe aren't provisioned quite correctly. And so we're trying to use pages like this to gain insight into maybe the cause of what's going on with any kind of performance issue. Along the lines of performance, if I jump down here to the threads page, the threading page gives us a view of all the different concurrent activities that are going on inside of an Ignition Gateway. In 7.9, we now have those activities classified by sub-system. And what we can do here is we can look at a chart of the CPU usage of the gateway broken down by sub-system and also broken down by scope.
Carl: So you can see of all this gateway's CPU cycles, what percentage of them are being caused by client requests, what percentage of them are being caused by things the gateway is doing on its own? And then over here in the bar chart, you can see that in this gateway, although we're not using all that much CPU, device communication and OPC communication is causing the bulk of our load. This can be a really handy tool for troubleshooting, but also for planning for future scale out. So if you're looking at a system that is overloaded and you're planning on maybe breaking that system apart, this can be a really powerful tool that would let you intelligently decide maybe how you wanna try to break your gateway apart. Alright, so next up, I wanna take a look at the logging system.
Carl: Now, logging is really, you could say the lowest level and perhaps most important diagnostic tool in the ignition status arsenal. While we've designed all of these pages the best we possibly can to try to give you, the user, the information you're looking for without delving into the logs, at some point, you'll probably have some sort of issue where you've exhausted the design of these pages and you'll need to get into the logging system. And the logging system in Ignition is organized by logger names of which there are hundreds, and dealing with the logs in the past has been a little bit of a dark art of knowing which logger names to deal with. And so, one of our major goals in the design of Ignition 7.9 was to change the logging system to try to make it easier to use, more accessible, and make information in the logging system easier to find and deal with.
Carl: And so to that end, we've added a new dimension of information into the logging system that we called Context Information. And you can see on all these logged messages, some of them have these little magnifying glasses next to them. And the magnifying glasses contain information about contextual information that give you insight into the context in which this logged message was generated. So for example, if I wanted to find any log messages associated with a database connection, I could simply search for the database connection name here, and it would filter all the log messages to only look at messages generated in association with that database connection. Or in addition to searching, I can also use that contextual information to set logging levels. As a different example, I could... Let's say I've got a whole bunch of clients running, and so one of the clients is behaving incorrectly in some way.
Carl: And so I wanted to sort of cross-cut through the logs and turn on any loggers that that client is touching, turn them on to trace. So what I could do here is simply use this context key called Session user, and when I pick a key, it's going to fill in all of the applicable current values that work for that key. So let's say Joe Operator is a name of one of my users logged in to my clients, if I set this to say, trace level, the logging system has now been reconfigured so that any logged messages that were generated in association with this specific client will now be put on trace. So we may have just affected dozens of logger names that are independent of the client system, but what this lets us do is sort of look at the logs with a whole new sort of a new light, and find information that would have been very difficult to find before, because you would have had to go and affect many different loggers.
Carl: So you can see my logs are filling up now with information involved with that specific client. And you can see each of these log messages now is pertinent to that specific client and so they're all annotated by the contextual information that have to do with that client. Okay, so let's take a look at some of the other pages that we have here. Now, I'm not gonna walk through each one of these pages, because it would take the rest of the morning, but let's take a look at a few of them. So in general, what we've done here is we have added a page for each module and subsystem that exists inside of Ignition. And then on each page, we've taken a fresh start to what kind of status and diagnostic information you might need for that specific subsystem. So for example, here on the gateway scripts page, I'm gonna get a list of all of the different gateway scripts that are configured. When did they last run? How long did they take? If they errored out, what was the error? I can get details about the error. There's all kinds of useful information here that previously probably would have only existed in the logging system.
Carl: And speaking of the logging system, we're getting back to it here. So all of these pages also have a pre-filtered view of the log system, so that if I wanted to look at the logs pertinent to that system, I don't have to do anything more than simply visit the page and I get a pre-filtered view, all made for me there. Performance information is also baked into many of these pages. So let's go down to the devices page where we can find all of the device connections we currently have configured, and let's take a look at one of these devices. So when we drill down into the device details status page, we're gonna get really detailed performance metrics for that specific device. So we've got a histogram of request timing, so we can really delve into the statistics of how long each request to that device is taking, as well as this number that I really like, 'cause it gives you a really quick read on whether or not your device is keeping up, which is what you call the Load Factor.
Carl: This number is calculated simply as a ratio of how long all of your requests are taking, compared to how quickly you're supposed to be running them. So in this case, you can see that this device is overloaded, because the load factor is over 100%, which simply means that this device simply can't respond quickly enough to keep up with the timing that we've asked of it. This is a pretty common type of configuration issue that we see, and so we're excited to have status pages that really give people the information they need to be able to see how they need to change their configuration in order to let their system keep up correctly. There's also a brand new functionality baked into some of these pages, because again, we really took each system and redid it from the ground up. So just as an example, if I go into the store and forward status page, and take a look at one of my store and forward engines.
Carl: I've got new abilities to deal with quarantined information in here, which is something we didn't have before, so I can retry information, but I can also export it and import it. This is something that is often a useful tool when dealing with quarantine, to store and forward information, but my point is each of these pages just has a lot of depth to it, so we made everything look a lot better, but more importantly, we really made sure that all of the functionality and information you needed to deal with maintaining and troubleshooting all of these subsystems was immediately at your fingertips.
Colby: Alright. So with that, let's go on to the next section. And we'll go on and look at the so-called distributed services. So, distributed services are mechanisms to help multiple gateways work together. As customers build out their architectures, it's common for them to end up with multiple gateways, either inside of one plant or across multiple sites, and they want to be able to combine data or access data more easily, and that's what some of these services do. First, let's start by taking a look at the Gateway Network, which we introduced last year as part of the Enterprise Administration Module. So the Enterprise Administration Module was a feature that helps administrate these multiple gateways, manage backups and status information and so on, and so the Gateway Network is what enabled that by connecting multiple gateways together in a secure and efficient way. It's built on a common web technology, such as HTTPS and web sockets, and so it's firewall friendly and secure as well. Additionally, the Gateway Network allows for some more advanced configurations, whereby gateways can access other gateways through an intermediary. So in this example, we have gateway A that would be able to access information on gateway C through the intermediary, which can really facilitate some network architectures that previously would have been rather difficult.
Colby: So in 7.9, we've got three primary features that we've introduced. The first one is what we call remote tags. This feature is pretty straightforward. If we have tags in gateway B, we can add a remote tag provider in gateway A, and use those tags as if they were local, essentially. So why would you wanna do this? So let's say you've got three self-contained Ignition set-ups, and maybe they're in different parts of your plant or at different remote sites, and you wanna set up a central monitoring application that is a dashboard of KPIs, for example, from all of your sites. Once you set up a Gateway Network connection to all of them, you can easily create a remote tag provider and bring them all together as one cohesive tag space. The data can be mixed and matched on the screen, you can access tag history and alarm status, and so on. And so it really gives you the ability to create a type of application that would have been pretty difficult before.
Colby: A different application of this feature is in a situation where you have a gateway that's grown maybe beyond the capacity of the system. So for example, you've added more and more devices, and more tags, and we love to sell Ignition as an unlimited platform, which is true from a licensing point of view, but there's a physical limitation to everything, right? So when you reach a certain number of tags, your gateways tend to get overloaded and you'd like to try to deal with that. The easiest way would be to split off the load into multiple gateways, but this would previously create a problem where you now have two complete systems and you need to try to integrate them in some way. That could be a little bit difficult. With the remote tag provider on the distributed services, you can create a third front-end server that has access to both of those gateways, thus creating a virtual address base that is coherent across the entire application you've built.
Colby: Also now, your view applications and your client applications can talk directly to that front-end server, splitting the load of those as well, so allowing you to scale up to a greater number of clients. If we went further and developed this idea into a more robust architecture, you might do something like add a load balance in front of your view servers, creating multiple layers of responsibility: IO servers, front-end servers, and then ultimately your clients. And in this picture here, we've gone one-to-one, but it certainly doesn't need to be like that. If your system is very heavy on IO load, for example, say you've got millions, tens of millions of tags and you're trying to serve up a couple of dozen clients, obviously we'd have quite a few tag servers perhaps going down to just a few front-end servers, or the opposite could be true, and you could be trying to support tens of thousands of clients, in which case you would scale up the front side. The important part here is that the front-end servers are only accessing the tags that they need in order to support the clients, so they're much lighter weight and the heavy work is done over on the remote side.
Colby: The next distributed service we've introduced is remote historian. Now, hopefully everyone knows that Ignition will store tag history into a sequel database. This is a feature, it's used by virtually everyone to power charts and graphs and reports and other analysis. It makes it very easy. Just a few clicks to start logging history to a database.
Colby: Well, a common use case is to gather history from many locations and store it into a central database. Often another Ignition will live centrally and have central monitoring or reporting applications. So as this diagram shows prior to Ignition 7.9, the way to gather this data centrally was to have each location connect directly to a central database to store the history. And this was great from the point of view that by leveraging the power of the database, we can make this architecture possible. People have been doing this for our entire existence as a company. But there are a few downsides. This situation works fairly well if the database and all of the Ignition gateways are local, but when you start to add some distance between the sites, that direct database connection starts to break down. And we'll look at these problems a little bit more in the next slide. So what we've done is with the remote services, we've offloaded or inverted the picture a little bit. So now history can flow through an Ignition gateway and then to the database.
Colby: So this improves a few aspects of the problems I just mentioned. First of all, as I said, direct airways connections can be fairly inefficient over a remote connection, but also security can be concerned having direct database access over a WAN, or even worse, you're trying to collect this over going at some point through the public Internet could be very tricky, and might be a little bit of a headache for your IT department. Also, security at the database layer, while very flexible, is typically in a specialty of its own. So by going to this model, where we're leveraging the security and the configuration of the Gateway Network, we can then secure the database in one central location and leverage the more application-specific features of Ignition, a little bit more user-friendly for the Ignition Admin to create a secure architecture. As I mentioned, this is much more favorable for high latency distributed connections, so applications. And so we're seeing a lot of customers who are collecting data from very remote locations. This is after all the heart of the Industrial Internet of Things, collecting, accessing data over vast distances. And so this new mechanism is dramatically more performant in this regard.
Colby: We've run a few tests where we've compared direct database connection to this remote historian feature, and on a local network with virtually no latency, 10,000 tags being stored, we've seen a dramatic boost in the reduction of the size of the data, so that's great. It doesn't impact the local connection too much because usually bandwidth isn't a problem. But when we go out to something a little bit more remote and introduce a little bit of latency and maybe some more cost associated with the bandwidth, then things get really exciting. So if you take that same example and inject 30 milliseconds of latency, which honestly for a cell or satellite connection is unrealistically low, so this is actually a very good situation for those connections, we see over an 80x, 8000% improvement in performance. An application that, in this example, what took 11 minutes now takes eight seconds. That's dramatic, but if we go just a little bit further, what would have been previously impossible is now both possible and really, very effective. So finally, the third service I'd like to talk about today is the remote alarm notification. This gives you the ability to configure tags on one gateway and have their notifications be distributed through an alarm pipeline on a different gateway.
Colby: So this can be very useful if you need to distribute alarms from multiple locations or installations, but you don't want or can't administrate the actual alarming hardware at each location. You can have your SMS or voice hardware setup centrally and then leverage that from all of your different gateways. Or perhaps your remote locations don't have your full user rosters. Perhaps your users and your schedules and all of that are configured centrally, and a particular user needs to be able to receive alarms from any gateway. This feature allows you to take advantage of that. The alarms that are generated at the remote sites can be distributed through the central gateway to those users, acknowledgements flow back to those remote sites, and everything acts as if you were essentially working with one coherent system. So there's a few ways to also leverage this feature. The pipelines configured centrally can be leveraged directly from their remote tags, so you really don't have to do a lot of work to configure each site. You don't have to create new pipelines over there, you can just point the tags to the central server, or on the other hand, there is the new remote notification profile, so you could configure the pipelines remotely.
Colby: And that central notification can play a role in a much more robust notification scheme, so there's a lot of flexibility here. And I think it's also representative of what we've done across the board, where we have these fundamental building blocks that just provide you with more tools to create really effective architectures. One thing I wanted to do, so we've discussed these features in some detail here, I don't wanna demo all of them right now, but I think it's really interesting to see them in action to some degree. It's one thing to talk about it, but then when you see the simplicity and the way that you can leverage these, it's pretty impactful. So I wanna do a quick example of the remote tag system, just to show how easy it is to get up and running with this feature. So I have a gateway here that I'm calling my central headquarters, and I have another gateway that I'm not gonna show that I'm calling my remote site. But currently, I don't have any kind of connection set-up between them. To make this demo a little bit easier, I've set up the remote site to be more permissive than we would normally do for security, for example, to just allow any incoming connection and then to allow me to use the tags remotely. But outside of that, I'm gonna go from scratch. So I'm gonna come over to configure and the first thing I'm gonna do is actually set up the Gateway Network connection.
Colby: So in this case, I go out going from the central to the remote site, create a new connection, and once that's established, I can now go, and this gives us a communication to each other and I can go and configure all the services I want on top of them. So next, I'll come down to the tags, real-time section and create a new real-time tag provider. I'll select the remote tag provider over the Gateway Network, and I'll select my remote site. I'm presented with all the high providers present on that remote site, and I'm gonna choose the default provider. Once I save, it's available just like my normal default internal provider and I'll come over to my designer which is running on my central gateway. Now under all providers, it shows up right next to it, and I can browse, view and utilize however I want all the tags as if they were local. Now the important thing to remember is that these tags are fully executing on the remote system, all of the history, the alarms and the values are executing over there, so on my system here, I'm only accessing these few values that I happen to have subscribed right here, but I can do whatever I want.
Colby: Now I can come in and create a chart that will show the real-time values, take something that's being stored, drag it over. The history is being queried over the Gateway Network in real-time, I don't have to have direct database connections, and all my security was configured in a very simple application-specific way over there. I can go further on how in my central gateway, I have a few other tags and I can show, for example, how easy it is to mix and match data from multiple gateways. So in general, all these features integrate with each other very well. If I do an alarm status table, for example, I've got alarms being generated from the remote site combined with the alarms on my local site, all the sites that I have access to, and then I've configured access to are able to seamlessly integrate their data together. So it's a very quick example, but again, these are building blocks that we've tried to make it as simple as possible but are gonna have a huge impact on the way people build very robust and amazing architectures.
Carl: Alright, and last but not least, this brings us to the community features, so for those of you who don't know, we have a section on our website called ideas.inductiveautomation.com where you can submit feature requests and ideas to us for future improvements to Ignition and you can vote on other people's ideas so this helps us organize and categorize requests. And Ignition 7.9 contains a number of new features that came from this idea support so I wanna quickly talk about a few of these features and what they mean. So the first step is vision global templates which is an idea that's sort of been floating around for a while, and it's a pretty simple idea. The basic idea is that you can now define templates for the vision module in the global project space which means that those templates will be available in all of the projects that are on your gateway, so this can be a real advantage for users who have gateways with many projects on them to be able to create a consistent set of templates that can be used across all their projects. And it also plays very nicely with the enterprise administration module which would then allow you to automatically synchronize those global templates amongst all of your agent gateways which would allow you to create a set of standardized templates that would be synchronized across the entire enterprise.
Carl: The next one is, this was actually our top most voted feature which is proper support for multi-monitors for vision clients. This is a pretty exciting one for me, I'm excited by how it's turned out so I wanna talk about it for a few minutes. So the general idea here was that it's very common in operation centers to have work stations that have multiple monitors, four, six, eight monitors. And prior to Ignition 7.9, in order to run the Ignition on all of the monitors, your best bet was to launch a separate client on each monitor which worked okay, but it had some drawbacks to it. You had to log in to each one separately, you had to update each one separately, it was clunky to the different client tags so it's sort of difficult to coordinate between all these clients. So now with Ignition 7.9, you're able to launch a single vision client to one of the monitors, log in, and then spawn additional client frames to all of the monitors on the system.
Carl: And so all of these additional frames are logically part of the same client which means that they will share log in, client tag information, and it's pretty easy to coordinate navigation between them. So I'd like to take a quick look at what this looks like in practice which of course is a little bit difficult on a webinar because obviously, I'm on one monitor, so we're gonna use our imagination a little bit and pretend that this one monitor is actually four monitors just by dividing it into halves. So once I log in here to my first monitor, I'm able to open up additional frames on all the other monitors, and so the key takeaway here is that these additional frames, which on a real multi-monitor situation would be full screen and obviously on different monitors, but the different monitors are all part of the same logical client and yet can operate independently from a navigation perspective. So if I go over here to this monitor, if I execute swaps and open pop-ups on this monitor, they all stay relative to the monitor that I'm operating on.
Carl: But at the same time, if I wanted to, say, have one of my monitors be an overview that then acted as a navigation hub for the other monitors, I'm able to do that as well. So if I wanted to click a button and do something on monitor four, that's also very easy to do. So this is a real advantage for those of you who are running multi-monitor setups in your network operation centers. Alright, so the next feature on the list here is called security zones. This is a feature we've wanted to include for some time, and the inclusion of all of these new distributed services in Ignition 7.9 really made this the right time to do it.
Carl: And so what this is is a new dimension for security for Ignition. So Ignition has always had role-based security, which means that security is configured for people and people have roles. The problem now is that you've got lots of different kinds of entities operating in your whole stack, and not all of them are people, right? So when your gateways are communicating with each other, the gateway is not a person, it's a machine, and so it's not really appropriate to assign it roles. So instead, what we do is we've defined this concept called security zones, which is really just a way to give a name to a segment of a network or an IP address or a host name, something like that. And then you can define security policies based on those zones. So for example, if you had a highly distributed setup with multiple tiers of gateways communicating with each other, you might wanna say that gateways from segment one only had read-only access to the tags on gateways from segment two, something like that. So that's how security zones would apply to multiple gateways.
Carl: But security zones is also applicable in the realm of client security, so you can imagine that, since it's so easy to launch clients from Ignition, you can web-launch them anywhere over a LAN or a WAN, you can find yourself in situations where your user may have certain privileges to do actions that are inappropriate based on your location. So for example, say you're the supervisor and you are on-site, well, maybe it's appropriate when you're on-site that you should be able to start a batch, but maybe if you are re-targeted in from a remote site, maybe starting a batch from 400 miles away is no longer appropriate, and so security zones give us that additional dimensionality to the security system to say, oh, yes, in order to run this command, I need to both be a supervisor and I need to be physically in zone A or something like that.
Carl: All right, ARM support. So this is an exciting one for us, so as of Ignition 7.9, we now have an official build for ARM. This is really great for people who are maybe playing around with Raspberry Pi's to be able to run Ignition on a Raspberry Pi, but it's also really being driven by the IIoT edge devices. So many of these edge devices are engineered to be low-power devices, and that usually means that they're running ARM architectures. And so now that Ignition has an official build for ARM, it really solidifies the concept that Ignition can really be installed everywhere on the network stack and the hardware stack, both all the way down to tiny little embedded things and up to big enterprise-class servers. All right, multiple license keys. So this is a feature that we implement in order to better support our community of third-party module authors. So we've transitioned our module marketplace over to the module showcase, and what we're doing here is we're really trying to give more and more autonomy to third-party module authors and just try to streamline everything for them.
Carl: And so part of this is giving them the ability to commission their own license keys so that when they sell one of their third-party modules, they're able to deal with licensing all on their own, and then if you were to buy a module from a third party, they could give you a key and you could install that license key into your copy of Ignition side by side with the key that you bought from Inductive Automation. And so there's a lot more features on this list, and this really goes to show the power of the Ideas portal. It really demonstrates that that portal is just a great way for us to gauge feedback and help us prioritize all sorts of features that are very important to all of you. So please continue to participate in the Ideas forum, it's definitely something that we value highly. And that wraps up our tour of the features of Ignition 7.9, so we really hope that you enjoy these new features. It'll be available for download today, so we invite you to try out the new release, and now I will hand it back to Don.
Don: Thanks, Carl. So we're gonna go into our Q&A here so everyone has a chance to get your questions answered. We have a number of them in the queue that Carl and Colby will look at. As I just mentioned, a couple other things that I would like to do just as we move into that Q&A. First off, there are some new people, I'm sure, that maybe this is an introduction to Ignition, so please take the advantage to learn about it directly. You can learn for yourself, you can go to inductiveautomation.com, download the full version of Ignition for free, and you'll be up and running in three minutes. So you can test it out, you can even build an entire project before you buy it. We're really interested in you having the opportunity to get some knowledge about that.
Don: Just to note about pricing, when you hear about new versions and upgrades, you might wonder how that affects the price, you can get all the pricing information you need. We're very transparent about that. Those of you who have been working with us for a long time know that. Go to the pricing page of inductiveautomation.com's website and all the pricing's there, all the modules, suggested packages are all clearly displayed. So we're pretty confident that you will see that Ignition's an excellent value and tremendous new functionality of 7.9, which you just saw today. Also, just to note, the upgrade is covered by basic upgrade protection. So I just wanna reiterate that you should always keep your upgrade protection, the Ignition license, up and enforced because, as you can see, with the new releases, they are packed a whole lot of new functionality and you just get it for free as you go forward. There's no change in price with Ignition 7.9.
Don: If you enjoyed today's webinar at all, I just wanna say there's plenty of free Ignition training available online on inductiveuniversity.com. It's a totally free online training service. There's 600-plus videos there. You can earn Ignition credentials. Over a million videos have been viewed by people and lots of people have been learning Ignition all over the world just at their own time, at their own pace. So you can sign up and start learning about Ignition at your own pace without any problem.
Don: So I just mentioned those things. I just wanted to mention those as we go into Q&A so that for new people, they know what access they have and where they can go, but in addition to that, you see our director of sales here and all our account executives. If you don't have an account executive, you can certainly just contact us, we'll help you get one. And as I mentioned earlier, if we don't get to all the questions today, we will distribute it out and have an account executive follow up and get whatever technical answer you need or more detail. And also, if you're new or you just wanna see a demo of a little deeper than what you got from Carl and Colby, by all means, call your account executive, find out when you can schedule a demo, and we'll take a deep dive with you and any members of your organization that wanna have a little mini tour of 7.9 or all of the Ignition's capabilities for that matter.
Don: With that, we're in our Q&A section right here. So I think I'm gonna start off by just asking one question here from the list and then we'll go through as many as we possibly can as we go forward, and I'll just ask the question. Carl and Colby, you guys have to decide who wants to answer or you can both chime in if you want to. So this is a question from Josh. Is there a module which will need to be licensed for a gateway to act as a remote tag provider? Would it be enough to just license the OPC UA server and drivers?
Colby: Great. Yeah, that's a great question, and I see a few questions already about licensing with the distributed services. So the way that we did this is that instead of making a new module or creating new additions, we simply integrated the services into the platform or the module in the place that was most natural and most in line with the functionality. So what that means is that in the case of tags, for example, in this question, you don't need to license anything else. On the server that is providing the tags, as you've rightly said here, you would license the OPC UA server and your drivers, create your tags and now, any other gateway would be able to access those because tag functionality is a fundamental part of the platform.
Colby: I see other questions here about, "Do we need the enterprise administration module to use these services?" And so as I just said, no, you don't. The enterprise administration module is a type of service built on the gateway network equal to these other services, so no, you don't need it. It serves this role for administration purposes but these other ones stand of their own. Another example of what I just said, remote alarm notification, for example, requires the notification module and the tag history functionality requires the tag history module. So it's fairly straight forward. And for everyone who has upgraded protection, it would be a direct upgrade, so there's nothing new or tricky to deal with on that front.cbf
Don: Great, thanks. Just a quick question here. "Is everything in the new status page live?"
Carl: Yeah, that's right. Everything is live in the new status page. The old status page had those selectors that would turn on and off live data but we got rid of that and now everything is live all the time on there.
Don: Okay, cool. This next question is a bit long. I'm gonna read it 'cause I think it's a relevant question that may apply to a number of people here. "Is it possible to pass on the SMS alarm message to a VoIP application like Skype and convert it into an alarm call? This possibility will generate tremendous interest from Smart City project managers because they have to manage a few thousand maintenance technicians to manage the city infrastructure. Human beings may miss an SMS message but a call is difficult to miss. Maybe if we talk to telco companies like Skype and WhatsApp, they will be very much interested. Please consider it on the wishlist and look into it.
Colby: Alright there's a lot here, and this is a great question. I'll start by saying, I'm not trying to knock the question, there's nothing here, I'm gonna say, that has to do with 7.9 but it sounds like, if you're talking about inter-weaving SMS and VOIP and so on, our alarm notification system has a tremendous amount of flexibility. If you haven't looked into the way the alarm pipelines work, the pipelines are basically a visual logic system for creating notifications. You should go to the Inductive University and check those out, because I think what you're really asking here is how to set up a way to use both of these methodologies and perhaps use one if another one hasn't worked correct or hasn't been acknowledged, so on and so forth, so there's a tremendous amount of flexibility there, so I'd look into that. And also I'd just say, because WhatsApp is so popular, we get asked about this a lot, WhatsApp does not have a public API, so unfortunate, because it is such a great way to connect to people, but they currently don't have a way that we can get through there.
Don: Thanks, Colby. So the next question is, "How does tag history work for remote tags? Is it possible to enable tag history at the central site for tags on a remote gateway? What licenses would be required for this, assuming we do not need store and forward? What licenses would be required if we did want to store and forward?"
Colby: Okay, so, again, as I said a few times, the thing about the remote tag system as presented here is that the tags are being executed on the gateway where they reside, and so the history functionality, in terms of storage, hasn't really changed. You can store... Well, the normal situation hasn't changed. You can store tags to a database, you can store tags remotely through our new provider, but the methodology hasn't changed. We do have features like the tag history splitter, for example, that would let you store history to multiple places, and so an architecture where you wanted to store data locally for a short period of time within Remote Leaf, forever or for a longer period of time, would be very easy to do like that. When we're consuming tag history, when we're using them on charts remotely and so on, the query is being executed through the gateway network, through the remote gateway, and then to the ultimate tag history storage where the data is residing.
Colby: There's a shortcut to that if both systems happen to have access to the database, but those are all just little details about how to get the best performance. So from a licensing point of view, as I mentioned, it is part of the tag history module, you need to have that module, although we do have a lower price point for query-only functionality, so the main price you see for the tag history modules for storage and for full functionality. And for just query-only functionality, you can license a lowered version of the module.
Don: Thanks, Colby. So the next question is, "In terms of multiple screens, which is amazing," Timothy says, "How does it affect my design process? I'm gonna have to pick a screen size during design based on my display monitor, but how does it affect my design template with multiple monitor systems?"
Carl: Good question. Okay, it really doesn't change anything. It's the same design process you would go through for designing for a single monitor, it's just that now you can open different windows on different monitors, but each monitor acts like a single client would. So for example, it's not like you have to design a window that is stretching across all the monitors. I guess I'm making an assumption that on a multi-screen system, the monitors are the same size, which maybe isn't a good assumption, but even then, it would work fine anyways because when you design an Ignition screen, you can use relative layout to have things adapt to different screen sizes, and so that would work the same. It would be just like if you took a client and maximized it on one monitor and then dragged it to another monitor and maximized it again, it's... Acts the same as that.
Don: Good, thanks. Okay, I think you already answered this one about the EIM module to use distributed services, Colby?
Colby: Yeah, right.
Don: Yeah, that's fine. Okay, then there was one thing about, do you have to pay extra for distributed services?
Colby: I think I've already...
Don: You've answered that one too, okay, good. All right, so then the next one is, "When will version 7.9 go from RC to full release?" A question many people may have.
Carl: Yeah, good question. The answer is very shortly, it's on its way up there right now, it will go final today.
Don: Excellent, thank you. So here's another question that has to do with copy protection. "Does the Ignition copy protection for a created project or its parts, templates, windows, UDTs, scripts... I'd like to prevent illegal cloning of my project and prevent the illegal use of my element library in other projects, for instance, by binding to the Ignition license like in the new Siemens PLCs."
Colby: Okay, so I think I understand that question as something that comes up fairly frequently in regards to people building essentially products out of Ignition, so it could be OEM or it could just be encoding specialized knowledge into an Ignition project, and they wanna make sure that people can't steal their sub-components of their project. And so we actually do have a feature for that, it's not very well publicized on our website or virtually at all, I think, but it's called the OEM lock. And so that's something you would just contact your account rep about and see how that would play into your licensing scheme, but essentially it's a way for a project creator, a designer, to encrypt their, what they've created in a way that the customers can use it, but can't access it through the designer, for example, or really in any way. So I think that would be your best bet.
Don: Okay, Colby, I think here's another one for you. "Why is the size of the data so much smaller with the remote historian?"
Colby: That's an interesting question, like why didn't we just do this earlier, right? With database access. The reason is, first and foremost, we can't control the protocol used by the different database systems, right? And it turns out that a lot of these protocols are just very, very verbose. When you have a lot of values, they just send them in a not very efficient manner and that creates two problems. One, it's a lot of data, that's why it's bigger, but two, it's a lot of packets and so, that's why latency can have such a negative effect. So, with our remote history system, we're able to bundle up data into bigger chunks and then we're able to encode it using a very efficient method which solves both of those problems.
Don: That's great, Colby. Listen, we have a great long queue of questions, so we're gonna take five more minutes. Normally, we'd end up right now. We'll take five more minutes and answer a couple that I think are gonna relate to a lot of people but I also wanna reiterate, we will get to all these questions. If we have to follow up, we'll do five more minutes now before we end up. Can I upgrade to version 7.9 directly from version 7.7?
Carl: Yes, absolutely. It's backwards-compatible. You can upgrade directly. You don't have to take intermediate steps.
Don: Okay, good. Then, hope the third party module development process with Maven and Sine Module remains the same for version 7.9 and we'll be backward-compatible with previous versions. That's a statement, I assume we'll make it a question.
Carl: Yeah, it's close enough to a question.
Carl: Yeah, it is the same. So, I'm guessing this is due to the idea that we changed the designing process about what, six months ago or so, and rest assured, we didn't change it again. So, it's the same process. And the Maven artifacts for 7.9 are up on Nexus now for all of you. Third-party module authors, you can get going with it right now.
Don: Great. I'm gonna take two more quick questions. Can you explain what Vision Module Top Up restriction means?
Carl: Alright. So, that was one of those other features on that list. It's a pretty simple idea, basically, that if you have a pop-up window in a vision client and you drag it to the side, it just gets stopped by the borders of the frame as opposed to being able to be dragged outside the frame and then enlarging the virtual desktop and making the client scroll.
Colby: Right. Pretty minor point but we had some customers who were having problems with the operators dragging screens to the side and then missing information that was important because of that.
Don: Cool. So, we'll take Ivan's question last 'cause I think it probably applies to a lot of people that has to do with documentation. Is the documentation for all new features and functionalities available somewhere?
Carl: Yes. The new user manual for 7.9 is going live today and the university will follow shortly thereafter.
Colby: Yeah. I'd like to say that our training department is under a tremendous amount of work on the user manual. So, when it goes live today, it's not just new information for 7.9 but it's really a lot of new information and presentation of that info, so check it out. It's pretty nice.
Don: Great. Listen, I really appreciate everyone's interest today. It was really exciting to be able to present version 7.9 today, and there are lots of questions still in the queue that we didn't get to. I said we will get to them. With coordination through the account executives and Carl and Colby and their team, we will make sure that we do get all of your questions answered. Very much appreciate everyone's interest today. I know we're out of time. I'd, at least, ask Carl and Colby, is there anything final you guys wanted to say, sort of wrap up with your presentation of version 7.9 to our customers and viewers and listeners?
Colby: Well, I would say that this release is exciting for us in the sense that we've been able to develop it in collaboration with so many of you. And so, we're making, as we go forward with these and develop all these features, it's really exciting to see the way that your applications and architectures are developing, and so we look forward to seeing where it all goes.
Carl: Yeah. I'm just really excited by how that status section turned out. It's one of those things we have to use for a while. If you go back to a pre 7.9 gateway, you just notice this big difference. It's the availability of information and the way it's presented is just such a leap for them. I'm really excited by that.
Don: Great. Thanks, Carl. Thanks, Carl, Colby, and thanks to all of you. With that, we have concluded with today's webinar. Have a great day, thank you.