In an industry like pharmaceuticals, maintaining quality and compliance is a strict requirement, not an optional goal. Outdated or ineffective technologies and methods can not only hamper efficiency, but also stunt growth and potentially affect product quality.

That was the situation Sandalwood Systems Integration Group found itself in with one customer who was having difficulty bridging the gap between their scheduling application and their ERP system. Sandalwood leveraged Ignition — an industrial automation platform for SCADA, HMI, IIoT, and more — to deliver a solution that completely revolutionized the customer’s production processes.

Minding the Gap

The customer was struggling with a recipe control gap. While their ERP system provided meticulous high-level recipe control and monitoring, the plant floor lacked real-time data as well as access to scheduling and optimization tools, relying instead on an in-house Excel-based application to schedule multiple sterilization lines.

Sterilization scheduling can be a complex process: components must be sterilized in time to feed fill lines, which are predicated on the downstream demand of the final product. On top of that, the existing inventory of sterilized components needs to be considered when determining production quotas. Relying on Excel macros for batch preparation did not offer the flexibility or scalability required to effectively manage the sterilization lines, resulting in a system that could only schedule a few days at a time, hindering long-term planning efforts.

“We were initially given a copy of the Excel-based application and asked to duplicate it in Ignition, which acted as our initial requirements,” said Bob Sloma, Digital Transformation Lead & SME, Systems Integration Services at Sandalwood. “As you can imagine with an Excel-based application, figuring out what they were doing by analyzing the VBA code was a challenging task.”

Even consulting with the application’s developer, it was a challenge to dig through layers of code and determine which reports were actually being used, as it became evident that certain reports were more vital than others.

The Excel application determined the best overall schedule by calculating all possible routings and their overall durations. This brute-force approach could not produce a full schedule without overloading the machine running the application. Clearly, it had reached the limit of its efficacy. “I have significant experience with MRP and production scheduling with my 30-plus years of experience and knew there was a better way to do this,” said Sloma.

Batch Production Scheduler

Once Sandalwood and the customer clearly defined the objective of the project, Sandalwood was able to deliver the Batch Production Scheduler: an application that would allow the customer to create a schedule of the sterilization lines that covered the requirements for the full horizon of the fill lines’ schedule as well as enable them to add products and lines over time. The core functionality of the Batch Production Scheduler included efficient component sterilization scheduling, component quantity determination, as well as reports and metrics.

The Batch Production Scheduler transformed the customer’s production process with real-time scheduling and optimized resource utilization, leveraging Sandalwood’s algorithm to intelligently evaluate processing routes for each component, selecting the most efficient plan. The improved scheduling delivered accurate component quantities for caps, vials, and plungers based on the fill line product schedules, not only ensuring timely production, but also reducing waste and avoiding unnecessary downtime.

Beyond that, the new application delivered adaptable scheduling, allowing users to define multiple routings for component categories. This increased flexibility was especially useful as the new system introduced long-term scheduling, expanding the time window to weeks ahead. As production introduces new products and adjusts current offerings, the customer can now add new products easily, with bill of material-defined component quantities.

The new system also revealed some unexpected benefits, highlighting how difficult it was to implement changes in Excel and how little connection the data had to other applications. “Ignition was chosen as the platform to enable future interoperability starting with integration to directly query a database for inventory data,” said Sloma.

The system displays metrics for each sterilization machine’s schedule and its ability to meet fill line requirements. These detailed reports empower decision-making. “There are over a dozen middle managers and the reporting is being utilized by over three dozen people across a 24x7 operation,” said Sloma.

Sandalwood developed the solution’s UI in the Ignition Perspective Module. Perspective, which leverages mobile-responsiveness and web-based deployment, combined with the Reporting Module enables operators and managers to access reports via a web browser, eliminating the need for local files and allowing the customer to control and constrict access to specific screens and critical data.

Sandalwood’s “lab on a cart” speeds up the development process

Lab À La Carte

A solution like this doesn’t come out of nowhere. At Sandalwood’s corporate headquarters in Michigan, they have a “lab on a cart” where they develop the basis for their applications. The lab consists of a two-unit rack-mounted device running two Windows PCs — one is on the corporate network while the other is connected to a manufacturing network with a firewall between the two — in addition to other devices like industrial PCs, RFID readers and antennas. Sandalwood runs a VM to simulate multiple PLCs publishing data via OPC UA with other VMs running various development environments, one of which contains a shared Ignition Gateway, MSSQL Server, and PostgreSQL.

“Ignition’s use of Python as a scripting language was also a big advantage,” said Sloma, who developed a prototype coded in Python for the scheduling algorithm, including specialized rules for how often the sterilization machines need to go through a wash cycle between production cycles or component changes. “Most of that code was able to be used within the Ignition application by the Ignition developer without significant changes. That saved a lot of development time.”

Ignition’s designer does not limit the number of concurrent developers for a single project. While Sloma was the project lead for this application, Ignition’s shared environment allowed multiple people to perform code development, reviews, and functional testing. As a result, Sandalwood was able to complete most of the development within their lab before implementing the solution in the customer’s environment. “Ignition is a breeze to install,” said Sloma. “This was handled by the customer directly. It takes more time to get the infrastructure in place (VM, network access, etc.) than it takes to install Ignition.”

Ignition’s capacity for rapid development and implementation greatly expedited the project. “The ability to start development sooner within our lab while our customers get their environment in place is a game-changer for us and allows us to deliver solutions more quickly than if we had to wait for clients to set up the resources and grant us access,” said Sloma.

Planning Long-Term

Even with the successful implementation, Sandalwood is already looking to improve the customer’s downstream visibility and advanced scheduling while utilizing the same UI template. Even though this project is not currently connected to any devices, it includes the SQL Bridge Module. Sandalwood plans to connect to a SQL database at some time in the future, with the goal of eventually obtaining the live component inventory data directly by querying the database via Ignition. The Sandalwood team hopes to utilize Ignition to develop line side user dashboarding and annunciation (Andon board) and create a digital whiteboard for the operators. Another goal is to integrate the customer’s Microsoft Active Directory for user management in place of Ignition’s built-in capability as well as their badge-in systems.

The Batch Production Scheduler has streamlined the customer’s scheduling process, and by implementing the Ignition platform, created a foundation for innovation both short and long-term.

Unified Namespaces (UNS) have the power to streamline OT data by breaking through communication barriers between devices and applications. By leveraging the Ignition platform and MQTT, UNS can open the door to transformative potential for operational and enterprise applications. But what even is a UNS? Join Cirrus Link as they leverage Ignition and MQTT to implement UNS and their transformative potential for applications, and share details about the core functionalities of UNS. By the end of the session you'll be equipped with the knowledge to harness the power of unified data and unlock new possibilities for your industrial operations.

Transcript:

00:04
Susan Shamgar: Hello, welcome to today's session, "Demystifying the Unified Namespace with Ignition." My name is Susan Shamgar. I'm a member of the technical writing team here at Inductive Automation, and I'll be your moderator for today. To start things off, I'd like to introduce our speakers. Arlen Nipper has been designing embedded computer hardware, software, and SCADA infrastructure solutions for 47 years. He was one of the early architects of pervasive computing and the Internet of Things, and in 1998 co-invented MQTT, a publish-subscribe network protocol that has become the dominant messaging standard in IoT, designed to optimize and make use of data for both OT and IT. Throughout his career, he's been an industry leader advancing SCADA technology. Nathan Davenport has more than 18 years of experience in the software industry. He graduated from Portland State University with a Bachelor of Science in Computer Engineering and worked for the first 13 years of his career at Microsoft. In 2019, he joined Cirrus Link Solutions as a Senior Software Engineer to focus on IIoT and the challenges and opportunities it presents. In 2023, he took on the role of Director of Sales Engineering at Cirrus Link as a technical leader and strategist for the company's sales engineering team. Please help me welcome Arlen and Nathan.

01:29
Arlen Nipper: Thank you very much. Appreciate it. Hello, everybody. Welcome to ICC. This will be my ninth presentation here at ICC. And first of all, thank Inductive Automation for all the cool stuff that you guys do. It's awesome. I mean, this show, we get to meet all of our customers, talk to them about new ideas. And a lot of what we've got in the Cirrus Link product line actually came from talking to customers here at ICC. So, really enjoy it. So today we're going to be talking about demystifying the Unified Namespace with Ignition. So, before that, real quick introduction to myself, Arlen Nipper, and Nathan Davenport. Nathan will be out here in a little bit helping me with the demo. So, Cirrus Link, we were founded in 2012. Right after that, we became a Strategic Partner with Inductive Automation. So, that has been great. So, really, when you think about it, when we started Cirrus Link, we needed a platform. We had a good idea. We wanted to leverage MQTT for industrial computing. All we needed was a platform. So, with that, really what we do is our development team works on the Ignition platform, developing MQTT technology modules to run on the Ignition platform.

03:03
Arlen Nipper: Now with that, we have a few standalone products that we do. One is the Chariot Sparkplug-aware MQTT broker, and the other is the new product we're going to introduce today, is a free MQTT client. So, we work with this all the time, and I'll go through this in a little more detail, but finally having a first-class MQTT client that we can all use as these MQTT networks get bigger and more complex and bigger and more complex going forward. Also, this is the 25th anniversary of MQTT being published into open source. So, I was thinking about that, I was...

04:00
Arlen Nipper: Yeah, it's pretty wild when I think about it, I mean, Andy and I were trying to solve a problem for Phillips 66. There was no cloud, nobody was... There was no security. Security was security by obscurity. But as I was thinking through this now, 25 years later, if Andy and I would have built a kill switch into MQTT, I figure right now there's anywhere from three to five billion clients running right now as we're talking. A billion of them. So, if we turned it off, that means there was a billion Facebook Messenger applications that would quit working, car telemetry would quit working.

04:44
Arlen Nipper: You wouldn't be able to talk to your Alexa to turn your lights on and off. You wouldn't be able to open and close your Genie garage door. So, it's pretty incredible when you think about an open technology, very understandable, very simple, and how it scaled to all of the different applications that it's in today. So, we... Kind of who's using the MQTT Sparkplug technology today. So, at this point, we, Cirrus Link, have over 2,000 discrete companies that are using MQTT Sparkplug. And if I were to put this slide up six years ago, that would have probably been 60%, 70% oil and gas. That's where we came from, that's where our customer base was at the time. But if you'll notice, where the growth is, is in manufacturing, and manufacturing really, with SCADA in oil and gas, where we have remote telemetry, we almost had to have a UNS. We had to name at least our stations and our polling where we could have everything at least on a network when we're polling down that network to have it organized in somewhat of a hierarchy. But in manufacturing, basically, it was the wild west. I mean, they were everywhere with that. And really, I think that's one of the driving factors around the whole notion of the UNS and the popularity that it's gaining today.

06:22
Arlen Nipper: So, with MQTT as an enabling technology, it's interesting that something so simple that customers start using it immediately. So, I demoed in, I think, 2015, the first MQTT module, and immediately customers started using it. But more interesting to me is what they were doing with it and how they could innovate with it. And so as we proceeded, we went from, again, the first demo that we ever did was we kind of proposed the notion of, "What's the problem?" Well, the problem is that we have devices connected to applications, i.e., protocols are evil. If I have a protocol, I have to have a driver. The driver talks to the device, brings back the data. Well, the data sets within that application. Now I want to use it somewhere else, so I have to write something else to get it out of that polling engine into something else. So, that was the problem. And what we said is that really what we're proposing, at least in year one of this journey was, hey, we should look at connecting devices to infrastructure, not to application.

07:42
Arlen Nipper: And with that, we could start unlocking some of the stranded data that was out in the field. Because, you know, in 2015, we figured that 80% to 90% of the valuable data that the company could use was probably being left stranded out in the field. Now, as we progressed the next year, we said, well, let's put some tenents out there. The first tenent is let's decouple and connect to infrastructure.

08:10
Arlen Nipper: And the second tenent was, well if this is going to expand, if we really are going to explode to the Industrial Internet of Things, we better be able to show that this is a superior OT system to begin with. Because if we couldn't replace conventional legacy poll response systems, there would be no adoption in that. So, as we move forward, we also had just started in 2016, the Sparkplug specification where we could start saying, okay, well, MQTT is pretty cool. You can publish anything you want on any topic and it's got a problem though. You can publish anything you want on any topic. So, Sparkplug came out. We started trying to define what would be the best way to use MQTT in industrial automation architectures. So, by 2017 ICC, I think we had all the ingredients that we needed to kind of, for the emergence, if you will, of a UNS.

09:21
Arlen Nipper: Unified Namespace. So, we have the three tenents now. Connect your devices to infrastructure, not to applications. Be able to demonstrate a superior OT solution, and with that be able to provide a single source of truth. And we came out with this tenent, a single source of truth. And now it's being used everywhere. Oh, we're going to have a single source of truth. We're going to have the single source of truth from the edge, and that's the only way it's going to expand. And here we said the transformation to IIoT, it won't be IT down to OT. It will be enabling OT to put together an infrastructure that's ready for cloud enablement. And I think that's where we're going. That was kind of the evolution, if you will, of UNS. So, we'll go back to the problem that UNS solves. Well, the UNS kind of solves the problem of trying to get rid of data silos and stranded data. Now, if we go back, even go deeper into kind of the origin of the problem is, we had this automation pyramid, call it the Purdue model, you can call it the ISA-95 model, where basically you started with your sensors, your PLCs, you moved up to SCADA from SCADA, you moved up to your manufacturing operations.

10:55
Arlen Nipper: Get the data up to there. Well, we kind of stopped at level three for a little bit, and well, we need to get it up to the enterprise, so we must define a DMZ level. And then we can finally get it to the business networks, and they can start seeing that data. And ultimately now we'd like to get it to the cloud. Now, the problem with this, as you can imagine, is that, we'll start at the SCADA level, is that first, from an operational standpoint, we're only getting the data that operations need. Well, the business looks at it and go well, wait a minute, you're not pulling in this other value, say, from a tank level or this other value from how long a pump's been running. A pump. The pump is there, I'm controlling it, but you're not telling me how long it's running. And operations go, well, we like the way we're polling. We told you when we put in the SCADA system that we would change our polling algorithm.

11:57
Arlen Nipper: But now that you want to, we really don't wanna do that. And then you go up to the next level and you go, well, we finally got our data up to this level we need to go down, and we need to change some other applications. And now we've got it up to the next level. So, as you can imagine, as Travis said this morning, "Dream it, do it." But with this model, you could, it's like, "Dream it, forget about it." It was never going to happen. And then we finally get to the cloud level, and I think we started seeing this about five or six years ago.

12:34
Arlen Nipper: This notion of well, I've got all my process variables down here. If I wanna get them up through this pyramid, I'll finally get them up. And then I'm going to just take my whole, all the process variables that I got and I'm going to put them in a data lake. And this is going to be the most beautiful data lake and we're going to put all of our data in there and everything will be great. And over time we'll be able to use that data and take advantage of it. And then suddenly we figure out after a couple of years that it's turned into a data swamp and nobody uses it. And we have terabytes of data that are landing in data swamps because think about it, I've got a discrete register value, I wanna go look at it, now I've got to do a query of where did it come from? I've got to do another query of, well, what's the engineering units? I've got to do another query of on what was the deadband on that measurement? And by the time they try to get this data, it just becomes without context, without a UNS, data, literally, a data lake turns into a data swamp.

13:51
Arlen Nipper: So, we get to the definition, if you will, of a Unified Namespace. And really, it's all about taking your information and getting it organized in a way that you can use it within your company from the very edge where your single source of truth is up through all of your business systems, through your manufacturing systems, so that ultimately when you get to the enterprise, everything is organized in a way that we've got contextual data. And of course, we're doing that, a lot of that with Ignition, with the ability, you know, originally it was just the tag definitions. We could organize their tags, we could give them properties, we could give them engineering high, engineering low, dampening, or deadbands.

14:40
Arlen Nipper: Then we came along with UDTs, so we could take user data types and define a model, and then that model consisted of the measurements and the measurements had the contextual information along with them. So, with that, if we could take that, imagine if we could have that context all the way at the edge where the engineer defined the equipment and get that all the way up to the enterprise, all the way through the SCADA, then we literally would have a UNS. So, as I think about it, really kind of how this all came evolved, if you will, is that with protocols we got registers and we could define them, but they always were kind of standalone. When MQTT came along, we had to, is the nature of MQTT, we had a topic and a payload, and the topic again, by its very nature became hierarchical. You could use slashes and so you could have, I still remember Phillips 66, 1999. We probably had the first properly named UNS, if you will. If you go by the ISA-95 hierarchy, we had a pipeline. You know Pipeline 1. In Pipeline 1, we had booster stations, Booster Station 1, and booster stations we had PLCs.

16:08
Arlen Nipper: And then PLCs, under that we had flow computers. So, we had this hierarchy by the very nature of how MQTT worked and how we were getting that into an organization. So, from Walker Reynolds, to David Schultz, to Matthew Paris, everybody's had really good ideas now of leveraging what you can do with MQTT, but do it in a way that we can have that UNS go all the way up to the enterprise level. So, here's my Phillips 66, 1999 UNS. Now, one thing that kind of comes up in conversations when I'm on with the customer and go, "Well, Arlen, we've got our broker here. So, that's our UNS database." And remember that an MQTT broker is just for routing messages through your infrastructure. It is not where all of your historical data is. So, I just wanna point out here that if you put all your tags into an MQTT broker and you set the retain flag on all the tags, all you're going to get is last known good. So, within a UNS architecture, we still have to think about where is our UNS database going to be in that whole architecture.

17:35
Arlen Nipper: So, a lot of you, I think I've done about 200 Snowflake demos here since we introduced Snowflake last year at ICC. And this is kind of the architecture drawing that I've used in all 200 of those demonstrations. You can see where we've got this notion of Ignition, Ignition Edge, native devices like Opto 22, like Phoenix Contact, they can do Sparkplug B and being able to take the edge of network and publish that up to an MQTT broker. That engine is subscribed to on an Ignition gateway. And from there we really start using Ignition as the enterprise connectivity platform to create a data model i.e., a UNS, instantiate that, creating our digital twin. Now, I hate that word "digital twin." It has so many connotations you can't...

18:36
Arlen Nipper: But the difference here is we try to do... If you look out there, AWS has digital twin technology. Microsoft Azure has digital twin technology. Google has digital twin technology. But the problem is those digital twins are the way that they thought you should do a digital twin and they probably don't know what you do. And the interesting thing with what we can do with UDTs and Ignition is those are digital twins, the way that we as you, the customers use it. And that's the way that you can start leveraging really a digital twin using Ignition UDTs and then of course still keeping track of our real-time data. So, the digital twin that I create on Ignition Edge out in the field can be published to an Ignition gateway automatically. I don't... It's automatically that UDT is published up. We discover that, now I've got the UDT there. Now I can point that at a transmitter that goes to a broker that's connected to the Snowflake, the IoT bridge for Snowflake. And now going into Snowflake we literally have that UDT recreated where we can take advantage of that.

19:56
Arlen Nipper: So, that becomes really... Snowflake is really the kind of the ultimate UNS database so that you can go back and get all the historical data, but you still have all the real-time contextual data there as well. Now just to go into a little more, we are listening. So, over this year, last year we've had a lot of requests and we've added some features to Engine, Transmission, and Chariot that customers have been asking for. So, first thing is that the UNS enablement of MQTT Engine. Now what we did was as you know, if you can have edge devices again, you could have Ignition Edge and all of the native devices again, the Advantechs, the Opto 22s, the Eurotechs, the Phoenix Contacts, publishing that information into Ignition.

20:56
Arlen Nipper: Now we've got to keep track of that, that's an individual edge node and we've got to keep track of the metrics and that's the namespace that came in. And then you've got another edge node and this could be in a factory, another cell. And when you display that in the MQTT Engine, you've got all that information, but it's not really the UNS that you wanted. You would like to collapse that so that you could truly define that and have it all together by the time you get it to Ignition. So, what we have here is Edge Node 1 and Edge Node 2 and they're both going to connect to a broker, start publishing information and those are going to flow into Ignition in an MQTT Engine. Of course, you're going to have your Sparkplug view of G1, D1, E1, ACME Inc. Stillwater Coyote properties for my Coyote Property for Wile E. Coyote. And then we have our Anvil Production Plant and then down to the actual UDTs. And that's all good. But what I would like to do is have it in a new UNS view. So, now in Engine you can set it up and say, "Okay, I know you're going to have all the Sparkplug metadata there, but what I wanna deal with is a UNS view."

22:21
Arlen Nipper: So, now we can go in and start making really clean view right in Engine. You don't have to do tag copies or anything like that. Is that, that will show up in Engine exactly the way. So, think about it, what we're doing is obfuscating the group Edge Node ID and we're presenting at a hierarchical namespace just the way that you named it. So you can start having all of these edge nodes contributing to a single UNS.

23:03
Arlen Nipper: Okay. The second thing is a lot of customers have, especially in manufacturing, they have it set up where they're familiar with MQTT, but they have small devices, Raspberry Pi's, they've got very simple MQTT clients and they would like to connect their clients to a broker just to get some of the information that we can publish out of Ignition. So, with the Transmitter module now, you've got the ability to point to tag providers, folders, individual tags, and literally publish those one tag per MQTT message. So, in here I'm showing that we've got ACME Inc. Stillwater Coyote, Anvil Angle, JSON payload of a value and a timestamp and those can be published on retain and you can choose to publish the properties as well.

24:02
Arlen Nipper: So, you get the engineering units, engineering high, engineering low, those will be setting there in your broker so that as other MQTT agents come or clients come around and they connect to the broker, they're going to immediately get last known good. And then they can subscribe just to the data that they want. Maybe they just wanna subscribe to the Anvil Angle and that's all they wanna subscribe to. So, they don't have to be aware of Sparkplug and they can get very granular in how they actually use MQTT at that level. Now we've given you a double-barrel shotgun and you can shoot both feet off. So, this is going to create a lot of traffic and a lot of... If you can imagine if you had a million tags and you're going to retain all of those in a broker. That's probably going to blow your broker up. But we do have a lot of customers wanting this feature to be able to start really going out and getting very granular in the way that they can subscribe to topics that are coming out of Ignition. Number four. Oops, I think I skipped over one.

25:19
Arlen Nipper: Got them out of order here. Number four. For the last seven years people have been wanting to do alarms over MQTT. So, now with... And we had to have some infrastructure help from Inductive Automation and Inductive, thank you very much. But now we can generate alarm at the edge, publish that into Engine and then at Engine we can acknowledge that alarm and take it all the way back.

25:54
Arlen Nipper: So, now you can. Thank you. So, now you can use MQTT as your single secure connection into a hub-and-spoke architecture. And finally, I probably should bring Nathan out about this time. Nathan basically isn't all... Gets a lot of the customer calls where we're starting to design something or get into a debug situation where we've got different kinds of brokers, different kinds of clients out there, and we're having to debug them. So, we are announcing here at ICC that we now have the Chariot MQTT Client.

26:37
Arlen Nipper: So, it's free. Uniquely, you can subscribe to multiple MQTT servers. I think all of the other very simple MQTT clients, you can just subscribe to one broker. But when you're trying to solve a complex problem, you wanna subscribe to multiple brokers.

27:00
Arlen Nipper: Of course, it's got a built-in Sparkplug decoder, we can publish messages from it, and again it's free. So, if you download Chariot, which is our MQTT broker, the client is part of that, and you don't have to use Chariot broker at all, but you can run the client, and you can use that for free. You'll be able to download it as of today, I think. Right, Nathan?

27:26
Nathan Davenport: Yes.

27:27
Arlen Nipper: All right. So, with that, we are coming to the demo. So, I figure after eight years of doing live demos and never having a problem, I was probably pushing my luck. So, if we have a problem, I'm going to let Nathan demo it today.

27:57
Arlen Nipper: So, and I know a lot of you know Nathan, the guy is just incredible. He can, man, he can debug anything. So, really, what we're showing here is that we've got... It doesn't show up on the screen, it's being cut off. We've got three actually, hit escape on there. It'll show up. There we go. We've got three edge nodes publishing data. They will be publishing data. They're set up in a Unified Namespace that'll be going to one broker up into Engine to Ignition. From Ignition, we've got Transmission, where we'll be using the new feature of the UNS transmitter to transmit some of these tags out where you can subscribe just to individual tags. And then we've also got another transmitter going to another Chariot broker, going to IoT Bridge for Snowflake. And then ultimately, we'll get the entire UNS into our Snowflake data cloud platform. So, Nathan.

29:00
Nathan Davenport: Thank you, Arlen. Hi, everybody. I feel like every time we do these demos, Arlen makes them more and more complex, as you can see by the topology diagram. So, hopefully, the demo gods will cooperate today. We'll see. We'll see who's pushing their luck. All right, so as Arlen said, you see, we have three Edge gateways here. They're all hot. They're all connected to Chariot MQTT Server 1, and they're waiting for MQTT Engine here on the central gateway. Let me select it here so you can see, to come online, publish a state message on the appropriate topic. And that's the trigger that's gonna tell these gateways and the Sparkplug transmission clients, now is the time to go ahead and publish your birth messages and subsequent data messages. So, let's pivot over here to the Engine gateway. You can see it's disabled right now. And I'm gonna pivot back over to... And somewhere in here in the central gateway is MQTT Engine. Now, I have no UDT definitions here at all. I have no tags in the traditional Edge Nodes folder, and I have no UNS namespace. So, I'm gonna go turn on MQTT Engine, and you're gonna watch all the data flow.

30:23
Nathan Davenport: Let me get back to the topo diagram. From the three Edge gateways single source of truth all the way up to Engine. And we will take that single source of truth, that single stream of data, give you your standard edge nodes view with the Sparkplug overlay. And then we're also gonna give you the UNS hierarchy and topic namespace with that overlay removed. So, we go turn on MQTT Engine. Give it a second or so. That's about all it takes. And here, you can see your traditional... Oh, sorry. Trying to full screen, but that did not work out, so let's try it one more time. And here you can see your traditional Sparkplug nodes laid out much as you would expect them. Your group, your edge node, your device, and then your UNS namespace, right? So, as we drill down through your UNS namespace here, we're gonna go just a little bit deeper so that you can see that these tags here are in fact under the standard Sparkplug edge nodes folder with the Sparkplug overlay, and they're updating now in real time. And within your UNS namespace, you have that Sparkplug overlay removed.

32:01
Nathan Davenport: All right. We start at the enterprise, site, the area, and so on. So, we give you both copies of these tags, the Sparkplug overlay, without the Sparkplug overlay. And these tags very much behave just like you would expect them. If you were to write to this load tag, for example, that's going to send a Sparkplug command message down to the edge. Transmission's going to unpack that, write to the tag, that's gonna create an OPC UA right down to the PLC, and that write is going to bounce back all the way to Engine, and this Engine tag is gonna update. So, let me prove to you that this is actually working. The load's gonna go from 44 to 46 let's say. You see it go all the way down, come all the way back. Now, this is the perfect time, I think, to go ahead and demo alarms across MQTT. So, I'm not gonna show you the alarm at the edge, but Arlen went ahead and put an alarm on this load tag at the edge, and once we cross a set point of 50, I believe.

33:11
Arlen Nipper: 50.

33:13
Nathan Davenport: That alarm's gonna fire. So, let's say all of a sudden our load jumps to 51. This alarm that you see here came all the way from the edge all the way down to Engine, and then we basically via Engine, wrote it into the alarm status table. So, from here, from the Engine side, we can go ahead and acknowledge this alarm, which is then gonna fire another command back down to the edge to acknowledge it at the edge. So, let's do that. So, the alarm's been acknowledged. Now let's say that the load drops back down below our threshold. You'd very much expect this to be cleared. So, we drop down to 40, let's say. Well, 40, let's say. And that alarm has been cleared. You can see it here in the table. We've cleared that alarm. We have alarms across MQTT. You guys have been asking. We finally brought it to you. Thank you.

34:25
Nathan Davenport: Like Arlen said, it took about seven years and a little bit of help from Inductive, but we got it finally. All right, so let's. Oh, and I probably should have showed you as well that of course we have your UDT definitions over here as well. We can't create the instances without the definitions. You get all of that single source of truth. Let me pop back over to the topology diagram. So now, what I'd like to show you guys next is, we're gonna turn on Transmission here on this gateway where we also have Engine. We have a traditional Sparkplug transmitter. It's gonna push your data up through MQTT server number three, through the IoT Bridge for Snowflake into your Snowflake back in that Sparkplug Protobuf. And then we also have another transmitter. I'll show you the transmitters here in a second so we can kind of anchor you in, in reality in the product itself. We have another transmitter, UNS transmitter, specifically configured to consume the Engine UNS tags. So, let me show you what I mean. Pivot back over to Transmission. We're not enabled yet. You guys know what a traditional transmitter looks like. This is the transmitter right here going to Snowflake.

35:44
Nathan Davenport: It too is picking up the UNS tags, but it's Protobuf encoding them, while the UNS transmitter also pointing to exactly the same folder. But what we're gonna do is we're gonna shred these tags. We're gonna publish out one message or a message per tag on a topic that is the full UNS path all the way down to the leaf tag. So, now you have full control for consumers of your data. Maybe one MQTT client wants to simply consume the load tag, maybe another wants to consume the angle tag. And let me also show you that there's no data here in our Snowflake backend as well. I'm gonna refresh it just so you believe me. These three schemas here or folders are sourced by the bridge, produced by the bridge, but we should be seeing our ACME INC. schema folder, all of its views, all of its UDTs, all of that. We don't see it yet. We're gonna go here, we're gonna turn on Transmission, and we are going to publish this data out. So again, let me pop back over to the topo diagram. So, how can I convince you guys that the UNS transmitter publisher, has in fact published all of those tags, one topic per tag? Well, we're going to use the free client that we built for you guys, the free MQTT Chariot Client, to basically view this data at the server.

37:24
Nathan Davenport: Okay. Let me see whether my session has expired yet. So, we're gonna refresh just to be sure. I'm gonna turn this server on. It's not actually accepting connections yet. Now it is. And here is the MQTT Client built into the Chariot server. Looks like we need to connect to localhost, and we do. So, I have the Chariot Client here connected to localhost, this server right here, MQTT server number 2, and the MQTT Server 3, the server that's serving up the tags to Snowflake. Sparkplug data. So let's go back. Real quick we'll pivot through this view. Looks like we have an active QoS 1 subscription on hash. If I go over here into the topic tree viewer, you can see we're connected to both servers. We have the top server and its topics. I'll expand them here in a second, showing you the data coming into Chariot server number 3, the one all the Snowflake data is flowing through. And then all of your UNS data is here on the local box. And you see your UNS reconstructed here. And as we drill down through this topic namespace, you're gonna find exactly the same data that you would be seeing in Ignition right now for these tags.

38:56
Nathan Davenport: So I turn on most recent, just so we can stick on angle. And every time the angle tag updates and the UNS transmitter publishes out a message, we're gonna auto-update the JSON payload down here. So what are we giving you? This payload at the very bottom is updating, I don't know, about once a second. We give you the qualified value. Timestamp, quality, an actual value. We give you the data type, and then we give you the full UNS path all the way down to the tag. You can retain it, publish on QoS 0, 1, 2, whatever you guys want to do. It's completely up to you. Like Arlen said, be a tad bit careful. If you got 20 million messages, it could be a little bit heavy. And now imagine if you also wanted the properties for that tag. So you guys remember possibly that Sparkplug is going to push all of the additional tag metadata. Things like engineering units, engineering high, engineering low, tooltip documentation, all that stuff comes in a birth message. But this is in Sparkplug. So we had to give you a way of retaining these properties. So as you can see here, we will also give you the ability to go cherry-pick out the metadata around a tag as well.

40:06
Nathan Davenport: Here in this example you've got engineering high and you have engineering units. So at this point now you can lock consumers down to topics, and they can consume one tag only if you want, or however many tags that you may want them to consume. Okay, and then as you can see here, the rest of your UNS is here as well. We got a little bit more time here, so I'm gonna show you a couple more things before we pivot over to Snowflake. Along with the connections view and the topic tree viewer, we give you the ability to subscribe to any topic you want and maybe publish out a message. So let's say, hey, we want to publish out a message on, I don't know, how about Arlen/Nipper with "Hello ICC 2024!" Bang. So I'm gonna publish that out there. I think I saw it, but things are streaming so fast. I can't quite tell. There it is, there it is. So we're gonna give you the ability to connect to multiple servers all at once, stream that data through, give you the topic tree viewer, give you the ability to publish out raw messages when you want to.

41:15
Nathan Davenport: I'm hoping here in the near future we'll get you a Sparkplug simulator into the publish side of this as well, so you can kind of simulate your own Sparkplug devices. Not here yet. Coming soon. Now we got to pivot over to Snowflake. I'm gonna refresh this view. Now here is the schema or the folder that contains all the views for ACME Inc. But before I go show you those views, let me show you where you find your UDT definitions, your models within Snowflake. The models are what we use to dynamically create the views such that we can hydrate them properly. So, if you scroll down into the views here, into the Stage_DB schema, there is a node machine registry. And if we preview this data, you'll find every UDT that was on that Engine gateway now up here in Snowflake on the cloud. You have your full context, your full UNS path, and there's all of your machines, your palletizer, your wrapper, your stamper, your drop test, your paint booth, your grinder, and a few other models there that are injected by the bridge themselves. Now, if I drill into the ACME Inc. view here, and let's say we drop into... Oh, how about the grinder, I think, and we preview this data.

42:36
Nathan Davenport: Here is all of your live tag data in Snowflake. Full UNS. It's still here. Yeah, we've stitched through the Sparkplug IDs, but your full UNS has been rehydrated here on the Snowflake side. And if I scroll all the way to the right, you'll find all of your UDT member tags as columns in this particular view. Let's pop back to the topo diagram. Again, a single source of truth. Three Edge gateways. In a couple of seconds, we can go all the way up through Engine, build you out your UNS, unroll that back out into another server via the UNS publisher, send data all the way up into your Snowflake Historian backend database in a couple of seconds.

43:28
Arlen Nipper: Awesome. Thank you, Nathan.

43:30
Nathan Davenport: Thank you.

43:36
Arlen Nipper: You made it through one.

43:37
Nathan Davenport: Woo. Nine more to go. And you can bet they're gonna get more and more complex too.

43:43
Arlen Nipper: That's right. That's right. So, I guess we're just about out of time, so if there are any questions, I think we could take a few and then we can call it a wrap.

43:54
Nathan Davenport: I think so.

43:55
Audience Member 1: I have a question on the Ignition Edge. It looked like you're just publishing the Sparkplug metric at that point. So, I noticed that your group edge node and device were G1, E1, D1.

44:05
Nathan Davenport: Correct.

44:06
Audience Member 1: And that's just getting stripped. So, when I bring it into the Engine in that middle one.

44:10
Nathan Davenport: Yes.

44:11
Audience Member 1: Okay. So, that's what's happening. So, that becomes the UNS piece.

44:14
Nathan Davenport: Exactly.

44:14
Audience Member 1: Okay, perfect.

44:15
Nathan Davenport: We still keep the context of where these particular tags in the UNS layout come from. We actually will have custom properties on those tags that'll tell you what your group ID, your edge node ID, and your device ID are so you don't lose context. But we remove that overlay to give you full UNS flexibility.

44:35
Audience Member 1: Okay, perfect. Just want to make sure I saw what I thought I did.

44:39
Nathan Davenport: You did.

44:40
Audience Member 1: Second one is that UNS transmitter. It looks like that's just using what used to be like the system.transmission component. So, it's flattening things. It's publishing a flat.

44:49
Nathan Davenport: Yes, it is flat, and it is similar to the Transmission, but we leverage the same code, our underlying agent code, that we use in the Sparkplug transmitter within the UNS transmitter.

44:58
Audience Member 1: Okay, perfect. Just want to make sure I understand that. The third thing is a comment. Does Rick Bullotta know what you just did?

45:03
Arlen Nipper: I hope so.

45:04
Audience Member 1: Yeah. There you go.

45:05
Arlen Nipper: Rick if you're watching.

45:07
Audience Member 2: Great products. You guys are awesome. But I have a question. So, your Unified Namespace. I mean, correct me if I'm wrong. It can filter out a lot of the stuff that's higher up in the tree so users only see the important parts that they want to see. What if I change my structure that I'm transmitting? I change a folder name or whatever, does that break everything or does it still work? How do you handle that?

45:35
Nathan Davenport: If there are no collisions, if you make a tag a folder, or a folder a tag, we have a hard time kind of resolving those types of collisions, if you will. But if you're simply adding other folders and so on, they should just pop in right in the middle of this UNS structure and it should function much like you would expect it to.

45:52
Audience Member 2: What if you delete, though? You change something.

45:55
Nathan Davenport: Worst-case scenario, what you do is you probably come back over to the Engine side, you'd blow all those tags away, you'd refresh from the edge, and we'd recreate that UNS in milliseconds from the ground up.

46:05
Arlen Nipper: And we've talked about this back and forth. 50% of the people we talked to say, "Oh, you should delete it." And the other 50% said, "Hey, just stale it." So, the customer did know it went away, and then he can go and delete it. So, we went with the staling.

46:21
Arlen Nipper: And that's all the time that we have.

46:22
Susan Shamgar: I think we have time for one more question.

46:24
Arlen Nipper: Okay, one more.

46:26
Audience Member 3: So I'm just trying to wrap my head around it a little bit more. Is SPB-V1 still there in the background, or is it like...

46:33
Arlen Nipper: It can be. But once we... In Engine, if you select the fact that you only want a UNS view, then you'll have metrics on G1, E1, D1. But those will only be for debugging. But the actual namespace that we created does start at ACME Inc. And so there's nothing. It's gonna stay that way.

47:01
Audience Member 3: So, then bridging that namespace should be a cakewalk.

47:03
Nathan Davenport: Yep. Should be. And as you can see it here. Just as Arlen said, for the UNS publisher, we strip off those pieces, and we republish on the full UNS topic. So this is the topic that the UNS transmitter's publisher is publishing.

47:14
Arlen Nipper: Well, I think he means the, in Engine, your UNS, the actual UNS tags.

47:20
Nathan Davenport: Ah, got it.

47:22
Arlen Nipper: Yep.

47:23
Audience Member 3: Thanks.

47:25
Nathan Davenport: Good question.

47:26
Susan Shamgar: All right, great. Thank you so much. And can we have another round of applause for Arlen and Nathan?

47:30
Arlen Nipper: Thank you, everybody. Good job.

47:37
Nathan Davenport: Thank you, sir.

Learn how process manufacturers are leveraging the power of SafetyChain & Ignition to drive meaningful value in their production environments. We’ll cover how manufacturers benefit from seamlessly connected systems and the broader impact that has on various segments of their operations. You’ll hear about a case study where thousands of data points derived from a complex manufacturing process were leveraged to drastically improve quality and production metrics. Finally, we will showcase how easy it is for manufacturers to connect SafetyChain and Ignition with a live demo.

Transcript:

00:01
Geoff Nelson: Glad you're here. Appreciate your time here to talk to us. We are here to talk to you about SafetyChain and our Ignition Module to help capture real-time data for a digital plant management system. My name is Geoff Nelson, I am the VP of Technical Solutions for SafetyChain Software. This is Jonathan.

00:21
Jonathan: Hello, everyone. Welcome. Thank you for joining us today. I've been with SafetyChain a little over three years working as a Solution Engineer. But I primarily come from the food and beverage manufacturing industry. I spent over a decade working in a plant and SafetyChain is a plant management platform. So, I'm really excited to talk to you guys about the value that SafetyChain can bring and how we can leverage the Ignition Module.

00:49
Geoff Nelson: So, let's get into it. So, we will talk about SafetyChain, we'll give you some of our key applications where we kinda hit the plant management, plant floor, talk about digital transformation which I'm sure you're all pretty familiar with, give you a customer success story and then go into a demo. So, we'll try to get through these kinda quick so we can show you a demo and leave time for questions at the end. So, we are a digital plant management platform. We're a SaaS solution hosted in Microsoft Azure, we have native applications for Android, iOS and Windows and we help kinda pull everything together, the glue for the digital plant management platform. We are an alliance partner here with Inductive Automation and we will show you our module that we have.

01:35
Jonathan: All right. So, yeah, as Geoff's kinda said, we bring everything together. I like to think of us as kinda like a one-stop shop when it comes to plant management. And as you can see, everything here listed, these are some of the key use cases and applications that a lot of our customers use as and leverage in manufacturing. I'm not gonna go through the whole list, but we touch your whole process from shipping and receiving all the way to getting your product out the door. And primarily, we've come up in the food and beverage space, but we have had other applications outside of that. Now, as it relates to the Ignition Module, that specifically focuses on how we're capturing data for our customers.

02:13
Jonathan: So, with the Ignition Module, we can capture any data that's already mapped to their Ignition Gateway in SafetyChain. And SafetyChain is already a pre-built solution for you to extrapolate your data. You can aggregate that, graph it, trend it as you need. We could take for an example, temperature logs here listed right here. Instead of having a maintenance tech or operator go in and take hourly required check and write that down and put it away in a folder or binder, SafetyChain helps you digitize that process and take it a step further by automating it. So, with the module, we could set off a trigger where we're capturing that specific data tag on a specific routine or basis, or if there's a condition that needs to be met, we can trigger it as well. We have multiple ways of triggering that data collection point.

03:11
Geoff Nelson: So, like Jonathan said, these are the key areas of impact, what we do, it's pretty customizable. And so, you can build really your own process out within SafetyChain. And then he's highlighted here these blue ones as real-time, maybe ones that resonate more through Ignition. But then you can bring this data in and it can live next to all of these other impact areas as well.

03:36
Jonathan: So, again, I talked about my time in the plant. This slide kind of really illustrates the process around capturing data and using that data to further your continuous improvement efforts. SafetyChain is basically gonna help you do that and then the module's gonna help you also automate that. So, in SafetyChain, primarily you could collect data via a workstation or tablet. So, we're device-agnostic. You can use a Windows workstation, you can use an Android or iOS tablet. Typically, it's operators entering checks or maintenance guys entering their work orders, things of that nature. But you can also trend and track that data and find your opportunities for improvement, find your opportunities to save time and waste and then you gather insights and you act on that data. And as you're acting on that data, as I said, you're pushing your continuous improvement and you're pushing the bottom line so that ultimately you're growing as a company. That's what we try to help our customers and try to generate those success stories from helping them leverage that data.

04:41
Geoff Nelson: So, whether you're coming from paper and we're helping you create a digital process or you already have data being collected and you're just going to multi-site networked cloud solution, we help you come to ask questions that you didn't even realize you had because you're doing that CI, that continuous improvement, on your processes and on your data. So, I'm gonna tell you a little story about Egglife. So, I don't know who here is familiar with Egglife. They make the tortilla alternative out of egg so you can have tortillas that are made from egg. They took the Ignition Modules. They already were using SafetyChain, they had gone from a paper process to a digital process on their tablets. So, they're using tablets to gather information, they're gathering downtime, dwell time, temperatures, all sorts of information within SafetyChain and already performing analytics. Then, they moved to the Ignition Module because all of that data was available within Ignition but they still needed to collect the data for auditability, for compliance and for audits that come in. Now, they took about 12 manual processes. They had people going up to the machines or going up to the HMIs and collecting this data in a tablet.

05:55
Geoff Nelson: They moved it over to the Ignition Module and all this data's still being captured but in an automated way. So, they took 12 processes and automated them. So, that's people, that's time now that people aren't having to go walk up with a tablet and it's all within SafetyChain and they can still perform their analytics. It's all in the cloud and it's all stored long-term. So, an opportunity there for them to save time, save money. And then now, they can use those operators really to do something else more valuable than looking at a screen and collecting data. All right, now we're gonna jump into the demo. So, bear with me just for a second here. Okay. So, I am bringing up the module first and then we'll jump into SafetyChain. So, this is just an Ignition Gateway here which I'm sure you guys are all familiar with. We have a module that can be installed and it puts this SafetyChain piece here at the bottom. It's really easy, I mean, a few clicks to install a module and then you get your connections, your Form Collectors, your OEE Collectors and your Tag Collectors.

07:01
Geoff Nelson: This allows you to really grab any data that Ignition has access to and then put it into SafetyChain in different ways. So, I'm showing a Form Collector here and it'll make more sense when we start showing SafetyChain in a moment because we'll show you our Demo 1 tenant. I'm just gonna go into the kettle temps here and just show it to you real quick. And I am using this connection here at this site and connecting to a VM, so might be a little bit slow here. When this comes up, it gives you a user interface that allows for configuration to create an integration between Ignition and SafetyChain. So, Ignition has view into what SafetyChain data exists. So, we call these Forms. So, a person might be entering, writing on a piece of paper what their kettle temps are and then so we digitize that into a digital form within SafetyChain and then Ignition gets access to that. So, a user could come in here and access all of the forms that exist within SafetyChain, pull it into Ignition, set up a trigger, so when do I wanna send this data to SafetyChain? Do I want to do it time-based, every five minutes, every one minute? Do I wanna do it tag-based? So, if a temperature exceeds a certain value, does the dwell time exceed a certain value?

08:20
Geoff Nelson: Send this information to SafetyChain, there're different ways to do it. Do I wanna do it manually so you can actually script this execution? You can put it into a button and perspective revision into a screen, and then you map each of the fields. So, I can have my Kettle Temp 1, 2 and 3. I have which line is it coming off of. Average is a calculated value within SafetyChain, so I don't have to send it. The temps, the tags, the fields within SafetyChain have different sources. So, you can choose a tag, a static value, an expression. You can choose a data source which allows you to go to any data source that Ignition has access to. So, if you have a SqlConnection or something, you can then pump that data directly here through configuration. So, it allows you to really take, like we said, any of the data that Ignition has access to, package it and send it to SafetyChain. I'll show you one more. So, what this does is it pulls the SafetyChain context into Ignition. So, Ignition knows how to talk SafetyChain language. The other option that we have are tag and OEE Collectors which really just says, "Hey, give SafetyChain the tag," and then it will deal with it.

09:34
Geoff Nelson: So, here, it's not talking SafetyChain language, we're just sending, okay, this tag goes to SafetyChain and it is your in count or it is your out count so that SafetyChain can then track your downtime, it can track your throughput, your productivity. All we need to know is the tag, just send us the tag and we'll do the rest. So, in this context, all the business logic is in SafetyChain. In the Form Collector, the business logic is basically in Ignition but it allows you to really do the integration in whichever way is needed.

10:02
Jonathan: Yeah. And then we can visualize that. Once we have that data and we've set up all the configuration on the back end on the SafetyChain side, you can then see that visualization and reporting of your OEE and we're going to demonstrate that a little later as well.

10:15
Geoff Nelson: So, that's what we'll jump to now. So, that was the Ignition Module. So now, what does that look like in SafetyChain? So, this is what we call our reporting or our grid screen. It's just one click from the homepage to get here. And now, we can quickly start to see and visualize the data. So, all the data that comes in, whether it's from Ignition, from a user on their tablet or on their phone, on the PC app or even a web-based browser interface, they can put their data within SafetyChain and it all here lives together. So, if you wanna perform analytics, deep dive into the data, you can have your automated data right next to your manually collected data and start to make decisions. Once you come in and start to look at your data, so it looks like I am here looking really at our kettle temps. You can also start to then perform actions. So, you can create tasks to assign to users. So, for follow-up, you can trigger notifications. So, if this is out of compliance, you can also do verifications. So, you can create your own sign-offs and verifications within the system.

11:23
Geoff Nelson: So, if you're doing data verification, pre-shipment review, that all is done within SafetyChain. So, you can have your processes built out and start to see the digital plant management part of it. So, I'll just show here the verify and I don't know, Jonathan, this is your site more than mine. Is this data verifiable?

11:44
Jonathan: Yeah, for sure.

11:45
Geoff Nelson: Well, you see here, so we had Sign-off, Record Review, FS Coordinator and Pre-shipment Review. So, those are verifications that have been built into the system, it's just all configurable and this data then can be verified and it's all tracked historically, so who did what when is not alterable. So, a person would come in here, so I would be here with my user, I would go verify these. So, I'd select the ones that I wanna verify, I'd sign them and I would put my note and then all that's tracked historically and so all these... So, those records have been verified for that verification that I picked. Do you want to jump in here a little more...

12:26
Jonathan: Sure, yeah. While I'm doing that, as I said, I worked prior to SafetyChain in food and beverage space. How many people here have been a part of an audit before? Raise your hand if you've been a part of an audit. Was that fun as far as like getting prepared and...

12:49
Geoff Nelson: No.

12:49
Jonathan: No? Yes?

12:51
Geoff Nelson: Audits and fun.

12:52
Jonathan: I like to do audits on the weekends maybe. Yeah. So, one of SafetyChain's big claim to fame would be having our customers become 24/7 audit-ready. And I'm gonna show you our Programs feature as soon as I remember where the link is. Here we are. And yeah, I've been a part of a few audits myself prior to going through digital transformation. So, we're talking filing cabinets, we're talking binders, we're talking going through old emails and work orders, it can be a headache and it's usually across a few days. So, when I came to SafetyChain, I learned about our Programs feature. It really resonated with me coming from industry and I'm like, "I wish I had this back when I was on the other side of the desk." So, what SafetyChain can do, as Geoff said, is we do a lot of customization of our forms so that you can capture those and you have record and documentation of that for future purposes. You can link those back to your food safety or internal program and be able to be audit-ready at any notice. So, if you have multiple clauses, we'll look at our HACCP one right here.

14:18
Jonathan: I like to think of these as kinda like those binders but in digital form. You can see all of your forms that have been linked to that specific program so that if the auditor was to come in and say, "Hey, I need to see records from this date to this date for this specific clause," it's right there at a few clicks of your fingertips. So, you can see all the records, you can see all of your documentation, so that means any SOPs or work orders and instructions that you have already listed specific to those clauses and that program, you can put that in there and it's customizable. So, we're not just doing food safety, we're not just doing SQF or HACCP in this case, but we can do an internal program that's specific to your specific company guidelines. So, if you have an EHS program or safety program, if you have maybe a GMP audit that you do internally, you can set that all up and have that traceability in there as well.

15:14
Geoff Nelson: You could do, like he said, internal binders or maybe customer or auditor ones. So, if you build one specific to what an auditor might look for, you can do it that way. And instead of having a piece of paper or a single physical drawer or location, these digital binders or programs, you can have multiple assignments. So, that form that we looked at like the kettle temps or any of those ones that we build out can belong to multiple programs and it's just at that form level so then any of the data that comes in will go to all these. So, if you filter for... If it's in Master Sanitation and it's in Food Standard 9, the data will all exist there without further mapping. So, there's nothing you have to do after the initial configuration.

15:54
Jonathan: Right. So, as far as all of the prep work, you do most of the lift up front when you're doing your configuration, setting up your forms, storing your documents and then from there, as you're collecting your data, as you're going through your typical everyday work processes, it's automatically going to its right place as related to your program. So, these are just a couple examples in our demo environment. As you can see, you got your docs, your forms and then your records for a given time. You can go out longer. So, this is the date and time filter at the top. So, if you wanted to go back three months, you could do that and you'd have even more records there. Yeah. So, here we go with the same HACCP one that we were looking at. It's got 492 records and so if an auditor was to come here, walk in today and say, "I need to see your HACCP records," I can pull that up pretty easily. Should I go into OEE now?

17:00
Geoff Nelson: Yeah, let's do it.

17:00
Jonathan: All right. So, another one that's near and dear to my heart would be around line efficiency and OEE tracking. I spent some time as a production manager, so knowing how the lines are running on a given day, basis, knowing where your opportunity is to reduce downtime is a very big deal especially in the manufacturing space. And that's where our OEE module comes into play. So, with the Ignition Module, as Geoff said, we have the OEE collector and we can map those tags back to our OEE solution so that we can generate this right here. This is one of our main screens here, this is live monitoring. So, in real time, we're capturing those tags and the counts from the machines coming from the line and we could tell whether the line is up or down, we could tell how fast it's running and we could tell if we've made our plan for today or where we're at in regards to what we were scheduled to produce. So, very impactful.

18:02
Jonathan: We have different screens, we could look at a more abbreviated version as well where you don't see the graph and you just can see at a high level. It's green, that means it's running. If it's red, it's down. You can see what your current rate is, obviously, what your total downtime is right there and what your current OEE is for that specific run.

18:21
Geoff Nelson: And here, we're looking at a single line but this is made for a multi-line, even multi-site so you can look across locations, built for scalability to look. Yep, here we go. So, he's showing two lines now. And so in the slim view, you might look at multiple... There's different views even to make them even smaller. But you might put it up on a screen down at the plant floor, pull it up in your office, put it up on your phone at a different site to get you visibility into how you're performing. Are you currently down? Why were you down? Why are you not meeting your goals?

18:54
Jonathan: Right. Yeah, this is a lot more lines here now. So, yeah, this view kinda... I'd say like the supervisor, manager/operator view, so you can see specifically what's going on on your production floor from an OEE standpoint. And then from a reporting standpoint, we have some out-of-the-box reporting as well where you can focus in on how you're doing as a plant but also if you were looking at an enterprise view, how you're doing across all of your plants. As Geoff said, we're very scalable. So, if you had multiple plants, you could see how specific SKU was running across your different plants if they shared SKUs. This is the enterprise view right here. I need to go out in more time to skip data.

19:56
Jonathan: Here we are. So, you could see how each location is behaving, you could see how your shifts are trending, if you have one shift that's doing a little better than others, graveyard shift might be taking breaks when they're not supposed to, get your OEE by line and then also by SKU down here. And then another good one is our top five reasons like Pareto. So, figuring out where your biggest opportunities are from a downtime at the source and reason level. And then, we also have some customizable reporting as well in our report builder. So, even if you don't see exactly what you want here, odds are you can use the raw data to build that in SafetyChain as well. So, we have customers that wanna see something specific or specific tables, they're able to build that with the raw data that's being collected via the tags. All right, we are about 20 minutes in. Do you think we should take questions now or is there something else you wanted to show?

21:08
Geoff Nelson: Let's show... Can you show SPC real quick?

21:11
Jonathan: Oh, yeah... I'll let you do it.

21:13
Geoff Nelson: You know the data though, right?

21:15
Jonathan: You talking about the Ignition?

21:17
Geoff Nelson: Yeah.

21:18
Jonathan: Okay. Let me...

21:20
Geoff Nelson: So, like he's saying, this is all out-of-the-box functionality and we do have report builders so you can make customized reports and dashboards. Most of our system, almost everything also can be done through API too, so you can pull your data out into other systems. The Ignition Module allows those screens that we were just showing to be set up really within minutes with a couple of tags per line to get your in count, your out count or even just your in count will drive a lot of those screens. What he's pulling up now is an SPC dashboard just to show a little bit more analytics to the data that we pull in. Was there not one on the main screen?

22:03
Jonathan: I'm not seeing the ones that I built, but I'll probably use one of these other ones.

22:07
Geoff Nelson: This is our demo site like Jonathan said. So, we use... A lot of people use this site for a lot of different reasons and it may look a little different from time to time depending on maybe who we're demoing to. So, he's searching a little bit. I typically don't go in here, Jonathan does a little bit more than I do.

22:23
Jonathan: With my login, though.

22:25
Geoff Nelson: Oh, right, yeah. This is my login.

22:28
Jonathan: Let me change the secure profile.

22:30
Geoff Nelson: I don't know why my browser's doing that, that's weird. So, as you can tell, this is a part we didn't rehearse, guys. But you saw that chart before. We have a lot of out-of-the-box charts for your data to start populating. Is there one here? Hold on a second, this mouse works. Does this one work?

23:01
Jonathan: I haven't seen that one...

23:05
Geoff Nelson: Well, this is what I get for doing this. But you can build SPC charts that will show up on a dashboard. You can also have ones that will show up on the tablets. So, when a user's entering their data, as soon as they hit submit on the form, it'll pop up the SPC chart to show you how data has been doing across the line or the shift or the day and it could be paired with the Ignition data too. So, if you wanted them to be paired, they could be paired. And then what we're trying to show here too is kinda the plant management piece. We showed you verifications on your data, we show all the data that exists, the forms you can create. Those are all customizable. We also have ones that are kind of what you see over and over again like our OEE and production ones. Those are pretty basic. I mean, they're kind of a template or standard that we do over and over again. We showed you programs so you can collect your data and be audit-ready. We showed you the OEE and productivity screens and... Oh, here we go.

24:09
Jonathan: This is what I was looking for. Okay.

24:10
Geoff Nelson: This is what he was looking for and some SPC charts so the data can come in, you can be looking at your control limits. So, we have compliance, whether a value is in or out of compliance, so pass or fail and then we also have SPC control limits which are different. Are you in control for your process? We have alarming and alerting for different rule violations. So, you can see here the different rules you might violate. This data looks pretty good, so it's not really violating anything. A little bit crazy stuff. But a lot of out-of-the-box SPC charts, some reports and then you can build your own, customize like Jonathan said. So, with that, I think we will turn over for any questions. Yeah, back there.

24:51
Audience Member 1: First question, how does the licensing work on the module?

25:00
Geoff Nelson: Good question. Adam, do you wanna answer that? No. The module itself in the showcase is free. So, the module itself is free. And then in SafetyChain, we build into the licensing. We license by location, not by user. So, a specific location can have as many users. And then whatever you're purchasing is kinda how we do the cost. So, integrations typically has a cost to it. I think right now we're doing a deal on the IoT piece. Is that right, Adam?

25:27
Adam: Yep. Correct.

25:28
Geoff Nelson: So, if you... Till the end of the year, for now, I think it's a year free on the IoT piece. So, you would just be paying for SafetyChain on a per-location basis.

25:38
Geoff Nelson: Right now, our Ignition Module is sending data from Ignition to SafetyChain. We are frequently enhancing it, but we do not do bidirectional in the module. However, we do have APIs that can do just about anything. So, if you wanted to customize some work, you could pull any data down, record data, you could do tasks, really just anything. Not native embedding of a specific chart but this is all web-based. So, if you could embed a web page or like a browser framed, you could do that. But otherwise, the charts won't embed themselves. No. Was there a question over here? Yeah.

26:15
Geoff Nelson: So, your question was, basically can another system trigger events within SafetyChain? Is that right? The answer is yes, it can. And there are two ways really to do that. One, like I said, we have APIs that can do just about anything and you could call our either Task or Record API to create actions in SafetyChain. So, you could assign a task to a person to go do some work based on whatever other system was doing. The second one is, through Ignition, you could create a record in SafetyChain and that record could be tied to what we call a dynamic flow that says, "Hey, go do another thing." So, based on whatever you send us, we configure in SafetyChain somebody else to do whatever the work is. So, depending on whatever your use case is. So, yeah, you could definitely do that.

26:57
Geoff Nelson: Are the forms dynamic? Absolutely. Yeah, they're dynamic, customizable. So, you create your own from scratch. You can have fields that are hidden and dependent on values of previous fields. So, it's very customizable and dynamic. Yeah. Are the forms developed by a developer? No. So, it is a user interface where a power user would go in and create their form. Really the requirement there would be on change management, so deciding who has the power to go create forms. Because once you release it, that's it, everybody gets it. So, if you cause a problem or something that users didn't expect, then you'll hear about it. But yeah, it's a user interface for you to drag and drop fields and configure them. Yeah.

27:36
Geoff Nelson: Is there an enterprise piece? Yeah. So, that goes with how you wanna do your roles and permissions. So, you can choose a certain level of user that has access to edit and create forms and then nobody else has access. So, at an enterprise level, you could say, yeah, this is a group that we've created, maybe you pick a person per site or a region or however you wanna manage it and then... Yes, then they would be able to edit. And then you could even have a different set that can release them which means now that people can go use them.

28:02
Geoff Nelson: Good question. So, in the downtime, reasons are configurable. So, you would configure them in SafetyChain, so which options you have available to you and then users can come into that screen that we showed and just select the reason for it. So, you can do a category, you can do a source then you can do a reason.

28:17
Jonathan: Right. And there's a free text portion as well if you need to add more information and detail.

28:22
Audience Member 2: You said you were getting that... Does your tag fill that out?

28:26
Geoff Nelson: You can in our downtime tracking with our automated downtime tracking, you can do that. Yeah. And I think we're just about out of time here. Was there one more back there? Yeah.

28:35
Audience Member 3: Does it have access to if a user enroll info from like Azure Active Directory or Ignition?

28:44
Geoff Nelson: We do have SSO available. It's SAML 2 or OpenID Connect is what we support. So, yeah, Azure, Okta. I mean, just about any of them. Yeah. Last one here. Last one.

28:55
Audience Member 4: So, you said you have these apps, mobile app as well. So, if we are performing audits and on the shop floor, there's no internet connectivity, do we have like saving in offline...

29:04
Geoff Nelson: We do have offline mode and then when connection's restored, it will push back up. Yeah. So, on those native apps, it's offline mode. So, when you go down, it'll store it. Okay. I think that's all the time we have here. Thanks, everybody.

29:14
Jonathan: Thank you, everyone.

Sepasoft’s workflow solution can map out and execute the production process for almost anything – including made-to-order bobbleheads! Our demo will showcase how simple it is to manage production workflows, collect real-time data, and utilize document management with 3D models and form entry. We’ll also highlight how to authenticate and verify every action during production for compliance and accountability using Electronic Batch Records (EBR) and electronic signatures. Join us to see the latest Batch Procedure technology in action.

Transcript:

00:00
Tony Nevshemal: Hey everybody. Welcome and thank you for coming to our session today. I'm really excited to be here at ICC. It's actually my first ICC. But when I started... Well, today, my colleague Doug and I, sorry about that, are gonna be presenting "Sepasoft's Workflow Solution: Building Bobbles with Batch." We're gonna be building these really cool bobbleheads today using Sepasoft's Batch [Procedure] Module. And within Sepasoft, there's often been some controversy about how we start... How we named our module "Batch" because it's, some people think it's a misnomer. That it only applies to batch manufacturing. However, it truly is a workflow solution. It'll handle any workflow that's incorporated or associated with your manufacturing, and we intend to show you something of that today.

00:55
Tony Nevshemal: My name is Tony Nevshemal. I'm the CEO of Sepasoft, and I'm also the new guy, having joined just recently. Many of you know Tom, Tom Hechtman was the prior CEO of Sepasoft, and he has transitioned to the CTO role where he's in charge of the product roadmap, product innovation, and thought leadership. Prior to joining Sepasoft, I was actually at, a CEO of an ERP, a manufacturing ERP. And prior to that, I was an operations director at a large manufacturer. I'm very happy today to come down the Purdue pyramid to level three where all the cool kids are and one of them is Doug. So Doug, introduce yourself.

01:38
Doug Brandl: Yeah, thank you. My name is Doug Brandl. I'm an MES Solutions Engineer with Sepasoft. My background is, I've got 10 years of experience in pharma as an automation engineer and consultant, and then application development before then. But I grew up around the MES space, I grew up around the standards. My father was really involved in them, and our dinner table conversations with me and my brothers and my family often involved talking about operations, responses, and all the different object models. It was a bit nerdy, a bit geeky, push the glasses right up your face. But I've got an ingrained, internalized understanding of the space and I've been with Sepasoft for a little over a year and thank you to everybody who went to our session last year, and thank you for coming to this one today.

02:36
Tony Nevshemal: Well, and before I joined, I endeavored to take all the training classes at Sepasoft for all of our modules. But one of the training classes I have not taken yet is our Batch [Procedure] Module. So Doug is in the unenviable position of walking me through our Batch [Procedure] Module, the unit procedures, changing up a recipe, and you guys get to see it all in real time today. A quick word about Sepasoft before we proceed. Sepasoft is of course an Inductive [Automation] Solutions Partner. We have the broadest and deepest MES solution on the platform. We have batch processing production workflows, we'll be showing some of that today. We have genealogy and WIP inventory with our Track & Trace Module. ERP connectivity, we can hook up to pretty much any ERP, and we have a direct connector with SAP.

03:31
Tony Nevshemal: We're well known for our production efficiency and scheduling with our OEE and downtime, quality tracking is handled with SPC. We have a bunch of ancillary modules such as settings and changeover, document management, barcode, those types of things. And you can control it all at the enterprise level with our multi-sync management, multi-site management, not sync. I'm very happy to tell you that this week we're announcing another bullet point added to this list, and that's SepaIQ. So please come to our session on Thursday. SepaIQ is really an exciting breakthrough that we've made, that Tom's made, and it relates to our manufacturing, machine learning, AI, data contextualization, all of those topics. So please come to our session on Thursday to learn more about that.

04:21
Tony Nevshemal: And finally, a quick word about a change we've made regarding our Quick Start program at Sepasoft. Our Quick Start program is effectively access to our design consultation engineers. We've opened up that access to be universal to any and all Sepasoft customers. So to the extent that you need expertise with your MES project, whether that's at architecture, design, implementation, rollout, consider us part of the team because when you succeed, we succeed. So I think that's enough of that. Let's get into the presentation.

04:55
Doug Brandl: Yeah. To give everybody some context on what we're doing, we are receiving orders from our ERP system for made-to-order bobbleheads. And we're going to run through to assembly, and we're going to try and highlight, and I challenge you to think of it this way, the procedural control and workflow of what it takes to go from order to execution of making these bobbleheads. And Tony will have to put them together for us. We're gonna leverage our best procedure tool, we're gonna use our Track & Trace modules. We'll, hopefully, if we have time, be able to see some of the genealogy of lot consumption, and you'll see a handful of our components that we use to do all this and our recipe editor.

05:43
Tony Nevshemal: Yep.

05:45
Doug Brandl: Alright.

05:45
Tony Nevshemal: Alright.

05:46
Doug Brandl: So first things first, you guys are gonna have to excuse me, I've got to turn around to do this. We're gonna refresh our orders off of our ERP system, and I like this bobblehead for the Sepasoft company logo, that's awfully convenient that one's right at the beginning. So we're gonna go ahead and start a batch, and as you can see, we've got our batch ID, proceed to the review page before we can assemble. So what we've got here is, this is just a standard Perspective page, we've got our document viewer, which is an HTML5 WYSIWYG. You can do a lot of things in it, a lot of really cool things. In this case, we're embedding a WebGL model, this we do with the help of the Web Dev Module. And over here on the right side, we've embedded some form entry fields and all of this gets tracked to the batch, this gets tracked to the electronic batch record, the EBR, and I'll show you what all of that looks like here in a minute. But I guess probably before we go, I should give you a quick overview of the recipe so that we can...

07:00
Tony Nevshemal: Yeah. Is there a way to graphically view that?

07:01
Doug Brandl: Yeah. I put a little slide out here. Right over here is a visual representation, and this is also very similar to... Sorry. This is our recipe that we're gonna be executing and we here have "Review Station" which in this case is gonna be my computer where I'm going to do some 3D model review. We're going to do some authentication challenges. This links into the identity provider provided by Inductive [Automation].

07:29
Doug Brandl: And we'll challenge for some electronic signatures. We've got some logic that we can do to that where you can require double signatures, you can set up which roles need to be to gate certain steps. And then after our review, if we're happy with our model, we go through the assembly, so I have an equipment phase here. If you're not familiar with the standards, think of the phase as like a step. In this case, this equipment phase is a simulated PLC where I'm going to send to our printer, our 3D... Our beautiful Amazon printer here. Our 3D models that we're going to print, we're going to e-sign to make sure it didn't turn to spaghetti, and then we're going to measure, record the values to our SPC modules and then assemble our 3D, our little 3D bobblehead. Alright, so Tony.

08:26
Tony Nevshemal: Yes.

08:27
Doug Brandl: Well, I guess this is all me, I'm the reviewer. As far as... This looks appropriate to me. I'm not really seeing any mesh errors.

08:36
Tony Nevshemal: And all components, all three are present.

08:38
Doug Brandl: Yes, all of this is present. So I'm gonna go ahead and click through these and I'm gonna say this is all good, and I'm going to... You can't see it in the bottom right because it's covered by my shadow, but down here, we've got our button to finish this document. Now, when I do this, I'm gonna slide this back out. You can see where you've been and where you're going with our batch monitor. And when I click on this and expand it, I can see all of the relevant metrics that we're capturing as part of this step. I can see, right up here, I can see the model is appropriate. So this is really good for auditing and figuring out what really happened during the execution of a batch. Slide this guy back out, and I can see I've got an e-signature required to complete the review step.

09:28
Doug Brandl: I will go ahead as a reviewer, do this challenge, so here I am Doug, and my password. Alright, I accepted that. I could also reject it, which in our batch, in the recipe that you saw or branches, you can get pretty complex in your conditions that you put in there to do really whatever it is that you need. Next up, I guess we go to our assemble stage. Here, this is just a simple Perspective page that I put up tied to our fake little PLC. You can see I say that the state is running. Our PLC is saying that it is running, but in reality, it is waiting for some filament. So Tony, if you don't mind, could you scan some...

10:21
Tony Nevshemal: Sure. Beep.

10:24
Doug Brandl: Perfect. Alright, there we go. Okay, now we're off to the races. So, while this is running, I'm just capturing a handful of metrics, we're looking at filament consumed, layers printed, extruder speed, etc.

10:35
Tony Nevshemal: How did you build these screens?

10:37
Doug Brandl: Yeah, this is just standard Perspective. All of these are tag-driven, so this, when you install our modules, you get an MES tag provider. And as you configure which phases, which, as you configure the batch module, you can expose each step when it executes for a particular unit, you can expose all of those values as tags. So all of these are just tags, and I just... It's a very simple like plain old Ignition Perspective. And then, again, on this while it executes, I didn't pull it up fast enough, but we are tracking, you see Base_Out at the top, we see filament. These are material transfers, so this is actually piggybacking our Track and Trace Module. It allows us to consume material, track lot usage, and we'll see that hopefully at the end with our trace graph, and then it'll also... You get a file name, you get the extruder speed, all of that gets tracked live, and you can store those values as they change, you can store the last value, so that you can... And you can see all of this in your EBR at the end after execution.

11:56
Tony Nevshemal: And for those that don't know, what's an EBR?

11:58
Doug Brandl: Electronic batch record. Alright, so we'll go over to our measure. I forgot I have a e-signature here. Alright.

12:07
Tony Nevshemal: Well, it looks like they printed.

12:09
Doug Brandl: Okay, they didn't turn to spaghetti.

12:11
Tony Nevshemal: No.

12:11
Doug Brandl: Alright.

12:12
Tony Nevshemal: We got the parts.

12:13
Doug Brandl: So I'll go ahead and sign off. Or would you like to sign off?

12:16
Tony Nevshemal: Sure.

12:17
Doug Brandl: Yeah. And again, this is any identity provider in Ignition that you set up, so you don't need to do anything crazy, it's just part of the platform. Alright. Now we're good, hopefully. Well, I hit the login button. Now we're good to go to our measure. Alright, so we've got some annotations now here on our 3D model. Tony, I need you to take some measurements here.

13:00
Tony Nevshemal: Okay.

13:02
Doug Brandl: So let's look at the head first.

13:04
Tony Nevshemal: Which one?

13:06
Doug Brandl: And I want you to get the diameter of that section on the 3D model.

13:15
Tony Nevshemal: So that is 6.12.

13:17
Doug Brandl: Alright, and then let's go to the base. If I can put that. There we go. Now we're gonna grab that right there, the diameter.

13:32
Tony Nevshemal: Alright, 6.16.

13:37
Doug Brandl: And then finally, let's go for the spring diameter.

13:43
Tony Nevshemal: 6.02.

13:47
Doug Brandl: Perfect. So I'll go ahead and complete this step. Now, I don't know if you guys noticed, but part of our process, we measure, we record the values to SPC, which it popped up while I was looking away, but we record the values to SPC and then we go to assembly. But we may run into a problem in the future, so I think there's an opportunity for us to modify this recipe and for Tony to dabble in the batch recipe editor, so we are good there. Now it's just assemble.

14:19
Tony Nevshemal: Alright.

14:19
Doug Brandl: If you don't mind.

14:22
Tony Nevshemal: So how do I assemble?

14:23
Doug Brandl: No, that's...

14:24
Tony Nevshemal: Okay. So you take...

14:25
Doug Brandl: Yeah. Take the spring, put it in the hole. Now, obviously you use your imagination and your projects, this could obviously be significantly more complex. You don't have to use a 3D model like we are here, you could use documents. We can retrieve these out of controlled document management systems. The world is your oyster when it comes to this. Alright, cool. It is assembled. I'm gonna go ahead and complete the step. Alright, so we have, we've completed our assembly and now we're gonna send the label to the printer and that's that. But we did notice that there are some opportunities. So Tony, if you don't mind, I'd like for you to go ahead and go into the recipe editor and modify the recipe, and let's see if we can account for times where... Let's go with the spring is not gonna fit in the hole. We're not gonna be able to assemble this. So we've got our happy path, we've got our green path through this workflow, but we don't have a red path, we're not handling exceptions appropriately, so this is a great opportunity to show you how easy it is. So Tony, can you open up the assembly unit procedure on the bottom left?

15:39
Tony Nevshemal: Sure.

15:41
Doug Brandl: And scroll on down, and after the "Record Values" and the "Record Transition," we're going to insert a branch into this workflow, so you can delete that line right there. And then I want you on our logic controls here in the editor to drag on "Or Begin." What this is gonna let us do is this is gonna let us say, "When this condition is met, you go down this path. When a different condition is met, you go down another path," etc., etc. And you can change these. So connect that, and then we're going to put in those conditions.

16:16
Tony Nevshemal: Okay.

16:16
Doug Brandl: So if you could drag two transitions in, the transition is where you're going to be able to put in that expression, and we'll have one for our green path and one for our red path. Or happy and sad path. And go ahead and connect those guys. Perfect. And then let's edit. You can connect them to the next one as well.

16:41
Tony Nevshemal: Sure.

16:42
Doug Brandl: And then let's go ahead and edit that transition. Let's give it a name.

16:47
Tony Nevshemal: So this is good measurements, right?

16:49
Doug Brandl: Yes. And then this transition expression, so this transition expression, what we can do is we can look up through the recipe, through what's been executed, and we can pull out some of those metrics. So we had our operator record on that document, we had them record the diameters of the spring and of the head and the base, so what we're gonna do is we can grab those values and apply some rudimentary logic. So Tony, we called it "measure," is the name of that step, of that phase. "Measure" and then you're gonna say ".diameter" and let's go. So in this case, our good one is when the spring is smaller than the head and the spring is smaller than the base.

17:35
Tony Nevshemal: Right, so when the spring...

17:37
Doug Brandl: And, nope, we don't need to...

17:44
Tony Nevshemal: Oh yeah. Just less than...

17:46
Doug Brandl: Yeah, maybe too tight.

17:47
Tony Nevshemal: "Measure.Diameter_Spring" is... "Measure.Diameter_Base" right?

18:19
Doug Brandl: Yes.

18:20
Tony Nevshemal: Okay.

18:21
Doug Brandl: Go ahead and save that. And then let's do the same for... Let's do the inverse, the logic inverse of that for this red path, so let's just call this "rejects."

18:31
Tony Nevshemal: Reject.

18:31
Doug Brandl: Reject measurement. And then our transition expression is going to be when the spring is greater than or equal to the base, or the spring is greater than or, and... Is greater than or equal to the head.

19:00
Tony Nevshemal: Spring, is greater than or equal to. What did I do first?

19:11
Doug Brandl: You did the head first.

19:12
Tony Nevshemal: Alright, so this is base. Okay.

19:13
Doug Brandl: Perfect. Save. And then what do we... What do you think we should do?

19:19
Tony Nevshemal: Well, let's say... So if it fails its measurements, that means you're not able to assemble. So we should probably tell the assemblers.

19:27
Doug Brandl: Yeah, probably don't wanna waste their time.

19:28
Tony Nevshemal: Right.

19:28
Doug Brandl: Yeah. So let's throw in a user message. So we have some built in... You have like a whole standard library of phases that you can drop in. And in this case I've configured it so that our assembly station can have a user message. So if you can just click that, drag it over into that unit procedure and connect it. And let's go ahead and configure it.

20:00
Tony Nevshemal: So we'll call this "notify"?

20:02
Doug Brandl: Yeah, like "notify operator" or something.

20:04
Tony Nevshemal: Yeah. Okay.

20:14
Doug Brandl: And then let's just give them a message down at the bottom where it says "parameter value."

20:21
Tony Nevshemal: Yeah. What do we wanna say here?

20:24
Doug Brandl: Let's just say "assembly not possible."

20:25
Tony Nevshemal: Okay.

20:26
Doug Brandl: We'll keep it simple. In your own projects, I'm sure that you'd probably wanna put more in there. And then go ahead and save that.

20:33
Tony Nevshemal: Yep.

20:33
Doug Brandl: So I'm not covering it. But you can also do calculations where you can pull in values. So a lot of our phases have that. Yeah, let's go ahead and require acknowledgement on it.

20:43
Tony Nevshemal: Yeah.

20:44
Doug Brandl: There's a lot of ability to make it dynamic so it's not all static. It's not like you're always gonna say the same thing. Sometimes you want to include values from previous steps or maybe include batch parameters as part of the message or part of any other phase. So we do have also the ability to include that as part of like a calculation. But we're not doing that here. So let's go ahead and hit save.

21:05
Tony Nevshemal: Alright.

21:08
Doug Brandl: And then we're gonna put a transition on this. So every phase needs to have a transition after it's done. And in this case, we're just gonna say "complete." Once the notification has been sent and this phase is... The execution of it is complete, we'll continue on and we'll terminate the batch. So you can go ahead and insert suggested here. And what this does is it's gonna look at the link up and just say whenever that step is complete. And this is good. We'll go ahead and save it, and then put on a terminator in the logic controls on the...

21:39
Tony Nevshemal: Let's try it without a terminator.

21:41
Doug Brandl: We can't do it.

21:42
Tony Nevshemal: Can we validate it?

21:42
Doug Brandl: Yeah, you wanna validate it? So if you don't do this, we do have some validation of our recipes where it'll look at it and it'll tell you what's wrong. And in this case, it's saying the assembly unit procedure, UP5 transition needs to be followed by something.

22:00
Tony Nevshemal: Okay, cool.

22:00
Doug Brandl: Let's go ahead and drag the terminator on and connect it. And then let's validate. Again, make sure that that resolved that issue. Recipe is valid. Cool beans. Let's save it.

22:16
Tony Nevshemal: Alright.

22:21
Doug Brandl: Alright.

22:22
Tony Nevshemal: Right. Let's run it again.

22:23
Doug Brandl: Yeah, so we'll fly through this for the second time so that we can get to questions since we've got four minutes to go. So, alright. This is gonna be the world's fastest 3D printer here. I'm gonna go ahead and kill all of these old orders. These are on the old recipes. So we do version our recipes. So these are using, it's the version 61 of that recipe. We're going to reset this and I'm gonna go retrieve some more orders from our ERP system and that'll be version 62. So refresh orders right here. Alright. So this is the same steps. I'm gonna go fast for the sake of brevity.

23:04
Tony Nevshemal: Let's quickly review them.

23:05
Doug Brandl: Yep. Oh, this looks great. We've seen this one before. Check, check, check. Check. E-sign. I'll go in as an admin. Password.

23:21
Tony Nevshemal: Cool.

23:22
Doug Brandl: Cool, cool, cool. Close those.

23:24
Tony Nevshemal: It's printing.

23:25
Doug Brandl: Yeah, let's go over to our print. Beep boop, scan the lot. We're printing. We are printing at 50 layers a second.

23:36
Tony Nevshemal: Yeah. It's screaming.

23:37
Doug Brandl: This is a fast printer. I can tell who has a 3D printer in here and knows how frustratingly slow that they are. Alright. We're gonna have an e-signature.

23:50
Tony Nevshemal: Okay.

23:51
Doug Brandl: Verify it didn't turn to spaghetti. So I'm gonna go ahead and sign that one as well. Tony, it didn't turn to spaghetti, did it?

24:00
Tony Nevshemal: It did not. We have something.

24:03
Doug Brandl: Alright. So now we're on our measure step. So this is after this step is where we added our transition. So let's go ahead and measure the head outer diameter.

24:16
Tony Nevshemal: Okay, that is 6.2.

24:20
Doug Brandl: 6.2. Let's measure the base.

24:25
Tony Nevshemal: That is 5.9.

24:26
Doug Brandl: Whoa. Now let's do the spring.

24:33
Tony Nevshemal: That is 6.02.

24:35
Doug Brandl: 6.02. Alright. So clearly we are gonna violate our recipe. So when I do that, let's go ahead and take a look and see what happened. So right here, I expand this. Sorry, let me make this a little bit bigger here. I just like watching him walk back and forth with the shadow. So here you can see this transition. So we proceeded down this route here and you can look at this transition and you can see what specifically caused us to go down whatever path it was. And in this case, it was our spring is greater than or equal to our base. Our base was too tiny or our spring is too big. And then we have our notification. So that notification's up on the top right here. And we did require acknowledgement. So I'm gonna go ahead and sign in as an admin. Password.

25:35
Doug Brandl: And here we have our... Just a standard batch message list. This is, again, one of our components where I can click on it. Assembly not possible. I'm gonna acknowledge that. And again, all of this is tracked to the EBR. There's an awful lot that I wanna show you guys as it relates to our EBR, as it relates to our trace graph. I'll hit the trace graph really fast and then I think we're gonna have to go move on to Q&A. And if you want more you can come over to our booth and I would be happy to show this to you. Alright. So here I'm looking at all of the different types of filament, all the different batches. So here what I'll do is I'll slide that over. So right here I can see we have a completed bobblehead. This right here is the assembly unit procedure for that particular batch.

26:24
Doug Brandl: Looks like it was one that I had done on the fourth, I guess. I could see which filament I consumed. I can get the lot number for the base. So I create... As part of this step, I'm also creating that lot. I can see everything in and I can see all of the material that is created as part of it. And then if I click here, I can see all of the five other batches that use this same material. So this is really useful if you're looking, if you're doing any investigations for quality, for recall, any of that stuff. So this is a really good way to visualize, what did I use? I received green filament and I have it on this particular assembly, this batch right here. So I know all of the bobbleheads that came out that used that specific green filament. And this trace, there's not a realistic limit on this. So it does run back. You can chain all of your material transfers back and forth. I think that's all I've got time to show. Does anybody have any questions? I think it's the Q&A time. Yeah, go for it. Oh, she's going to give you a mic. Yeah.

27:39
Audience Member 1: The object model that you have, the recipe, like how accessible is that? Let's say that I've got basically something that's dynamically generating parts from like a pick-and-place machine, right? And I'm not gonna have all that data until it hits the end of the line as a transaction. Can I write all of that at once? Can I then query essentially every transaction I've had for these measurements and get something like capability? Or am I gonna need to layer in other modules like traceability and SPC to do that kind of stuff?

28:07
Doug Brandl: So if you're doing anything with material tracking, you're gonna need the Track and Trace Module. So material transfers as part of the batch. So you could do all the built-in phases, but when it comes to material in and material out and tracking any of that, and suppose you've got 100 different types of dynamic materials, you can set those for the material in property on the phase. So if you want, I can show that to you probably over at our booth. I can show you what that looks like. But yes, you can do that. But it does require the Track and Trace Module.

28:41
Audience Member 1: Okay.

28:42
Doug Brandl: Yeah.

28:43
Audience Member 2: Hi. Is there an array-based entry? I see the graphical method to put all these essentially routes in, but is there an array base or some other way that you could do it in bulk and not all the clicking and dragging?

28:57
Doug Brandl: Yeah, you can script this too. You can script the creation of recipes, of batches. You could pull it, some people even pull it out of their ERP system and dynamically create recipes. So all of this is backed. So we have this frontend here, we have these components. If you don't want to click and drag and you've got some more complicated system, you can script the creation of all of these recipes. And the execution. Yeah.

29:27
Audience Member 3: Does the system have a functionality to do order maintenance to modify existing batches in run to reflect the new recipe?

29:36
Doug Brandl: At the moment, I don't believe we do. Yeah. I'll let Tom answer that.

29:41
Tom Hechtman: To start a recipe, that's a ISA-88 model. So you have your master recipe and you create a control recipe. So once that... Sorry. Once you create that control recipe and you're executing it, it's isolated from the master recipe at that point. Now, if you modify phase or templates, we have templates and different things like that, you do have ways to push those changes down into your recipe and such.

30:13
Audience Member 4: And you can create something... Are there already existing scripts to help facilitate that that you need to customize for your use case?

30:20
Doug Brandl: Yes. So I definitely encourage you to reach out for the Quick Start program, reach out to our design consultation team. They've got a lot of experience doing that.

30:29
Audience Member 4: Awesome, thank you.

30:31
Doug Brandl: Yeah. Any more questions you guys have, please come visit us over at our booth and I really, really, really encourage you come on Thursday to Tom and Mark's presentation. It is very exciting what they're doing. So show up if you can. Alright, thank you guys.

30:47
Tony Nevshemal: Thank you.

In today’s data-driven world, effective data management is crucial for manufacturers seeking to harness the full potential of their production assets. As industrial environments become increasingly connected, the need for a comprehensive data management solution that ensures real-time, reliable, and scalable communication is more critical than ever. HiveMQ with its enterprise MQTT platform that is highly reliable, scalable and secure provides that ideal platform working with the Ignition ecosystem. We will showcase some of our new product offerings like our Sparkplug module for DataHub enabling metrics fan out and other offerings that will complement the Ignition Edge platform, building the UNS framework to streamline data collection, integration, and dissemination, ultimately driving smarter decisions, greater operational efficiency, and supporting advanced use cases like AI.

Transcript:

00:00
Ravi Subramanyan: Good morning, everyone. Hi. So day one of ICC, and here we are, first session. I have the enviable task, or unenviable task, as one might say, of getting the day started. Hopefully I'll do a good job with that as people trickle in. I just wanted to introduce the topic. I know the topic is very relevant to what this conference is all about. It's all about open communication with MQTT, how that plays into the Inductive Automation ecosystem, along with Sparkplug, and of course, the new kid on the block, which is not new anymore. It's the Unified Namespace. Everybody's talking about it. Everybody wants to know about it, and everybody seems to have a solution for it. So understanding and unraveling that. That's kind of like what we are gonna take you on the journey in the next half an hour or so. I'm Ravi Subramanian. I work for HiveMQ, and I'll introduce HiveMQ when we get to our slide, but HiveMQ has... Wow, I like that.

01:02
Ravi Subramanyan: Seems like a rock concert here. HiveMQ has an enterprise-grade MQTT solution that is highly scalable, highly reliable, highly secure, flexible solution that plays well in the Ignition ecosystem, along with the Cirrus Link modules. We have a few customers that are using us, and we can talk about that case study as well. So for HiveMQ, I'm the Industry Solutions Manager for Manufacturing, so I focus on this particular area. I have seven-plus years of manufacturing experience, and I try to evangelize on behalf of HiveMQ on how our solution works well with manufacturing and vice versa. Do I help our salespeople make sure that they understand the manufacturing talk? When they talk to manufacturing or energy, or industrial customers, there is a specific language, there's a specific need, or specific use cases that we want to talk about, so that's what I do.

02:00
Ravi Subramanyan: So this is the agenda. I'm gonna jump right into it because we have only a half hour. Okay, so let's just look at, quickly look at some of the trends. I know some of these things are very, you guys are very, very familiar, but things like material shortage in manufacturing is rampant because, obviously, there is more need to manufacture goods, and the supply chain, as we thought, is ironclad; it's not quite ironclad, so there is, like, where is the material coming from? So what if the next pandemic hits? What are your backup plans? So those things continue to happen to be big issues. Carbon footprint reduction, that's something that every manufacturer is going through, not only for being like good Samaritans, reducing the CO2 footprint, but also for themselves to be more efficient in manufacturing and, of course, reducing the energy cost. Security vulnerability comes with the name of the game because, obviously, you're getting the data out of your ecosystem, so naturally, what you thought was like an air gap is not an air gap, so there is things that you need to worry about. And other things like supply chain, we talked about demographic changes, which is real. So the employees that can just hear a machine and then figure out what the issue is are long gone or on the way out.

03:14
Ravi Subramanyan: So new employees are coming in. How do you incentivize them? How do you make sure that they're able to perform to that optimal level? Last but not least, regulations and bureaucracy continue to be issues. So, Smart Manufacturing, what is that? So, again, we make a distinction between digitalization and digitization. So digitalization simply means just take the paper form that is used in manufacturing and convert it to digital; just scan it in into a digital format. That's the simplest thing, but 80% of the customers or 80% of manufacturing is still on paper, which is shocking, so going beyond paper. But then, beyond paper, you also need to combine that information coming in with other pieces of information in real time from equipments and combine that with information coming in from IT systems so that you can drive those insights.

04:06
Ravi Subramanyan: That's kind of what Smart Manufacturing is all about. And why is it important? You can see the growth projection over the next five years now or so. So let's talk about the power of Smart Manufacturing. Again, why Smart Manufacturing is important. I'm not saying it, McKinsey is saying it. Within one year of implementation of a Smart Manufacturing solution, this is what you can expect. These are the gains you can expect to get in using Industry 4.0, which we'll talk about in the next slide, and the technologies that come with Industry 4.0. So, again, what is Industry 4.0? It's all about all of these technologies that come together, which includes industrial IoT, which includes robotics, AR, VR, smart sensors, cloud computing, all of these things coming together to ensure that you have real-time information, you can power predictions, you can make your factory autonomous, you can create new revenue streams. How? Because you have the data that gives you some insights which you didn't have in the past, and then you can radically transform your operations with that.

05:10
Ravi Subramanyan: So, again, it's not just a revolution; it's an evolution. Why is it an evolution? Because when you get on the journey, it's not that you're done. So you have to be there for the long haul because things always change. So you have to be on this journey, and that's why it's an evolution. And these are some of the steps, so connecting, collecting, which we'll talk about. So getting the data together, collecting, assembling, and consolidating the data, driving insights, then that power, your AI and ML and predictive maintenance and other cool use cases, which can drive some of the KPIs that you have. So this is the typical, I'm not gonna spend too much time with this; this is how the architecture is and how the data flows.

05:54
Ravi Subramanyan: So, again, having some kind of a data management for the data flowing through all of these systems is paramount. Both at the machine-to-machine level and the machine-to-enterprise or the cloud level. So let's talk about that data management. So, again, so this is kind of like some insights from IoT analytics. They put out that AI being the next big thing; everybody's talking about AI, and AI is actually like powering the need for data management. So the data management market has significantly grown over the last few years, and it's projected to grow to $13.3 billion by 2020. And why? Because AI heavily relies on data management and the different aspects of it, which includes analytics, governance, orchestration, ingestion, and things like that. So if you want to do the modeling, you better have a proper data model available that you can trust, and that's why data management solutions are absolutely important, and that's why solutions like Inductive Automation, along with HiveMQ, along with Cirrus Link, and along with other players in this space are paramount to ensuring that you have the right experience when it comes to AI and predictive maintenance and things like that.

07:12
Ravi Subramanyan: So, again, what does it do? Again, it enables real-time decision-making, and obviously you're having a lot of data sources. So there's this huge variety of data coming from different locations. There is heavy velocity of data, the speed at which data is coming, and then the volume, how much volume of data. I think manufacturing is, it's overtook, I think, the World Wide Web as the biggest producer of data. You have all the data, but do you have the insights is the question. And then how you can drive that is by integrating all the data and transforming the data, and then you're ensuring that the data is trustworthy because at the end of the day, you can build your best models and you can build your best solution, but the moment you cannot trust that data, you're gonna lose your belief in that. That's what we are trying to do.

08:00
Ravi Subramanyan: We are trying to make sure that the data is ready, it's trustworthy, and ready to go. Yeah, this is kind of like the traditional ISA-95 model with all these different levels, and some of the issues here is that each layer is its own silo. It's its own snowflake, if you will, in some ways. And if you want to communicate, so you have to create a custom code that helps you interact between all of these different layers. If you want to go from shop floor to top floor, that's a lot of customizations that you need to do, and it's not replicable. And for you to be able to communicate between different systems, typically these things are point-to-point communication, which if your implementation is small, it's fine, but as it grows, this is where I think you get the spaghetti architecture, and it hogs the bandwidth. It's not efficient at all. That's where I think a solution like an MQTT comes in, and I'm sure a lot of you already know MQTT is that publish-subscribe technology, which makes it really easy for clients to publish data to a centralized broker when connectivity is available. The use cases are, for example, in a remote oil and gas upstream use case, or maybe in a factory where connectivity and bandwidth are limited.

09:18
Ravi Subramanyan: This is where I think it really helps you out, and the broker can then share that information with other clients on particular topics. Now, one of the things about MQTT is it's open. That's the advantage, but the disadvantage is also it's open. It's like you can create a topic structure however you want or the content however you want, which normally is fine, but in the case of manufacturing and industrial use cases, it may not quite work. There is a need for a particular structure around it. That's like the topic namespace as well as the payload content. You need to know the state of your machines. This is where Sparkplug comes in. Sparkplug adds that additional framework on top of MQTT that adds this information, and that's why Sparkplug, along with MQTT in the industrial use cases, is gaining popularity as well. And again, just a lightweight, bi-directional design for stateful context. These things are all reasons why MQTT and Sparkplug are gaining a lot of traction within the industrial use cases.

10:25
Ravi Subramanyan: So let's talk about HiveMQ. So HiveMQ, again, started in 2012, right after MQTT became open source in 2010. And so we built our solution on top of that. And what we did that is different from others is that we made it highly scalable, highly reliable, and highly secure. What does that mean? So from a scalability perspective. So you might have many, many, many different connections across your different factory locations or subsystems that need to be connected, and all of it need to be publishing and subscribing data at the same time. So concurrent connections with data going through, new connections coming in, and that needs to be enabled. So that is where scalability comes in. So one of the things that we do from our perspective is we have this clustering technology where we can add more nodes as needed. So it's like you can pad up or pad down the nodes so that you can scale up or scale down depending on your use case. Maybe you're a cyclical business; you don't need that scale all the time, but maybe sometimes you need that scale.

11:30
Ravi Subramanyan: That's what our solution is able to do by providing that high scalability. Reliability, as you know, MQTT already has a quality of service built into it: zero, one, and two. We are taking that to the next level by building additional reliability, like high availability, for example, using the same clustering technology, having multiple nodes within a cluster, replicate the data across all of these nodes, having a masterless cluster which can ensure that when one node goes down, the second node can automatically take over because guess what? The node is already capturing all of the information that the primary node is capturing, so it can automatically take over so that from a manufacturing perspective, there is no downtime, because every minute of downtime might cost dollars.

12:14
Ravi Subramanyan: It could be thousands or sometimes even millions of dollars, depending on where your production is. That's the level of reliability we provide. Security, the normal security, like X5.9 certificate authentication, like encryption data, TLS encryption, is all there, but we also take that beyond that to ensure that whatever other methods you might have from your security perspective is also enforceable on the broker itself. The other key feature that we have is what we call the data hub. We talked about data quality. We truly believe in the fact that data is obviously garbage in, garbage out. We all know that. So for you to make sure that for whatever use cases you are using that solution, it makes sense; you want to have the right data. For example, you might want the temperature to be in a certain format, degree Celsius, Kelvin; that's simple. We do that transformation to make sure that all the temperature values and the pressure values are in a certain format.

13:18
Ravi Subramanyan: You might want only the data to be in a certain range, for example. You don't want all of the data. Because A, it is not useful for you, B, it's like that's the only thing that you're concerned about. You want to enforce certain rules on which clients publish, can publish, and which clients can subscribe. Those are the kinds of things that the data hub can ensure. It's basically a software module sitting in our broker where you can create policies, and you can enforce those policies. You can also do transformations. For example, in some scenarios, Sparkplug may not be the most ideal because while it can talk to your industrial, the OT side of the world, no problem. Everybody can interpret that. But on the IT side of the world, people or systems don't understand that. So how can you make sure that the IT world is able to interpret that data? So you take the core aspects of Sparkplug, and then you can also convert the data to like a straight MQTT.

14:17
Ravi Subramanyan: And you can fan out all of the variables, all of the metrics that are part of Sparkplug so that, like an IT application, for example, like an ERP or a MES system, can understand that and then can take that and make a decision based on that or maybe a database or like some other cloud-based application. That's what we do. We ensure that we provide the best of both worlds through these transformations or through improving the data quality that will make sure that when you try to do your operations, when you try to go out and start off your AI projects or ML projects, you're ready to go and you don't have any bottlenecks and you don't have to have a separate project that you have to do. Like in a lot of cases, we heard that I'm starting off on a data project or I'm starting off on AI. I see the data; it's sitting in like this data lake, or some people call it a data swamp because you just like dump the data there.

15:15
Ravi Subramanyan: And then I have to spend six months cleansing the data, and I have to spend a lot of time figuring out like how the data can get into the format that I need it. So what we help you with is preemptively getting that in the format that you need so that you can then take and run with it and do your projects. One of the side benefits that people have said is that cloud is costly. So moving the data or ingress cost on AWS, Azure, and Google is costly. So why just take the data and just dump it all on the data lake if you don't even care about all of the data? Just selectively bringing the right data ensures that you also keep the cost down, you're focused only on the data that you need, and the data is in the right format. It is cleansed; it is what we call normalized because you might have this data sitting in so many different systems that need to be all normalized. Hey, I have this pressure point here, but I also have a pressure point data there in a different system.

16:11 
Ravi Subramanyan: How does this relate to that? So to kind of make sure that all of that makes sense and it's cleansed and it's brought together in a conceptualized fashion. That's kind of like what a Unified Namespace is, where you're able to bring all the data together into a single namespace, a Unified Namespace that you can then take and use it for any business decisions that you're trying to make. And so that's what we are able to enable. The one other thing that we also do is we recognize that there are a lot of systems that are non-MQTT; they don't talk MQTT. So for those systems, we're able to create these, what we call, extensions, which are application plugins. For example, streaming analytics platforms or databases, or other systems.

16:56
Ravi Subramanyan: We're able to take the data from our broker and then translate that into whatever formats they need through extensions that we have created. We also have SDKs that help you create new extensions based on what you need as well. So the other thing that we also do is we understand that the deployment of this system, this piece of software, needs to be flexible. So you can either take it and then put it into your virtual machine and manage it to yourself or you can put it into your version of the cloud. Maybe you already have AWS or Azure; you can do that. Or we also have a fully managed solution on our end which is available on AWS or Azure, or other cloud-based platforms. So that is completely managed by HiveMQ on behalf of our customers. So the initial tier, which we call the serverless, is free of charge for people to use. And then there are obviously additional features built in as needed to get to that enterprise grade as well.

17:56
Ravi Subramanyan: So people are free to try it out, and maybe for your use case, the serverless version works for you. So again, providing that flexibility to be able to interact with any application and not kind of like pigeonhole yourself into saying I can only work with the Azure or AWS ecosystem. So we believe in democratizing the data, which means that you should be able to work with any application in any particular system that you prefer. That's kind of like what we're trying to drive at. And on the left side, again, talking to devices, we have a client, which is MQTT, basically like a MQTT client library that can be installed in any device that can bring the data in the MQTT format. Or we can work with any popular gateways that are available, like Ignition Edge gateway, for example, that is able to publish the data in the MQTT format through the Cirrus link modules, which we can intercept, we can bring in, we are able to expose the tags, we're able to support the UDTs, and then bring the data in a highly scalable and reliable fashion.

19:01
Ravi Subramanyan: So that's the HiveMQ platform. Now let's quickly talk about Unified Namespace, and I want to leave some time for questions as well. So again, I already alluded to it. So basically, it's kind of like the single source of truth for all of the business data. Let's put it that way. Because you cannot say only OT data, because these days, your business data is a combination of your operations technology data sitting on your manufacturing floor, but you also want to bring in information from your ERP system or databases or CMMS or other applications that are not necessarily on the OT side of things, because the combination of all of this is that single source of truth for all of your data. That's what a Unified Namespace is all about. It has the ability, and it borrows a lot of the benefits of MQTT that I had talked about and the ability to conceptualize the data and bring it all together into one location. So when you look at your data, so it's able to catalog all of the business data in one location. Hey, what are my alarms? What are my events? What are things that are red? What are things that are green? So you're able to bring it all together visually so that if you see some issues, you can react to it.

20:16
Ravi Subramanyan: And these things can be sent as, maybe you can have a mobile app tied to it that can give you alerts and alarms and things like that. So it's just a quick way for people to understand the status of their business. That's what a Unified Namespace is. And just going back to that other architecture diagram, juxtaposed with Unified Namespace and how it enables the ISA-95 architecture to perform more efficiently. That's what we're able to do. And then there's something called federation of data, because you have certain data on the shop floor, you have certain data on your MES layer, some on the cloud, some on ERP. So you need to have various different levels of namespaces. Let's put it that way. Where you want to consolidate the data, and then ultimately you want to bring it onto your enterprise Unified Namespace. So imagine each of these are separate brokers. You have many different brokers talking to different subsystems on your factory, consolidating that onto your plant broker, for example, and then that is consolidating on your enterprise broker. And all of these are talking to each other through what we call a HiveMQ bridge, which is another extension. And the concept is called a federation of these brokers.

21:29
Ravi Subramanyan: So information can be easily sent back and forth efficiently. And this is kind of like an example of a typical Unified Namespace for a bottling plant, where you have data from different locations coming in, and you can see how the data is organized in a logical way. Again, there is no specific way to organize the data. We're not saying that it has to be the explorer model. It has to be based on the location and then all of the systems in the location. Sometimes you want to do, like I want to look at all of the alarms and I want to bring in all of the pressure data, for example, in one namespace, or I want to bring in all of the other information on one namespace. So again, it is completely dependent on customers and how they want to organize the data in a way that makes sense for them. So that's the beauty of a Unified Namespace. It provides a framework. Implementation is completely up to how you want to do it. Well, that makes it efficient. Yeah, this is kind of like just showing how it all comes together, and going back to the ISA-95 model, area, line, cell, and then you have enterprise. So again, bringing the data all the way from the line to the area, all the way to the enterprise, and how that all works and comes together to create that enterprise Unified Namespace.

22:46
Ravi Subramanyan: Yeah, that's just the final slide I have. So I know we have about five, six minutes. Maybe open it up to any questions you folks might have. Yeah. Yeah, yeah, that's a great question. And one of the advantages of the Unified Namespace and the way we are envisioning, ultimately building out that full finalized product, is you bring in the model the way it works for you. Some people prefer the ISA-95 model, but others prefer other models. Maybe Sparkplug, that kind of provides a model as well, but there's no kind of one-size-fits-all.

23:23
Ravi Subramanyan: So the tool itself will be able to take any model that you already have and just build it out based on that so that you can easily interpret the data. Yes, yes. So Data Hub is a relatively new software that we've added, both on the edge. So it can basically be deployed on the edge or on the cloud because it's all about going to the source of the data and transforming the data before it's brought to the higher layers. So there are scripts; there are modules that are already available. For example, if you want to move Sparkplug data and convert that to straight JSON or Google Protobuf to JSON, or you want to do a metrics fan-out from Sparkplug to just straight MQTT with all the metrics listed out. So those are things that we've already built out, but you can also use your own scripts, XML scripts, and bring it in to do whatever you want to do, and that will allow you to do those transformations.

24:31
Ravi Subramanyan: Oh, good.

24:32
Audience Member 4: And So is that module somehow available in the HiveMQ...

24:38
Ravi Subramanyan: Yeah, on the cloud, we are looking to add the module. We don't have that yet on the cloud. We have it on our on-premise solution, but we are looking to do that. That will, something that we're looking to do in this year.

24:49
Audience Member 4: Okay, thank you.

24:50
Ravi Subramanyan: Thank you. There's a question there.

24:55
Audience Member 5: Yeah, I have actually two questions. One, we heavily use brokering, and so we have situations where within Ignitions and all of our Ignition nodes, we use the Sparkplug, but a lot of our external applications we wanna use JSON. So if I understand what you're saying, you have a built-in extension that if I publish a topic in Sparkplug, you can republish that topic in JSON?

25:24
Ravi Subramanyan: Yes, yes, that's right.

25:26
Audience Member 5: And then second thing, one of the things we're seeing is if an example would be, you have a node that publishes a topic to a broker, and you have another node that is gonna subscribe to that topic. And then about 10 minutes later, another node comes along, and it needs to subscribe to the same topic. What happens is now the publisher has to refresh its data because the data is stateless. And everybody, so the new guy needs to know it, but that causes the publisher to be involved, and every time a new node comes onto the network and needs to subscribe to data, the publisher is involved in that transaction. Which means if a million subscribers come on at once, the publisher has to be set up to be able to perform well enough to publish for a million consumers. Can you, does your system make that work any better?

26:25
Ravi Subramanyan: Yeah, yeah. So again, this is a very, very specific question. We can certainly have our technical folks give a better answer, but my perspective is that we can; our solution ensures that there is some buffering that can happen in that scenario. And make sure that any new publishing or new subscribing clients get that information. There are ways, even within MQTT, to be able to do that, but we are able to also do additional things to make sure that that happens more seamlessly.

26:55
Audience Member 5: Okay, thank you.

26:57
Ravi Subramanyan: Yeah, Thank you. Couple of more questions. So we do have a booth upstairs. So please do stop by; we are happy to do a demo. I was trying to figure out if I can do the demo here, but I thought it would be better for us to have this Q&A session rather than the demo. But do stop by upstairs so we can obviously talk about your specific use case, and then we can give demo of that module that we talked about, as well as anything else you would like to know about HiveMQ. There's no other questions. I think we are good. Thank you so much. I think session one is in the books. Thank you. I will talk to you guys later.

Tired of closed PLC platforms with proprietary protocols and high licensing costs? This presentation shows you how Opto 22's groov products can help you break through the status quo in industrial automation. With groov EPIC and RIO systems running Ignition Edge out-of-the-box, you can control edge operations and securely democratize production data from the plant floor to IT systems—even to the cloud. Discover the open, cybersecure architecture and free support and training resources that make Opto 22 groov hardware ideal for your next Ignition project.

Transcript:

00:02
Dan White: Hello, Ignition community. How's everybody doing?

00:05
Audience: Good.

00:08
Dan White: Alright. My name is Dan White. I'm Opto 22's Director of Technical Marketing. I've got Garrick Reichert here with me. He's our Senior Application Engineer. And in the theme of "breakthrough" for this year's ICC, we're gonna present to you how you can break through the status quo in industrial automation. So I know you all came here to see a demo, but before we get into that, and Garrick's gonna take the lead on that, I am going to give you a little bit of context and who we are and what we do and how we've done it. So this is where we do everything. It's out at our headquarters in Temecula, California. Beautiful, sunny Southern Cal. Everything is done there. So the design, the manufacture, the support, all of our applications engineering, everything is done here in the USA at our Opto 22 HQ. And actually this year we are celebrating a big milestone. Just last month we were out at Opto celebrating our 50th-year anniversary. So how about that?

01:10
Dan White: Good stuff. And we plan to be around another 50 and we're gonna talk a little bit about how. So for those of you who don't know Opto 22 or haven't heard of us before, we are a 50-year technology innovator from SSR, solid state relays, and an innovative way to manufacture those back in the 1970s, to PC-based I/O and I/O and control systems, to mobility and web-based visualization, and IIoT. We're a market leader in intelligent and distributed I/O systems. We've got millions, hundreds of millions of I/O at over 10,000, probably more, global customers. Yeah, a worldwide reputation for quality, backed by our guaranteed-for-life I/O. So any Opto I/O, and we'll get into a little bit more of that later, but it is guaranteed for life.

02:02
Dan White: Unique in the industry for enabling simple and secure democratization of OT data. A lot of big words in there, but we're gonna talk about that in a minute. And of course, made in the USA and trusted by lots of companies all over the globe. So what is the problem that our products are... That our company is trying to solve with these products. A big part of it is what you see on this screen. So picture's worth a thousand words, and I'm sure many of you guys have seen things like this architecture out in the world. Does this thing have a little laser pointer? So complicated, layered architectures with unsecured connections and closed-off systems. And we're trying to simplify that for you guys. We know what you see out there. We know what this automation stack looks like but the status quo will not suffice.

02:53
Dan White: Using devices like this one that Garrick is gonna demonstrate for you in a bit, we can simplify that architecture. We can provide valuable production data to stakeholders all across the business, all across, and you can do it all with the best cybersecurity tool sets on the market. So what are these products? Well, in theme with Ignition, we've got what we call Ignition I/O, or Flexible I/O on our groov RIO. So the groov RIO is a single block of I/O with software-configurable, eight software-configurable I/O points. It's got two output relays and it even runs Ignition Edge right on board. We've got another version that does energy monitoring. And in my early days with Opto 22, I actually came in as a customer of Opto 22. And what really drew me in was the modularity. And in a lot of ways, that's really what draws a lot of us to Ignition, is that modularity of the architecture. You don't always need everything. Sometimes a little piece will do. Sometimes you need more.

03:56
Dan White: So sometimes you might choose to run Ignition without I/O. And we've run into a lot of cases where we've got customers that wanna run Ignition out at the edge but they maybe don't need physical I/O. Maybe they've already got some PLCs running. Maybe they just want to use it as an edge gateway. And that's where you see here our EPIC Chassis 0 system. So Ignition without I/O. And then of course traditional PLC applications where you need a lot of I/O. And we've got I/O, all types of I/O. Digital I/O, analog I/O, serial I/O. To do just about any type of control platform that you'll see out there. And this is what Garrick is gonna be demoing for you guys today. So stay tuned for that. And then why would you choose to use Opto 22 I/O?

04:44
Dan White: A big part of it is the cost of ownership. We know what it's like out there. We know that sometimes you call and get support, and the first question is, "What's your account number? Where's your credit card number?" At Opto 22, we believe in supporting our customers. If they buy our hardware, we're gonna help them make sure, we're gonna help you make sure that you can use it and that you have all the free tools available to do that. So that means free support. If you call Opto 22 right now, Elizabeth will answer the phone. She'll connect you to an engineer, somebody who's ready to help you, and you're not gonna have to pull out the wallet to do that. Free programming tools, and we'll talk a bit about more what those programming tools are. And then, of course, as I mentioned before, guaranteed lifetime I/O. Built on open standards. So, we don't want customers to come in and feel like they're locked into this architecture of, I have to use this PLC, and I have to use this HMI, and I have to use this OPC server. From the early days at Opto, we've been offering tool kits to allow you to run your programs on your own Windows applications, C++, .NET.

05:54
Dan White: Nowadays, it's Python and all kinds of other tool kits to allow you to have this open architecture and supporting of open protocols and even a lot of proprietary protocols as well. Security is a huge part of what we do. So just because we have open architectures does not mean that these products are not secure. We designed everything that you're about to see today with security in mind. Security, these products have been tested, penetration tested by government applications, by cybersecurity applications, and they pass the test. And we're gonna get into all those fun tools in a little bit. And then of course, robust and reliable. You can't guarantee anything for life if you're not making good stuff. And at Opto, we believe that our stuff's gonna last a lifetime. And that's why when it does fail, if it does fail, we stand behind it 100%. And it's designed to operate in the harshest environments, -20C° to 70C°, hazardous locations. You'll find them out on oil rigs. You'll find them just about anywhere in food and beverage, all kinds of applications. And then innovation.

07:04
Dan White: We've been, innovation has been at the core of what Opto 22 has been doing for 50 years, from an innovative method for making solid state relays, to innovative ways to allow customers back in the '80s to run programs from their IBM 16-bit computer and into a real industrial-grade I/O, to being one of the founding members of the OPC Foundation in the '90s, and of course, nowadays, the Eclipse Foundation that supports MQTT and is trying to spread that message for MQTT and all the things we can do in that space. So now, to kind of dig in a little bit more, what are all these open standards you're talking about? So everything that you see here is supported on groov EPIC. And in the age of IIoT, Digital Transformation, or whatever you want to call it, the data is more important than ever. And you might hear us talking about or using the term democratizing the data to explain this idea that we wanna make the data available to anybody who wants to use it, anybody who can use it in the business, or even outside the business. And so we're gonna collect a lot of that data at the edge. It could be machine data, it could be energy data, OEE, production data.

08:26
Dan White: The people in the business need that data, both on the OT operational side and on the IT side and the business side. And so that's why we choose to support everything you see here. And on top of open protocols, we support OPP. I don't know if you're down with OPP, but for those of you Gen Z-ers, this is an oldies band, or really an oldies rap group from the '90s. But we support other people's protocols as well, through having tools on board like Ignition and [Ignition] Edge, like CODESYS and OpenIEC programming platform, that supports things like EtherNet/IP, PROFINET, EtherCAT, all the industrial protocols that you guys see out there every day. So I like the open standards a little bit better. Talking about the architecture and the security of groov EPIC and RIO as well, open is great and open means accessible. But does open mean not secure? We're here to tell you, no. Open does not necessarily mean not secure. Open standards, open architectures, they're all good, but we don't sacrifice on the security side. And you know, most PLCs that you see out there on plant floors today are the least cyber secure device in that building. They've got open ports. They've got, anybody who comes up with a laptop could get in there and cripple your operation.

09:52
Dan White: So in today's environment, if you're gonna democratize all this data, you better do it securely, and that's why we support things like an integrated firewall on our groov EPIC, like encryption and security certificates that you can either create yourself through a self-signed CA or go to a GoDaddy-type place and create your own CAs through there. We've got an OpenVPN client on our groov, so you can securely connect through a VPN tunnel. We've got network segmentation, but what you see in the picture here and what I've been talking about if you've come by and seen us at the booth all week, is this idea of the separated, isolated networks between your OT and your IT. We've got zero trust user management. So when you plug in your groov EPIC for the first time, the first thing you're gonna have to do is create a username and password. There's no backdoor. There's no default username and password. You plug it in, you set it up. And of course, MQTT pub/sub, which allows us to securely pump data to on-premise brokers or cloud-based brokers without ever having to open up a port in our firewall and expose your important processes that are critical to operation.

11:05
Dan White: And so on top of that we've talked a little bit about before about the difference between the Opto... The Opto experience is the free support. You've got free resources on here for support, and if you're thinking to yourself, "Hey, this stuff sounds good, I'm a little bit intrigued." Well, there's lots of ways to learn about it and get more information and get help once you've got your EPIC and you're starting to play around with it and you go, "Oh, I need this or that." Hop on our website, right in opto22.com, you'll go into chat. Hop in our chat and I think a lot of times people see those chat bubbles pop up in the website and they start typing and they get some automated response. But when you go into our chats, you're gonna get guys like Garrick. You're gonna get guys like Justin back at headquarters today. You're gonna get trained engineers who know our stuff standing by, ready to answer your questions. There's other ways. If you're not into live chat and maybe you don't have a critical issue that needs to be handled in that very moment, feel free to hit us up on email.

12:09
Dan White: We've got also our direct phone line. Like I said, you can call Opto. You'll get a person on the phone. We've also got, and this is great, similar to the Ignition community, the Opto community's got a beautiful online forum that is factory manned by our engineers. It's community guided, so get in there, ask questions, share ideas. That's what it's all about, is making sure that our community is rich with ideas and sharing and keeping it going. So all our love and support for free. And if you don't need to talk to somebody, maybe you're more of a self-guided learner. We've got free training on OptoU, modular setup for all the tools on your groov EPIC. We've got our online configuration tools that'll help you to build out your system, choose your I/O modules, choose your power supplies, your software licenses, customize your system. If you're learning about IoT and how to build out an IoT architecture, we've got great tools like this IoT System Architecture Builder that'll show you everything from down at the plant floor, up to the cloud, how to do it securely, how to do it safely. Amazing videos on YouTube and on our website. Some of the most-watched videos on Node-RED. Our engineer, Terry, who you guys may see later at the Build-a-Thon, is prolific on there. And of course, you'll notice one of the top videos that pulled up was these "How to Run Ignition Edge with OPC or MQTT on Your EPIC."

13:45
Dan White: And then we've got our developer page. So for the guys that like to get down into the nitty gritty, developers that wanna program with Python or with C++ or .NET or wanna connect to our groovs using an API, it's all there. It's all shared. We like to keep it open and flexible. I talked a little bit about the robust reliability of the hardware and the lifetime guarantee. Well, back in 1974, it was that thing over there. In 2018, we launched groov EPIC. And it's all guaranteed for life, all of the solid state I/Os. So we really, we'll stand behind it. We'll make sure it works for you. And if it doesn't work for you, we will replace it right away. And then our community, we've got Opto partners, many... some of you in this room, many also Ignition partners. You can find those on our website. We've got distribution all over the country and as well all over the world. So you shouldn't have a hard time getting Opto gear all around the globe. If you don't see your logo and you're in this room and you're an Ignition and Opto partner and you don't see your logo, I have to apologize. I'm sure I missed a few, but we are proud supporters of the Ignition community.

15:07
Dan White: Many of our longtime integrators are also Ignition integrators. Some of the newer integrators have come to us from Ignition, and some of our newer Inductive integrators have come over from us. So we've got a really thriving group of people out there sharing great ideas, building out great applications, changing the world, and if you don't see your name, I apologize. In that theme of sharing ideas, we love to share success stories. We've got our case study program where we love talking to integrators and end users, finding out about their story, sharing in these applications, and I'm happy to talk to anybody who has a neat application using our gear and wants to get it out there for the rest of the world to see. Of course, we work well with others. Another great reason, you see a lot of companies up on this list that are here today.

16:02
Dan White: Your Inductive, your Cirrus Link, Snowflake. Partner communities are big in what we do. We know that there's a lot of applications out there that we can't do alone, and that Inductive can't do alone. But with this rich network and this rich ecosystem of partners, we can get it done together. And so, as promised, Garrick is ready to show off the latest and greatest. If you like what you have seen or what you're about to see, don't forget to check out Benson's presentation tomorrow. He's got some great stuff with Ignition Exchange resources, UDTs, Perspective templates, and a great energy monitoring application. So let's go. Garrick, take it away.

16:51
Garrick Reichert: Alright, we'll shift gears here and do the inverse of the grade school experience where we tell and then we're gonna show. First of all, this is a PLC out of the box. That's what it's made to do. The base functionality, the base application is a PLC and we're all at least familiar with that in this community, so we're gonna start there and we're gonna build and I'm gonna show you what this thing can do and what we can do with all the power and then introduce some new features that are coming out that I'm excited to show you that'll be out in the near future. As I said, this is a PLC. PLCs have I/O. Dan mentioned I/O, talking about digital, talking about analog. We also have what's called a mix module, which is software programmable I/O. So I'm gonna show you that where we can come in and I can configure this channel to be whatever you need to be to meet your needs there. We've got thermocouples, we've got inputs, outputs, digital, analog. So all of this is available on this one I/O unit and it's also available on the groov RIO, if you're familiar with that, as a standalone module.

17:58
Garrick Reichert: Also within this I/O structure we've got typical wiring specs and all this stuff here, so you can kind of see what it looks like if you would need to wire it up, the actual product specifications for those, and all that's available right here on the unit. So this is all on the unit. I guess I should open with that for those of you who are new. This is actually a web server running on the unit called groov Manage. And you can see up here that I am connected to that via its host name, not an IP address. We can live on those DHCP networks. We can also be secure on those DHCP networks. So IT doesn't feel that kind of ire in the back of their neck when a system like this is deployed. They know that it is trusted in their trust store. So we have all the I/O. Dan also mentioned the controller options. We do have two control options, our PAC control, flowchart-based language, and the CODESYS control. Which is a IEC 61131-3 standard tool set. If you wanna learn more about those, once again, come by the booth after this. We can talk about those.

18:55
Garrick Reichert: We offer our lightweight groov view HMI. If you wanna just do some basic stuff, Node-RED onboard, which is an open source platform that you can use to kind of move data. It's got a lot of cool nodes, including an Ignition node. If you wanted to get data from some source into Ignition, Node-RED can be that avenue that you might wanna use. So these are all tools we're gonna provide. And then you just pick and choose the ones that you want to use to suit your application. Obviously, the next one being Ignition onboard. And so we run Ignition or Ignition Edge. We prefer Ignition Edge, but we can run Ignition on this platform should you need it to run, maybe say, a small historian, where we can spin up a little database, run it local on the unit, give you that kind of local historian, and that you can manage and keep to yourself there within your system without having to go out and get in the SCADA's way and maybe involve IT in this sort of thing. We can handle that data management there.

19:49
Garrick Reichert: We'll get back into the Ignition vein at the end of this. I just wanna touch a few more things regarding, as Dan said, data democratization. We have on board as well OPC UA server capabilities, direct MQTT with Sparkplug B, transmission capabilities, if you would need that in your environment as well, as well as the networking. Full dual isolated NICs on board. And as you can see, this device is actually connected on multiple networks. I am on a static network up there on that "Ethernet 0."

20:19
Garrick Reichert: And then I'm on a DHCP network on that "Ethernet 1." And that DHCP network is actually connected to a cell modem here, which is transmitting data out via MQTT to the cloud. And we'll showcase that in a minute as well. Also, as Dan mentioned, we also have that open VPN tunnel, which is also connected. So anyone that had the credentials on their laptop anywhere in the world with an Ethernet connection could securely log into this unit and do what they needed to do, whether it be troubleshooting maintenance or anything like that.

20:47
Garrick Reichert: We have a couple other features here. One that I will touch on is port redirect. A lot of our Ignition customers can find this very useful in that it allows us to create a software bridge between those isolated NICs that allows us, if we're running that unsecured network with other PLCs that need to be secured, we can jump that bridge. You can get in, program those PLCs, remove that redirect, and then it's like they've never been there and they're completely isolated again.

21:14
Garrick Reichert: All of this can be facilitated directly on the unit or via Ignition using API calls and things like that. So you can program this in your Ignition environment to allow your techs to create these rules and maybe enable VPN, enable the port redirect, jump into their PLC of choice, program it and back out. And now you've created an audit log of that, of every time they checked one of those boxes to enable access to that, you've got that logged in there.

21:42
Garrick Reichert: The next big one is, as he mentioned, security. He mentioned the web server certs. So this device allows web server certs. As we mentioned, I showed you I am secure. It is in my trust store. You can generate the CSR, send it to your IT department. IT department will send you back a nice certificate you can load onto this device, knowing that everywhere on your network, this is a trusted device, like a web share, or maybe a database, things that you would routinely access with your PC, knowing that it is trusted, and I have access to it.

22:09
Garrick Reichert: Also, the opposite of that, we can put stuff into our trust store if we need to connect to things, MQTT listed, other things up there, data services, databases, things like that, where I wanna know that I'm connecting to a trusted version when I transmit data. So it works both ways with that. So we can do that and provide that level of IT security that many to all PLCs cannot. And then a custom built-in firewall. So this allows you to create custom rules on those different Ethernet ports, eth0, eth1, VPN. That allows you to inhibit access to certain functions. Maybe you don't want someone using CODESYS over the tunnel. We can take that and disable that over VPN. Now, someone has to be on eth0 on the static network to just program the unit.

22:56
Garrick Reichert: So we're locking it down in different ways so that you can tailor it to what works best for your application. It's not a, "You can only do X and that's the only way we can secure this." We've given you the options, we're gonna give you all the tools that you need to secure it within your infrastructure. The next one with security in mind is that accounts. Dan had mentioned creating a user account out of the box. You do have to define one local user as a local admin. But beyond that, we have access to LDAP, Active Directory Networks, directory, so that we can let IT manage the user password stuff. So now IT handles when do we update passwords. IT handles when an employee gets let go, HR sends them the email, that account is now locked out and does not have access to the system. Because in previous iterations of HMIs, you might have a guest, an admin, an engineer account, and by the end of the week, there's a sticky note with the admin password on the HMI itself. I'm speaking from experience.

23:55
Garrick Reichert: This eliminates that need, and lets it all be managed externally so that the peace of mind you guys have in IT is the same. And then we get into info and help. These are just, we can go into these details later if you guys want to learn more. We have a full RESTful API suit on board that you could leverage if you wanted to make RESTful API calls to get any bit of data out of this system, I/O data, configuration data, things like that. It's all available to you within the system. But I wanna get in and kind of focus on Ignition here at the end of this before we jump to a Q&A section. And I know you guys probably can't see on the front display too well, it's pretty small, but if you wanna come take a look at it after this, you can see this. This device is actually running a beta version of our upcoming 4.0 EPIC firmware that now allows or will allow you to run a Perspective client on the front touch to screen here.

24:47
Garrick Reichert: So now you can actually leverage all this power. All of these things are templates that have UDTs behind them and Ignition that now I can just deploy on my Edge gateway, run it here directly without having to worry about, "Do I create a custom interface here? Is it managed where? Where's the tags?" We're building it all in that system. So you can kind of tell this is Opto 22's Ignition Cloud Edition that we are running has all of our demos on it, as you can see on the left. And I am currently focused on this demo here, connected over MQTT. And we can go ahead and start a process on it. So there's got a car wash simulated. And you'll note if you're close enough, you'll be able to see the color change on these because these are the same built templates here. So we can walk through it as it starts. You'll see the things start changing color between here and there. Since we're leveraging the same templates, there's not a disconnect if I use a third-party HMI or anything like that. It's all built into one platform: Ignition.

25:44
Garrick Reichert: And so that's how we leverage that, we can use this to bring a lot of resources in and pretty powerfully deploy these systems now and in the future. 4.0, we're really excited about it. There's one other thing I wanna mention, there's a lot of other stuff that might interest this crowd and this audience specifically before we spend a couple of minutes on Q&A for any of those that you might have, is we're also going to be introducing in a kind of power user capacity, the ability to do containerization on these units. So, kind of one of those things that some of our customers, particularly this type of audience, might be very interested to know and be able to utilize and grow and flex some of the power that can be involved in this unit.

26:26
Garrick Reichert: And yeah, any of you could go to ice.groov.com right now and you could go to this unit and you could start seeing the data that's flowing from there. So, that's what we like to see. We wanted the power to the people, data democratization. And with that, we'll open it up to questions for Dan and I. And if you guys got anything, we got a couple of minutes.

26:43
Audience Member 1: That initial password that you're talking about. So you buy a new device, you put in the first username and password. But then you said the other username and passwords can be handled by LDAP or whatever. But that initial username and password still on there. So the employee gets removed, but they may still know that password.

27:04
Garrick Reichert: That would typically be set up by the initial engineer. So there is a little bit, you could change that password. It's always passwords...

27:09
Audience Member 1: Well, that was my question. Can it be changed through the REST API?

27:13
Garrick Reichert: Passwords, can passwords be set?

27:15
Audience Member 1: Is that a dumb question?

27:16
Garrick Reichert: I don't believe passwords can be changed. No, it's not a dumb question. That's a good question. 'Cause we have a public-facing API, and so there's a lot of inter-working. I don't believe passwords...

27:24
Audience Member 1: That way, if you did have an employee leave, you could use the REST API... Your fleet of devices could get all changed at the same time.

27:32
Garrick Reichert: Yes.

27:32
Audience Member 1: Okay. Just a thought.

27:33
Garrick Reichert: No, no. Thank you for that. Maybe I have to disable the buzzer here before too long.

27:40
Dan White: We answered everyone's questions? Oh, there's one.

27:46
Audience Member 2: Are there any plans for other VPNs besides OpenVPN like WireGuard or Tailscale?

27:51
Garrick Reichert: Yes, there are. We've actually done because, as I mentioned, with containerization and things like that, you would be able to load whatever software you might need and you can test that out, see if it works. We have had customers use other VPN software on board in the past. So that's definitely gonna be an option.

28:11
Audience Member 3: A quick question, you can connect HDMI to that to have a larger screen?

28:18
Garrick Reichert: Yes.

28:19
Audience Member 3: How many can you connect, just one?

28:22
Garrick Reichert: Just one HDMI port with dual USB, so you could extend this display to a larger monitor, touch screen, keyboard, mouse, if you wanted to put it in like, you know, a control room type environment where you would wanna have that. But yeah, that is also an option and available.

28:37
Audience Member 4: It came with Node-RED installed on it. Can that control the I/O as well or is it?

28:42
Garrick Reichert: Yes. Yeah. Okay...

28:44
Dan White: We've got seven nodes that are in there that you can use to control I/O, read and write I/O, scan I/O, read and write from our UI, or read and write from our PAC control programming software. Or if you're using CODESYS, you could use OPC nodes to read and write. So yeah, Node-RED is fully compatible communicating with I/O with variables, process variables as well.

29:08
Audience Member 5: Can the user management for groov manage the LDAP? Can that be used in CODESYS as well?

29:16
Garrick Reichert: No, it cannot right now. CODESYS has its own user management groups if you need to configure and set those up. You'd have to do it within that environment 'cause that's all the IDE side compiled from external.

29:25
Audience Member 5: Thank you.

29:27 
Audience Member 6: In the new version, is PAC Control able to do online editing now?

29:34
Garrick Reichert: PAC Control will function the same as it has always functioned. But good question.

29:40
Dan White: For those of you who aren't familiar with PAC Control, it's our legacy programming environment that's been with us since the '80s. And so a bit limited in terms of that.

29:48
Garrick Reichert: Yeah.

29:53
Audience Member 7: I was curious about the CODESYS runtime versus Ignition and what kind of controls are there to keep one from hosing the other, I guess, and making sure that your PLC functions are...

30:05
Garrick Reichert: Yeah, the PLC is a separate runtime engine that grabs a real-time thread and is totally dedicated to the PLC operations. Ignition is gonna... It's just like if you were in the field with a standard PLC and an Ignition at a PC. It's gonna function exactly like that.

30:19
Audience Member 7: Thank you.

30:22
Audience Member 8: Forgive me, I'm not familiar with you guys' product at all, it's first time I've had experience with it. So does it have to operate as an edge gateway and remote to Ignition or can it operate as a standalone PLC over Modbus TCP as well and interface with everything that...

30:37
Dan White: Yes, that's the latter. It does not have to run Ignition. It comes with Ignition pre-installed as a convenience and your choice whether or not you license it. In some cases you want that Edge gateway because you want that redundancy at the edge and that store-and-forward capabilities and things like that. But in other cases you may have a robust network and maybe you just want to publish MQTT data or expose OPC data to Ignition or to the software platform of your choice and that's also totally well and good. We put all the tools there, but you don't have to use them all.

31:07
Audience Member 8: And it can do both simultaneously, right?

31:08
Dan White: Yes, absolutely.

31:08
Garrick Reichert: Yes. Yeah, remember I started. This is a PLC.

31:13
Audience Member 8: Thank you guys.

31:13
Garrick Reichert: First and foremost.

31:14
Dan White: I'm glad you said that too, 'cause I think sometimes we talk all about this stuff and then people forget it. You know, many of our applications are traditional PLC control applications.

31:24
Moderator: Last one.

31:27
Audience Member 9: With the remote I/O is it possible to use that to transmit I/O from one of those modules to say another one at another end. Analog input on one side, analog output to the other remote I/O?

31:38
Dan White: Sure, I think.

31:39
Garrick Reichert: Yeah, I mean of course, like standard PLC functions we can wrap it past anything we need to in the system.

31:44
Dan White: You wanna put an output signal out of one and then wire it to an input of another?

31:46
Garrick Reichert: And put, wire it to another? Or even through programmatically?

31:50
Dan White: A lot of our learning centers even do that. I know that sometimes we've got inputs wired back to outputs just to show the dual functionality. Yeah, you can do that.

32:00
Moderator: We're at time.

32:00
Garrick Reichert: Alright. Thank you guys for attending.

32:02
Dan White: Thanks guys. Stop by the booth if you have any other questions.

Whether you're new to Ignition or just want a refresher, this session is made for all. The Inductive Automation Training team covers all the basic knowledge and fundamental features you need to get started with Ignition.

Transcript:

00:01
Jayson Thorpe: Hello everyone, welcome to Learning Ignition Fundamentals. We're about to get started here. How about that keynote, huh? I wanna thank you all for joining us for this session.

00:13
Aryanna Brown: My name is Aryanna, I am a Tier Two Software Support Engineer Team Lead here at Inductive Automation. I've been working here for about three years, and if you have ever sought support with our software, you've most likely spoken to me or my team.

00:27
Jayson Thorpe: My name is Jayson, also called JT. I'm a technical trainer, I'm on the training team at Inductive Automation. I started out in support, but I'm in the training department now. If you've taken any of the core classes or any of the other training courses we offered at Inductive Automation, you may have met me before. And today, we are talking about Learning Ignition Fundamentals. So we're gonna be going over some pretty preliminary information on Ignition, what is it, how do you use it? Why do you use it? Pretty much those big three main questions. Summarize, Ignition is a platform, it's an application development platform for you to build, design your own industrial automation applications for SCADA, HMI, MES and more. Some of the cool things about it, it's cross-platform written in Java, so it's operating system agnostic, web-based deployment and modular design. We're gonna talk about that modular design here in a moment, and the web-based deployment as we go through our demonstration today.

01:28
Jayson Thorpe: Since its inception, Ignition has evolved quite a bit. We have four different editions of Ignition to choose from. We have our Standard Edition for most use cases, we have Ignition Edge, for edge of network devices, usually gathering data, forwarding it to a more centralized gateway. We have our Ignition Cloud Edition, if you need to leverage hosting your gateway in the Cloud, this is available through web-based marketplaces like Amazon Web Services, and then we have my favorite Ignition maker edition for your home automation personal non-commercial projects. Ignition's modular design, what does that mean? Modular design essentially means that all of the major functionality you may want out of your gateway comes with a respective module, this means that you can easily customize your installation, things like the two different visualization modules we have, Perspective Vision are each their own module. Things like tag history, SQL Bridge, what this means is that you can really customize. Oh, oh. Oh, well, that's our last slide for now, anyway.

02:39
Jayson Thorpe: What this means is you can really customize your gateway or your entire network of gateways depending on what you need different gateways to do. You're not paying for things that you don't need a certain gateway to do, only for the things that you do need. So for this demonstration, we're gonna be going and installing Ignition, getting started with it, we're gonna start designing pretty quickly here. But what we wanna show you is that anybody can go to inductiveautomation.com, download Ignition, install it, and get started designing in about five minutes. Here we are in Inductive Automation's website, and anywhere at the top right, you can go and download Ignition for your respective operating system. We however, today have the downloader or the installer already downloaded, so we're just gonna run it. And we're gonna go through a basic install, which means we're gonna go with all of the core modules here.

03:36
Jayson Thorpe: Now, I said that we can download Ignition and get started in about five minutes, which in the SCADA space is a very quick amount of time to download our application. Once we download the appli... Once we install Ignition, here we are just making a couple of decisions as we go, we are gonna go with just the typical default installation to include all of the core modules. One of the things we also decided was the service name and the port that Ignition is going to use. And here we are, the gateway is already starting up, and once the gateway is installed, we pick which edition we wanna run. And what we're about to see here in the web browser, right now, we're using Google Chrome, let's create our user and password. But what we have here, in a few minutes, we've installed Ignition and we're running our gateway. Here in the web browser we're looking at the Gateway web page, which is the interface to your Ignition installation. Since Ignition is cross-platform, written in Java, you can load this on to a Linux box or of course, Mac or Windows, have your gateway running in a server box in a closet somewhere, and anybody that's able to reach that gateway over your network, will be able to interface with the gateway web page that we're gonna see here.

05:02
Jayson Thorpe: Gateway started. We're gonna start from scratch, we're actually gonna end up loading up a gateway back up here in a moment. What we see here is the Gateway webpage. Anybody who, you may notice, a local host is what we're accessing. Otherwise, this would be the IP of the gateway. Anybody on our network that can hit the gateway host can access the gateway web page. And here on the home page where we start out is where we can download some of these software peripherals to run a designer and also our Vision and Perspective run times. Next stop on our... Oh, still on the home page, we have links to the user manual, links to our community and as the exchange of our forums, different ways to get started with Ignition and to learn more about it as you go. Thank you. Now we're gonna go to status page, where we do have to log in, and the status pages is where you can get a bird's eye view of your entire Ignition sub-system. We can see the status of how many connections we have, like database connections, our device connections, how many tags we have, and even performance metrics.

06:15
Jayson Thorpe: On the config tab, the last stop of our tour here, is where you go to change any of those settings that we're looking at over in status, if we need to add a new gateway connect or add a connection, like a gate network connection, your database connection, OPC device, all of that would be configured here. Now, you may notice that green banner at the very top. One of the things I mentioned earlier is Ignition's flexible licensing. That trial mode, timer counting down from two hours is built into the Ignition platform. Anybody can download Ignition and run their gateway on this two-hour trial license where all of the core modules are fully functioning and we can build our reports, build our notification pipelines, build all of our displays and our HMIs all on this trial license. And when that two-hour timer goes up, we just go back to the gateway and reset it. Now, what we're doing right now, Aryanna is about to restore a gateway back up, which is in our downloads folder. And we're doing this to basically set up a few preliminary environmental points for our project.

07:25
Jayson Thorpe: And while this is going, let's also install the designer launcher. Now, the reason we're uploading a gateway back up is like I said, we have some project resources already built, some data points in the form of tags. And as this designer launcher is installing, me and Aryanna are gonna switch places, hot potato, and she's gonna take you through the designer once it's fully installed.

07:55
Aryanna Brown: Thank you, JT. Once we have our gateway up and running, we'll take a quick little tour and I'll show you what we've got going on in this back up.

08:11
Jayson Thorpe: Now, one thing to know is during or right now, we're not pointing to any gateways, but right now we have our launcher local to our Gateway, but Aryanna is gonna go into what are the different options for anyone on your network that may need to use the designer.

08:31
Aryanna Brown: So now that we have restored our gateway back up, let's take a look at what's in it. If we head over to the status page, like JT just showed you, log in, we're gonna see that we have some tags. Some of these I've created, we have two device connections, two programmable device simulators, so that when we show our demonstration, we can get started right away with real live unique values. And then, we have a database connection, and that database connection is for us to show trends. And as you see here, the throughput is about 0.8 queries per second, so this will show you the status of your database connection, and right now, it's healthy. I also have a partially built project in this back up that we'll go ahead and take a look at closer in the designer. First, we're gonna wanna launch our designer launcher. Now that we have this open, we're gonna go ahead and add our designer. Now, notice we have two tabs, one is on your network and the other is manual. Manual will allow you to input your Gateway URL manually should it not appear under the on your network tab. The on your network tab is gonna show you all of the Gateways it recognizes on your current network.

09:52
Aryanna Brown: Right now, it's only ours, so we're gonna go ahead and select our Gateway. Once we've selected our Gateway, we're gonna go ahead and open our designer for this Gateway, which should list all of the projects that we have configured for this Gateway. Once we get this open, we'll take a quick tour of the designer, and then we'll get started in showing you a Vision client runtime application.

10:23
Jayson Thorpe: Now Aryanna, how many designer sessions can we be running concurrently from the same Gateway?

10:27
Aryanna Brown: You can run as many as you'd like. As long as you can connect to it through your network, both I and JT can be working on the same project at the same time, if we'd like.

10:38
Jayson Thorpe: All right, I'm just gonna sign in here.

10:45
Aryanna Brown: Perfect. Now, we only have one project on this gateway, but you can create projects for each device, each substation, whichever you prefer. Now that we have our designer open, it is so pretty. Look at it. The possibilities are endless. If we head to the top left-hand corner, you'll notice our project browser, this is gonna list our various modules that can be configurable within the designer, such as our reporting module, which will auto-generate PDF reports to email, saving a directory, even print. We also have our visualization modules, Vision Perspective, scripting, any module that is configurable in the designer. Under that, you'll see we have our tag browser. In our tag browser, we have two tabs, one is tags, the other is UDT definitions with a drop down above it, to select our tag provider. UDT definitions provide a single structure of tags that map to unique data points in your server or device. If you notice we have one for compressor and one for sensor.

11:57
Aryanna Brown: Now, earlier, I mentioned our programmable device simulators, those are coming from a dairy. So these sensor UDTs are representing a refrigerator, humidity and temperature. If we head over to the tags tab, you'll see that we have real-time instances of these definitions. So we have one for each of our compressors and each of our sensors. Now that we've taken a quick little tour, I'm gonna go ahead and launch a Vision client runtime application to show you guys what operators or end users would typically see. While that's loading, I'm just gonna go ahead and show you guys. I've created a template here, notice that it says sensor three, I've only created one of these, this is a resource that we can use to dynamically create multiple instances for a given device or data type. We're gonna go ahead and log in just as operators or end users would. And this is our overview page. Notice that we have those sensor, three of our sensor templates in our overview page.

13:18
Aryanna Brown: Now, I did not create three different sensor templates, I created one and then parameterized them so that I can put in sensor one, sensor two, sensor three to give me those unique real-time values for each of those sensors. With this functionality, that means we can also read and write to and from these UDTs, and we can switch back and forth and see the unique values that these UDTs give us. Now we're gonna head over to our alarms page and let you check out some alarms. Oh, oh. We don't see any alarms. That's okay, let's head back to our designer and we're gonna configure an alarm on our UDT definition so that it takes on every single real-time instance. Now that we're in our UDT definition, we're gonna head to our sensor UDT, down to our humidity tag. Once we're in our humidity tag, we're gonna go down to alarms and add a brand new alarm, we're gonna give it a fun name, like humidity high alarm. Once we've given it a fun name, we're gonna modify the display path. Now, the display path is how it will be displayed in an alarm status table, an alarm journal table, it's exactly as described, how you would like it to display for that instance of the alarm.

14:50
Aryanna Brown: We're going to be using Ignition's expression language to dynamically create these display paths so that they are unique to each of their instances and alarms. Once we hit apply, we're gonna go down and let it know when we'd like the alarm to go active. Given that this is humidity, let's go ahead and make it 95. Once we hit Apply and Okay, you'll notice that we get alarms for each of our sensors. Look under the display path, we have this sensor one, sensor two and sensor three, I only had to configure that once and it dynamically created my display paths. Now, if you head back to the designer, you'll notice under our tags tab, each of our real-time instances for these sensors have the alarming icon showing that there is an alarm configured for each of these tags. Now we're gonna head back to our runtime application and take a look at some tag history. Oh, no. Same issue. That's okay. Just the way we modified a global resource to show you how we can get alarms, we're gonna now modify a project resource to get our tag history displayed.

16:16
Aryanna Brown: We're gonna head over to our history window, and if you notice on the left-hand side in that tag browser, there's this little clock looking icon, that means that history has been configured on these tags and they are currently storing tag history. So we're gonna go ahead and just drag and drop both of them on to our easy chart component, and now we have some values. Now, it is not... Oh, let's go ahead and take a look at it in the client. That was very quick. Easily deployable. Now it's not expected that operators be able to drag and drop. If you look here, if we get rid of this, they can no longer add them back, so we're gonna head to the designer and add a component so that operators can have the same functionality in their project client runtime that we have in our designer.

17:11
Aryanna Brown: We have a tag browse tree component that we're going to be using, and it is exactly as described. It's gonna allow us to browse our tags within our runtime application, so we do not need access to our designer tag browser. We're gonna make it pretty and formatted. And then, once we've done that, we're gonna modify the Tag Tree mode. Now, this is important because the Tag Tree mode will just differentiate between real-time tag paths and historical tag paths. Historical tag paths are tag paths that have been historized for tags that are currently storing history or have stored history. Now that we've changed that to Historical tag paths, operators can only select tags that have history. So we're gonna go ahead and hit save and watch this automatically deploy to our client. And if we get rid of our tag pens, our operators can easily drag and drop tag history onto their chart. Now, that I've gone through Vision and a client runtime application and showing you how to visualize that, JT is going to show you how to build a similar application in our Perspective module.

18:31
Jayson Thorpe: Thank you, Aryanna. So quickly, we've seen how we can manage our tags or manage the tags that are giving us the data from our devices using UDTs, make a change in one place. We see that change populate out to all of our instances. The UDTs that are giving us the real-time tag values are actually pointed to our PLCs. We made an update to one of the interfaces of our Vision client as well, and we deployed that instantaneously. And now, we're gonna go and do something similar in our other visualization module Perspective. For that, we just got word that our organization has bought some new motors. We bought some new hardware. It's installed. We have those connected through our OPC server. We're getting values from our motors in the form of tags through our OPC server. What we're gonna do here is go and design a UDT to match the motor structure in our OPC server. So we're gonna make a new data type.

19:29
Aryanna Brown: Oops, gotta go to that tab.

19:31
Jayson Thorpe: Ah, there we go.

19:33
Jayson Thorpe: In the UDT definitions tab, we're gonna create a new UDT. We're gonna call this motor and we do need to give it a parameter so that we can take the addresses for the PLCs or registers for each individual data point, tell it which motor we want to view, and we are able to redirect our OPC item paths across our server. What you see Aryanna doing here now is browsing our OPC server looking directly onto our devices for the different data points. You'll see we have at least eight different motors. All of these have an identical structure of the same two tags. This is why we're building a UDT, so that we don't have to build a new set of tags for each individual motor. We're just gonna add two of those into our UDT and then using our parameter for the motor number and Ignition's expression language, we're gonna plug in the parameter in place of that motor number to create a dynamic OPC address. Excellent. Now, we have our UDT defined. We have the two data points for every motor we're gonna want to view. And now we need to create our real-time instances, which we can do quickly with one of my favorite names in Ignition, the Instance Creation Wizard. We just have to tell it which UDT we would like to create instances of, give it a base name and pattern for the name and the parameters. When through, check that name tag name pattern.

21:13
Aryanna Brown: Oh, thank you.

21:13
Jayson Thorpe: Whew.

21:16
Jayson Thorpe: Very nice. Now, as soon as we hit Okay, we're gonna see eight instances of our motors. And using that parameter, each one is actually giving us a different value from our devices. Awesome. Now, we have the data actually coming into our system. In order to display this data, we wanna go to Perspective and start building some displays and interfaces. We're gonna build a view to not only show us information for each one of our motors, but also to be able to change the state of that motor to be able to turn it on off. So we're making a new view called motor view. We are gonna use a flex container, which in Perspective, one of the main considerations is the different sizes of screens that your sessions will be run on. What devices are your operators gonna be using? Perspective is chockfull of different layout options to be able to gracefully display your session on different device, specifically different screen sizes. And the flex container handles scaling of the components pretty nicely.

22:24
Jayson Thorpe: Now, so that we know which motor we are viewing, we're gonna add a label component here. And once again, using Ignition's expression language, which very easily can let you take different values from across your system to generate a single value, that's really where the expression language strength lies. In this case that one value we want to generate is just a string of text.

22:50
Aryanna Brown: We forgot to create a parameter.

22:52
Jayson Thorpe: Yes, we did. In order for this label to dynamically display, we do need a parameter just like our UDT definitions. There we go. Very nice. And after this label, we're gonna go and... Well, let's finish configuring this label here first. Now, since we've added the parameter, we can easily go and browse any of the properties across this view of all the components. Right now, the one we want is that motor number parameter. Just so this view is a little bit more interesting to look at, we're gonna go into the symbol factory, which is a library of scaled vector graphic images built into Ignition for us to use in our projects here. We have a simple motor four that looks pretty nice, but now we need to get the components to not only see the value of some of our motor tags, but also to be able to control the state of them. We have an HOA tag that we're gonna use to turn our motors on and off. So we're gonna grab a multi-state button for that, which lets us view and send out a read or... Sorry, a write to a tag.

24:02
Jayson Thorpe: So we're gonna go and use that parameter to once again set up an indirect binding, this time directly to any of our motor tags. Once we switch out the motor number with our dynamic parameter and make this binding bidirectional so that we can not only get that value and see it, but also send a signal back to the tag from this component. We need the same binding on this other property to indicate a value. So we're just copying the binding, pasting that real quick. And let's go into preview mode in the designer and turn on read and write mode. And let's see that motor one HOA tag change value now. Excellent. And all we have to do is change the value of that parameter to point to a different motor, but I think we've proven the point. Now let's get an LED display to actually see how much current's running through our amp or through our motors. And then, we're gonna go and quickly get this displayed over into our session. For this LED display component, we just have to once again bind to any of our tags using our parameter, we can dynamically redirect our view instances.

25:23
Jayson Thorpe: All right. Now, we have all of the information for our motors displayed. We're gonna go and create one more view, and we're gonna load that up with a few different displays to show to our users depending on the size of the screen they're viewing our session on. We're using a Breakpoint Container here. Remember I said Perspective's all about displaying your session on different screen sizes. The Breakpoint Container has two Subcon Containers. One will display when we're beneath a certain width, width being the container or the size of the screen being displayed on. And for the small view for when our operators are on their mobile devices, we're gonna use a carousel component for this. Carousel component, we've all seen it's equivalent on various webpages. Something that just takes an image or a set of cards can swipe them horizontally.

26:23
Jayson Thorpe: We're gonna load up this carousel component with different instances of our motor view. You can see here Aryanna is just telling our carousel, which view we want to embed, setting a unique value for that parameter. And just like that, we have four instances of four of our motor devices coming in through our OPC server. And now, we have to build out the large view. What are the users gonna see when they're on a, when they're viewing our session on a monitor or a wide screen. For that, we have a tab container. Tab container also has multiple sub-containers that can display on demand. For this tab container, we're just gonna deep select this container here, and we have two views in the learning Ignition fundamentals folder that we pre-built for this demonstration. And we're just taking those views and embedding them directly into this tab container. And then here, Aryanna is just adding more views. She's gonna name those tabs something useful. And then, we're gonna go and get this view right into our session as a webpage.

27:50
Jayson Thorpe: All right. So, I don't know if anybody's been timing me, but how long has it taken us since we started building our UDT? 10 minutes? Maybe maybe about 13. We're about to take all of that work and get it all in front of the people that need to see it. All of our operators running our session. So, let's see. Oh, view can't do...

28:08
Aryanna Brown: The tab containers.

28:08
Jayson Thorpe: That itself?

28:09
Aryanna Brown: Yeah. I'm not sure, it's embedded.

28:14
Jayson Thorpe: Delete that?

28:15
Aryanna Brown: Yeah. Okay. Here. And drag and drop.

28:22
Jayson Thorpe: There we go.

28:35
Aryanna Brown: Well, we may need to only have alarms stick.

28:38
Jayson Thorpe: Yeah, but deep select it.

28:39
Aryanna Brown: I do.

28:40
Jayson Thorpe: Let's try one more time. Interesting.

28:45
Aryanna Brown: I think it's the view itself.

28:47
Jayson Thorpe: Yeah. Oh, I see.

28:48
Aryanna Brown: Yeah.

28:49
Jayson Thorpe: It did drop it inside itself. Okay, cool. So delete it from there.

28:52
Aryanna Brown: Oh, there it is.

28:55
Jayson Thorpe: There we go.

28:55
Aryanna Brown: There we go. There we go.

28:57
Jayson Thorpe: Now when we go to the Tab Container, perfect. There we go.

29:00
Aryanna Brown: Okay.

29:02
Jayson Thorpe: All right. Slight setback happens to the best of us. Now, let's go to our page configuration. We have all these different views, all of the different displays built, but not all of these are gonna appear in our session. This is where we manage which pages are accessible in our session, which pages are exposed via URL in our session, and what pages are navigable too. Here we're just taking our homepage, that forward slash root URL, pointing it to the overview view that we just built. As soon as we save our project and launch our session we'll see the fruits of our labor here. Here we see the large screen version where we can switch back and forth between alarms and history. And we're gonna use the developer tools in Chrome just to simulate a smaller screen here where we not only see the small view that we built with all of our motors, but can you go make that a little bit smaller again and show off that flex container doing its work.

30:03
Jayson Thorpe: Notice how when we're narrower, the Flex Container is scaling up and down for us. These are just a couple of options in Perspective to handle graceful layout scaling for different types of devices. And that does end our demonstration for today. We're about to take questions here, but we didn't even get a chance to look at, take a deep dive into that is of the reporting module, alarm notifications, things that not only get realtime data in front of people that need to see it, but also that historical data, things like reports, calculations, MES downtimes, but also getting that historical and aggregated data in front of those who need to see it as well. Thank you.

30:51
Aryanna Brown: That concludes our session. Thank you for coming.

31:01
Jayson Thorpe: And now we do have a microphone walking around the room if there are any questions. We have 15 minutes for questions, everyone. Yes. Right down here.

31:09
Audience Member 1: What's the difference between Vision...

31:10
Jayson Thorpe: Sorry. We will ask you to wait for the microphone because we are streaming or this will be... It's either being viewed live. It is.

31:19
Audience Member 1: What's the difference between Vision and Perspective?

31:22
Jayson Thorpe: Biggest difference is one, the Vision client's gonna run as a Java client in kind of the more client-host relationship. The biggest difference with Perspective is different screen sizes. You run Perspective session in a web browser, any device that can get online, access a web browser can run a Perspective session. This is not the case with Vision.

31:45
Aryanna Brown: They also run separately. Perspective runs on the gateway whereas Vision clients will run on the machine that they're launched from.

31:53
Jayson Thorpe: True. Any other questions? I know everyone's all hyped on 8.3...

32:00
Aryanna Brown: I know.

32:02
Jayson Thorpe: From that keynote. Yeah. In the back in the middle.

32:09
Audience Member 2: I saw on the 8.3 feature keynote, Rockwell and Siemens S7 I/O drivers. What are the other standard drivers that are included?

32:24
Jayson Thorpe: Let's go. Well, you know what? You can come talk to us after. I mean, we could show you on the Gateway right now. Actually, let's do that. Let's show you. Well, one of the things is different, the drivers that come standard on the gateway are for Siemens, Allen-Bradley, even Legacy versions of both of those different ones here we can see the drivers that just come standard on fresh out of the box install, but different vendors make different drivers as well. So there are very few devices that you're not able to connect to directly. But even if you can't, the fact that Ignition acts as an OPC server means that whatever OPC server you do have connected to those devices, Ignition's gonna still connect to that.

33:06
Audience Member 2: Very good. Thank you.

33:10
Audience Member 3: JT, I don't see a module for MQTT.

33:15
Jayson Thorpe: MQTT is a separate module. That one is available as a few different modules. We have the...

33:22
Aryanna Brown: Engine distributor and the broker. We also have the transmission. So if you are looking for those modules, you're definitely gonna have to go to a Cirrus Link. And they're technically a third party module, but we work very closely with them. So they won't be available to you on the actual Inductive Automation website, but we will help you support it.

33:44
Jayson Thorpe: Yeah.

33:46
Audience Member 4: How many active or consecutive sessions can you have? Is there a difference between Vision and Perspective? What's the payload? How heavy is it against the Gateway?

34:00
Aryanna Brown: So Vision, like I said earlier, that they're gonna be ran on the machines that they're launched from. So truthfully, if you have kind of a heavier project that's gonna be more intense, you have to make sure each machine that is launching that application for Vision can handle that. In Perspective though, it's in a web browser, so since it runs on the Gateway, if there are performance type issues, it's dependent on your gateway and the specs of the machine that your gateway is hosted on and what you gave your gateway. So truthfully, it's kind of endless. You can give it as many resources as you want, as long as your machine can handle it, go crazy.

34:40
Jayson Thorpe: The key is that the license, the Ignition license is never gonna limit you on how many databases you can connect to how many devices or OPC servers or how many concurrent runtimes of Vision or Perspective or designers. You can have as many going of all of those as you want in any combination. The license is never gonna restrict that for you. Yes, thank you.

35:02
Audience Member 5: If you're new to Ignition, where would you suggest you start to get in to get a good introduction and learn about the system?

35:09
Aryanna Brown: This is a great question.

35:11
Jayson Thorpe: We have... Well, sorry, you say I'll show.

35:14
Aryanna Brown: I'm glad you were going to it right away because I'm sure we were thinking the same thing. Inductive University, it is a great, great tool. New hires use it with us just to get them started. So I highly, highly recommend it to get you guys started as well.

35:33
Jayson Thorpe: So yeah, you can download it really quickly and get started with it really quickly and using this free library of video tutorials, you don't even have to log in to watch all of these, but if you log in, you can take challenges and build towards a credential here in the Inductive University. But essentially, this is almost a whole course on getting started with Ignition and being able to do some really cool stuff with it without even having to open the user manual or even attending a class. And all of this is for free, Inductive University. Yes. Down. Yeah. I see you.

36:02
Audience Member 6: Yeah. So you showed a toolbox earlier with like check boxes and then the carousel.

36:08
Jayson Thorpe: Oh. Yeah.

36:09
Audience Member 6: Can advanced users make their own, like software developers? Can they make their own controls and visualizations?

36:16
Aryanna Brown: Oh, like components?

36:17
Audience Member 6: Yes.

36:19
Aryanna Brown: I don't believe so.

36:22
Jayson Thorpe: And I've seen some pretty interesting things done with Java Swing, but that's like as a Java developer.

36:28
Aryanna Brown: I would think if you created your own module at that point you could do whatever with it. But I don't believe you can create your own components. We do allow, if you search through our forums and our community third party resources to allow to get in there and kind of modify what you can but not necessarily create components from scratch.

36:50
Jayson Thorpe: Those people that, some folks that do have that skillset to develop modules, if a lot of folks share those modules with each other on the Ignition Exchange, there's a lot of free user made resources here. And a lot of stuff that we've put out actually via Inductive Automation has put some stuff really cool modules on here. Anything from modules to project resources, a lot of that is done by other folks and the community is really great about sharing and caring.

37:21
Audience Member 6: Okay. Thank you.

37:22
Jayson Thorpe: Yeah, absolutely. And then, oh, over there and then this gentleman right here.

37:26
Audience Member 7: On the Inductive University, is there a way to monitor the process of people that you have assigned to go there to learn?

37:36
Jayson Thorpe: I think you can track this on your user portal through your organization portal. Yes. Cool. So that is trackable on your organization's portal.

37:47
Audience Member 8: I think users almost do.

37:48
Jayson Thorpe: Oh, okay. Cool. Thank you.

37:51
Audience Member 9: So, speaking of the Exchange, the project you guys just showed, is that on the Exchange for download, or we're gonna check out later?

37:58
Aryanna Brown: It is not.

38:00
Jayson Thorpe: No, but that's not a bad idea actually. Maybe we'll have to see if...

38:02
Audience Member 9: Maybe kind of study it, kind of get better understanding.

38:04
Jayson Thorpe: Yeah. That's not a bad idea. One thing you can do though, let's see, if we go and start a new project, if we went to go and create a new project right now, there are template projects included in the Gateway as well. So, you can just, for example, like Vision tab Nav, that's gonna create a project with some tab navigation already built in Vision, Perspective has similar ones. So you can actually just write a white out of the box installation, get some prebuilt resources to start playing around with some kind of like what we did here.

38:36
Audience Member 9: Brilliant. All right. Thank you.

38:38
Jayson Thorpe: You're very welcome. Oh, down here. Thank you.

38:46
Audience Member 10: So when you were showing the changing parameters and how easy that was, on a qualified system for like life sciences, is all of that audit trail, is everything on your audit trail that you make changes to just to ensure that once you're on a qualified system, anything that changes, you can go back and...

39:05
Aryanna Brown: Yes. So, we have an audit log. Now, not everything is logged in that audit log as of right now. But if you head to our manual page, it will list everything that is and you will at least be able to see who went into the project and how they changed it. If they changed the project, it will say like, project modification and who it was, it may not necessarily tell you exactly what it is they did. But anything that's more gateway scoped, it will tell you. So, if they wrote to a tag, if they modified a tag, if they actually modified the tag, it'll tell you that. Things that are more project resource-based, it doesn't, it's kind of hit or miss on what it will actually log right now.

39:46
Jayson Thorpe: The designer doesn't really track exact changes to like, in every individual component, but you will be able to see who logged in, who did save any changes. And even with scripting built in throughout and some extension functions or sorry, system functions people set up their own logging pretty effortlessly through the scripting that's already built into Ignition as as well.

40:06
Aryanna Brown: There's a scripting function to write to our audit log.

40:10
Jayson Thorpe: Exactly. So anything that that audit log doesn't cover, you can probably cook something up as well to make sure it does. Back there in the back.

40:19
Audience Member 11: Yeah. Is there a cross reference browser for your graphics and tags and everything?

40:22
Jayson Thorpe: A cross reference browser? I'm not sure what you mean by that.

40:26
Audience Member 11: Finding out where your templates are used.

40:29
Aryanna Brown: Oh, so like a find and replace type? Yeah, we do. We have a find and replace tool within the designer. And you can put in like a keyword of what you're looking for and it'll pop up and list everything that, whether it's a property binding, a component of you, a window name.

40:45
Jayson Thorpe: Script.

40:46
Aryanna Brown: Script as long as you kind of know a keyword, it'll try to find it within your project. So yes.

40:54
Jayson Thorpe: And that's one of those things that every couple versions there is something new to make managing the various moving pieces of your projects a lot easier. That's not necessarily new, but every couple versions there's something that lets you find things in your projects a little easier.

41:12
Aryanna Brown: Yes.

41:16
Audience Member 12: So with 8.3 coming out pretty soon beta, will there be videos posted on university that kind of goes over the new features to kind of get a start on learning that stuff? Like the drawing tools for instance?

41:27
Jayson Thorpe: Not right when it's released, but we absolutely are going to start you know, coming from the training department, we wanna be able to teach people. People are gonna wanna know how to use it. We want to teach people how to use it. We absolutely are gonna be building resources to learn Ignition 8.3 as soon as we can.

41:43
Aryanna Brown: It may not be immediately available, but.

41:44
Audience Member 12: Okay. That's fine. Will the docs be a good place to start to kind of see that stuff kind of comes...

41:49
Jayson Thorpe: Absolutely.

41:49
Audience Member 12: Through later on to just get that information as soon as possible?

41:52
Aryanna Brown: Absolutely. Yes.

41:52
Audience Member 12: Okay. Perfect. Thank you.

41:53
Aryanna Brown: Yes.

41:57
Jayson Thorpe: One more.

41:58
Audience Member 13: I saw that you had to log in when you launch each of the individuals, if you are tied to Active Directory LDAP, can you configure it so that it's gonna take the user who's logged into that machine?

42:10
Aryanna Brown: Oh, so that it automatically, yeah, like Windows authentication type thing? Yeah.

42:15
Jayson Thorpe: Indeed.

42:20
Aryanna Brown: Any other questions?

42:22
Jayson Thorpe: If you are raising... Oh, down here in front.

42:23
Aryanna Brown: Oh, all right.

42:27
Jayson Thorpe: We would like for the mic just so it's available in the recording.

42:31
Audience Member 14: You kind of touched on the driver support, but do you guys support OPC, all the flavors like DA, A&C Alarms and Events, all those different versions? And then on top of that bus protocols, like is there a means in which to get PROFIBUS, PROFINET, fieldbus? There was some talk earlier about HARP through a third party, but...

42:47
Aryanna Brown: I'm not entirely too sure, but I can find out for you if you come talk to me...

42:51
Audience Member 14: All right.

42:51
Aryanna Brown: After the session.

42:55
Jayson Thorpe: Start in the back.

42:56
Audience Member 15: My question's around managing users and role capabilities. Currently we have single sign-on integrated with Azure Active Directory, and the way to manage that is inside of Azure. We make a user a member of a group and that gives, is that the only way to assign privileges and access to inside Ignition? Or are there other ways?

43:21
Jayson Thorpe: So typically, when you do use a service like that, as an identity provider or I guess a user source, there's usually options for like a hybrid management where you, if the permissions allow, potentially make a change to the user in the gateway and then that would update the source of truth. That as an option for most config for most implementations of user sources like that. All right. If you're raising your hand, and we don't see you, wave it around, please. All right. Well, thank you so much everyone. We will be here if you wanna talk to us at all. Thank you. We won't keep you here anymore.

44:05
Aryanna Brown: Good job. Good job, dude.

44:06
Jayson Thorpe: Right back at you.

Learn how to combine consistent processes with novel concepts to break through challenges in downtime tracking and OEE visibility. In this session, RoviSys will share how their DxOps Transformation approach, used at Nice Pak, helped overcome high variation between production lines and facilities, lack of data connectivity, extensive turnover, and data integrity gaps. Learn how to standardize integration methods for better scalability and real-time tracking and see how these solutions can enhance efficiency in your facilities. Don’t miss this "how to" guide on transforming challenges into opportunities for breakthrough success!

Transcript: 

00:00
Jesse Oehler: How's it going? So my name is Jesse Oehler and I'm a Technical Recruiter, Inductive Automation. And welcome to today's session, which is with RoviSys, titled, "Breaking Through Manufacturing Challenges with DxOps Transformation." I'll be the moderator for today's presentation. To start things off I'd like to introduce our speakers. Here's Samantha Willins. She's a Project Engineer with RoviSys in multiple vertical markets. She started using Ignition in 2018 and now leads the RoviSys Global Ignition Technical Committee, which is focused on novel platform solutions and information sharing. She ensures RoviSys resources around the globe stay up to date on the latest Ignition features and functions, promotes participation in forums, and drives innovation by identifying project accelerator opportunities. We also have Drew Daff. He's a Lead Software Engineer at RoviSys and he's part of the Digital Transformation and MES division. He has experience in designing and implementing advanced MES solutions across entire industries and regions.

01:08
Jesse Oehler: His involvement in numerous Ignition projects has addressed customer and configuration challenges, driven consistency, and improved performance that results in faster customer ROI. We also have Anh-Tuan Tran, who's a CPG Group Manager at RoviSys. He has more than 18 years of automation experience tackling customer challenges, ranging from DCS, PLC, HMI, SCADA systems layers to complex MES integrations. Since discovering Ignition in 2017, Anh-Tuan's been a continuous advocate for Ignition, enhancing data usability for manufacturers through both out-of-the-box and customized platform solutions. As a manager at RoviSys, he leads a team specializing in information data systems and OEE configuration for CPG companies. Please help me welcome our three speakers today.

02:05
Samantha Willins: Alright, well thank you for the introduction and thank you for having us at ICC. We're really excited to be here. I know I am. So, I just wanna say that we all know the theme is "Breaking Through," right? We're gonna talk to you about how we break through hurdles on our projects, and specifically we're gonna talk about a project we did with Nice-Pak and how we ran into a lot of hurdles and how we broke through those challenges to deliver a successful project. But first we wanna tell you a little bit about our company.

02:33
Anh-Tuan Tran: Hey everyone. I'm Anh-Tuan. I'm from the North Carolina office. A little bit about our company, if you haven't heard of us. We were founded in 1989. We're based in Ohio. We were founded by our CEO John Robertson, so he makes up the "Ro" in RoviSys, if you guys don't know how we came about our name. Really when we started, we started in the process automation space. But through the years as we hired different people with different expertise, now we actually offer a number of different capabilities in a variety of vertical markets, and then a variety of offerings in terms of implementations.

03:10
Drew Daff: Hi everyone. I'm Drew. I'm based out of our Ohio office. So, like Anh-Tuan mentioned, today at RoviSys we still do a lot of process automation work. But we also have a dedicated group that helps deliver turnkey solutions for other types of projects such as MES implementations, electrical design, setting up OT network infrastructures, integrating artificial intelligence or documentation services.

03:40
Anh-Tuan Tran: And as you can see here, we are a global organization. We have about 17 locations worldwide. We're just strategically positioned so that we can service our customers within that region. One of the things that makes us really unique is that across all the different locations, we share resources and work on projects together. This just allows us to put the right resources on the types of projects that we're implementing for our customers. The goal is really to give them that small company feel when we're working closely with them, but by being strategically positioned like this, we can reduce costs and improve the efficiency of implementations.

04:19
Anh-Tuan Tran: Alright, I'll talk a little bit about Nice-Pak. This is the customer that we did the project for. Right after the pandemic, a colleague of mine in our Georgia office introduced me to Nice-Pak. When they came to him, they actually had a Industry 4.0 initiative. And so, they presented a vision to me and asked me if I can help them on this journey, right? So we've been talking about Digital Transformation journey and Nice-Pak, if you don't know about them, they invented the disposable wet wipes. And so, right after the pandemic, their business was booming and they needed a way to really maximize the efficiency of production because the demand was so high. And they came to us and said, "Hey, what can we do? Where can we start?" And one of the things that we did was try to sit down with them and figure out a good starting point within their vision, 'cause there was a lot of stuff going on that they wanted us to help them with in terms of getting them along on the journey.

05:16
Anh-Tuan Tran: So, in this presentation, we'll talk about the project goals and deliverables for the project that we did for Nice-Pak, but one of the things that we're gonna do a little bit differently is beyond just talking about how we use Ignition to deliver a successful outcome, we're gonna focus more on the obstacles and the surprises that we encountered. So, it's more focused towards strategies for overcoming these challenges. And then what we're gonna do is we're basically going to give you guys our secret sauce. And as a system integration company, we don't actually have a product. A secret sauce is really just the proven strategies that we've developed through the years as we encounter multiple projects like this. What we've done is we've actually packaged up all of that knowledge and all the lessons learned that we've done from the project. We packaged it up into documentation and a game plan for us to approach these projects so that we can deliver a better solution. And really our strategy is just to mitigate risk and then create successful outcomes.

06:19
Samantha Willins: And this whole strategy is called the Digital Ops Transformation, which is where the "DxOps" comes in the name of the session.

06:28
Anh-Tuan Tran: Alright, a little bit of background to the project. I'm gonna briefly kind of touch on the different things that we did. But for Nice-Pak, we started with an OEE and downtime tracking project. And that was really just a good starting point for them. They were tracking OEE in downtime, in Excel spreadsheets. It was really bad. Like their dashboards were all in Excel. There were a lot of tabs and they were like, "Hey, it's gonna be really straightforward just to digitize this guys. Why don't you just take all these paper processes for us and then digitize it?" So, they had a paperless initiative. They call it the paperless shop floor goal, right? So, what we did was we used Ignition to digitize these process, but one of the things that we had to look at was, hey, if we don't really take the time to understand their future goals, if we come in with the technology and implement it, that might be the only project that we do with them. So our strategy was, take a different approach so that we can figure out what is the right starting point for them.

07:38
Samantha Willins: Oh, did I hit the wrong button? Sorry.

07:41
Anh-Tuan Tran: Yeah. So like for us, since we are an independent integrator and we're technology agnostic, when we go into these projects, we don't actually think of like what platforms to use right off the bat. The way that we approach it is that we have a architecture assessment process and we basically get all the stakeholders together and sit down, figure out what their business drivers are, and then from that understanding, we start building a picture of, what are the right platforms for them? So, for us, we basically have a scorecard, right? And we have a number of technology stacks that we look at, and then we start checking off the boxes and give them ratings. And in this instance, as you can see here, Ignition just checked off so many boxes for this customer, a lot. And so, they ended up becoming the solution that we chose and when we're in this process, we basically give them the pros and cons of all the different technologies, and then we also try to give them as much clarity as possible as to why we recommend this technology to them.

08:37
Anh-Tuan Tran: And then this allows the customer to see the transparency and the independent mindset of like, "Hey, we evaluated all these platforms, but this one fits the best for you guys and here's why." And they really liked that. And one of the things about Ignition that was great was that it was very, very scalable. And that was something that they were very focused on, was like, can I take this solution and then port it to other sites and scale it out, and then can we templatize all this stuff? And Ignition just fits the bill perfectly.

09:07
Anh-Tuan Tran: So, when we started this project, Nice-Pak is a global organization so they had multiple sites worldwide. It wasn't in their budget to do it at all the sites. They wanted to implement the solution at all the sites, but really they only had the budget for two sites. So we picked two sites that were similar but also vastly different. So the first site that we concentrated on was in their Mooresville, Indiana plant. This was an older site. They had aging infrastructure, a lot of their equipment weren't even connected or automated. So, in contrast to that, we also picked the Jonesboro, Arkansas site, which was a new facility for them, very modern, everything's automated, everything's connected. And this was kind of the two sites that we had to implement a solution that was global enough and templatized enough that we can normalize that data and show them that we can take this solution. If we can scale it at these two vastly different sites, then they knew they could take that solution and scale it out to all of their other sites globally.

10:03
Samantha Willins: Awesome. So that's a little bit of background on the project, so let's give you the secret sauce, right? Alright, so it may sound a little bit backwards, but it's been mentioned even in the presentations you've seen so far. We always start with the outcome of how operations will utilize the solution to get value. We have all the appropriate stakeholders in the room and we really like to have everyone down from operators up to the people that are handling the money. We like to have everyone involved because they're all using it. This is what we call our operational scenarios. So, for this solution, operations is gonna be using dashboards, user graphics, and reports to drive improvements in behaviors. And then we also do this whole process through our functional design specification design process. And that's creating user stories, mockups, and identifying those edge cases that can kind of trip you up if you don't look out for them in advance.

11:00
Samantha Willins: So once we start doing that, we start looking up at information flow, right? What data is available and how can we use that to design a structure? This is where you're gonna create your I/O lists and you're gonna start really just standardizing your tag naming conventions and things of that nature. Once you have that structure, you're gonna start developing base configuration and templatization and that's gonna be used across all the customer sites, right? So we always templatize the plant model to ISA-95 standards. And then we use built-in templatization and Ignition to build out the UDTs, the graphical templates, the lookup tables, and the global objects that are gonna be utilized across the enterprise. So if anyone ever moves locations, it'll be pretty obvious there. For enhanced features, those are gonna come into play for those edge cases we identified in the design phase. This is where we're gonna start really honing in on the equipment where it acts differently or just isn't connected at all. Then after that, we use our master data-driven configuration to normalize all that different data coming in and connect it within the Ignition tag database or an OPC server or MQTT broker or anything like that to just make sure that we have all the data where we need as we need it.

12:18
Anh-Tuan Tran: So keep an eye out for these icons on top of these slides. These are our strategies. And so, this is a strategy for having a scalable model. You can take this and implement it in any company and if you follow this approach, this is an easy way to make sure that your solution's gonna be scalable.

12:36
Samantha Willins: Yep. So, let's talk about the network architecture a little bit too, 'cause that's kind of a starting point, right? So their architecture was fairly simple. They had Ignition Edge gateways down here at the bottom that connected to the plant field I/O. Then it fed up to the corporate network. And I know it sounds a little scary, you normally don't want to do that. However, all the I/O was configured as read only. So, it was only going up, it was never coming back down, so they didn't have a worry there. With that, they also installed Ignition clients at each of the equipment stations for downtime reason entry, as well as they had giant 75-inch Samsung TVs with industrial PCs on the back as monitors for around the plant for metrics monitoring. So big goal about doing the network architecture was we really wanted it to fit into their existing structure and complement it, right?

13:31
Samantha Willins: You don't want it to be kind of standoff or be noticeable that it's an addition. You want it to merge well and flow with the existing architecture. And that was the goal here. So, let's kind of look at what the solution was. So, as Anh-Tuan mentioned, they had Excel sheets that were very complex and a lot of tabs. Anybody looking at these, they're going to, it's not intuitive. They're gonna sit here and try to figure it out for days at a time. So it was very complex, just not ideal for what you want to do. So this is what we made. We did a more intuitive theme, dark-themed application where you can look at this and hey, right, there's my OEE, I know it's right there, it's very clear. The good part about this also is it had multiple value streams. So this template dashboard was used for all of their value streams at both sites.

14:22
Samantha Willins: So their downtime, guess what, it was also tracked in Excel. So we also brought this into a more modern age with that as well. So, they were actually having people go down and count the downtime minutes and try to figure out what data was actually useful for the downtime. And it was a very tedious and long process. So we transformed it to this in a way that's easier to digest. It's very simple. You can see it. I mean, they already have the data, so why not put it in a way that makes it easier on them and saves them time. So we're actually, if you click these buttons up here, I hit the wrong button, buttons, anyways. So we actually have the ability for them to create downtime reason entries from either selecting from the current or even creating a new entry for the reason of the downtime. This is gonna help them identify the issues that are causing the most problems, ways to fix things if they notice that certain issues are arising, what they can do to save money and time in the long term. So, this is the solution but we're gonna have Drew talk to you about how we even got to this point.

15:36
Drew Daff: Thank you, Samantha. So, the room here is filled with people that know how to develop solutions. We all know that. What we believe at RoviSys is the true test is navigating the unexpected. So, the roadblocks, the hurdles, and the unforeseen challenges that arise along the way. So at RoviSys we anticipate these issues. So our real story is about our process to consistently break through these challenges to achieve success.

16:02
Drew Daff: Like Anh-Tuan mentioned before, the two plants we worked with had some similarities, but they also had a lot of differences. We had shifts that were different. We had operator processes that were different and the process to import schedules was also different. What our process allowed us to do though was capture these differences so that we could plan out how to deliver a consistent look and feel with not-so-consistent data. As we all know, customer processes change and what our process allows us to do is reanalyze the differences and figure out how to work around them and get the results that we need. For example, during our in-process design reviews, one of the plants saw what the other plant was doing and recognized it was a better process. So what they wanted to do was basically do exactly what that other plant was doing.

16:48
Drew Daff: Even though things weren't the exact same between the plants, like I mentioned, we adjusted and were able to give them very similar outputs. We also ran into very challenging edge cases and for these types of challenges, we have a process for our team to bring challenges that they're stuck on and go through them with some of our experienced developers that have gone through those experiences. We call that the RoviSys Architecture Review Board. And so, what that is, is a group of developers from, you know, all over the world at all our sites that bring in a lot of different experiences. And what they did was help us brainstorm solutions for functional gaps that we faced on the Nice-Pak project so we could rework solutions and avoid potential adoption issues once we were finished.

17:29
Anh-Tuan Tran: And this has been incredibly useful for us just to kind of identify SMEs within certain topics and then once we bring a problem to them that our team couldn't come up with, that team had a whole host of solutions that they could provide to us. And that made it so much faster to solve problems, especially when you can leverage that expertise and kind of have an organized group that did that work.

17:56
Drew Daff: Yeah.

17:57
Anh-Tuan Tran: So one of the earliest challenges that we had whenever we got into a Nice-Pak project was that they really had their own language or jargons that they used. And I think you guys, when you're working with customers, you're probably running into the same situations, their own acronyms. The things that they say when you interpret it is really not what they think, 'cause things are interpreted differently. So, when we start these projects, one of the things that we have to do is really sit down and kind of build that glossary so that we understand exactly what they're talking about. And then that allows us to synchronize with the team so that our team understands it as well.

18:31
Drew Daff: Yeah. And a big part of getting things right is, as we all know, learning what the heck the customer actually wants and what they need. So, often overlooked in projects like this is the voice of the actual users, that are living in the application day in and day out. A typical functional requirements document only outlines the technical requirements. So, but what it does is often misses how the system is really used by the people, like I mentioned, that live in it day to day. So, what we've done is we've built a process which helps developers understand the situations that operators and the users are in, so they can design and develop with those situations in mind. So, just a guess, a show of hands here if I can see. Who here has heard of SIPOC and KDD processes? Okay.

19:20
Samantha Willins: Yeah. A few.

19:21
Drew Daff: Yeah. A few. Good. So, for those who haven't, SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customers. So what this is, is a structured high-level map that helps explain the start and endpoints of a process and what's needed to go into that process. So, the inputs and the outputs. And this is all from the user's point of view, which is the important part. It's extremely helpful, not only in design, but like I mentioned earlier, the adoption of the finished product. So, moving on to KDDs. KDD stands for, Key Design Decisions. So, this is a process for documenting decisions and basically the why behind them. The why is very, very important because it helps understand the rationale behind the decisions that were made. A good example of this would be if someone forgot something, you have these decisions documented so you can go back and figure out why those decisions were made and move on.

20:21
Anh-Tuan Tran: And we didn't invent those terminologies. So, if you guys don't know it already, make sure you guys read up about it and learn about it, 'cause as we're implementing it, it's working really well for us in projects. So, it's just knowledge that we're trying to share, you know?

20:36
Samantha Willins: Yeah. These are not our acronyms, it's not just random letters for you.

20:43
Anh-Tuan Tran: Another obstacle that we encountered on this Nice-Pak project was that you know, when I sold this project, the customer told me that, "Hey I'm gonna give you all the tags that you need to check downtime." I was like, "All the tags, I don't have to put a control guy on this project?" And they're like, "Yeah, yeah, yeah, yeah. We got a guy and he's gonna give you all the tags. Don't worry about it. So you don't have to scope that piece." And we're like, "Alright, you give me all the tags. I can configure this whole application for you guys." That did not happen on this project.

21:16
Drew Daff: So, yeah. So just a quick word of advice. Don't always anticipate your customer's gonna give you exactly what you need. We all know how that goes.

21:25
Anh-Tuan Tran: Yeah. So, one of the things that we had to do on this project was that, when we realized the customer wasn't going to give us the PLC tags that we needed to give us the triggers for the downtime events or the counts to calculate OEE, the way that we staff the project is that we don't force or have a specific team in mind. We staff it based on the needs of the technology skill sets that we have at the duration of that timeframe. So when we identified that we needed a PLC person to come onto the project because they needed to pull up some Rockwell code to look into the Ladder Logic and figure out these triggers, we just created a staffing need for the duration, and we were able to staff resources from other sites. And they were able to come on for that short duration, got all the tags for us, built out the I/O list, and then we were able to continue with our development. And this is really important because it allows you to be very agile in terms of implementation, make sure that you don't lock in the team so that if you run into a scenario, you can adjust and pivot.

22:31
Drew Daff: So, another challenge that we really faced, and it was fairly big, as we all know, cyber threats restricted all network access for our customer. But fortunately for us, our implementation plan that we've gone over so far, meant that backups were available and stored in our local repos, allowing us to restore the system. What we did was we used this downtime to build our readiness checklist to make sure everything looked good to go when we were ready to get the system back up and running for our customer. During this time, like Anh-Tuan mentioned, our staffing model also allowed us to offload resources temporarily to stay efficient. And once that access was restored and everything was back up and running, we worked with our customer to get a fresh list of requirements that were needed to help get the system to optimal status.

23:17
Samantha Willins: And a good part of this too, is when we offload those resources, it saves the customer money. So, they're not paying for those resources to just sit. We're able to utilize them on other projects momentarily, to make sure that they still get the value for their money.

23:32
Anh-Tuan Tran: Yeah. And we're downplaying this event a little bit, but when we're hitting stage gates, we always do a major backup of everything that we develop. And that's just something that we do. And we have our own repository and in return that has saved us in a lot of scenarios when especially an event like this where you can take everything that you've saved, restore them, and get them back up and running within a day. So, it was very beneficial to get them back into production with a very short amount of time. And that kind of helps build into the cyber resiliency model that we have.

24:06
Drew Daff: So, I do have another question for everyone, and I don't totally expect an answer. So here we go. What do you guys do when your customer asks you for something important and you can't find it? So, this is an unfortunate situation we had to deal with on this project. Turnover dig at the best of both sides. So, the Nice-Pak side and our side, both the project managers on both sides of the project left and everyone that was involved with and executed SAT also left. So, we were kind of just dead in the water. So what basically happened was we couldn't find our executed copy of the SAT. The thing about RoviSys though, in this situation is we always try and do the right thing with our partnership mindset that we've gone over, our team adapted and did what was right. We broadened our customer success team and we were honest with Nice-Pak and let them know that we would be re-executing the SATs at our cost. This transparency and honesty is always something that is important to us and always will be. It's big with our partnerships. What helped to make this tough situation a little better is the fact that Nice-Pak was able to help us out while we were executing the SATs remotely. They were helping us out on site.

25:15
Anh-Tuan Tran: Yeah. And the key here is just work with integrity. Like if you don't know a situation, if you're just honest with the customer and you can kind of go and just tell them, hey, so and so worked on it and so and so worked on it and they're both not here in the company. We'll just re-execute the SAT and give you guys signed SAT that way you guys can have a more validated system.

25:37
Samantha Willins: Yeah. And those hard conversations are always hard to have, and no one looks forward to them. But I have known on multiple projects, the more transparent you are, the better the results overall. So...

25:52
Anh-Tuan Tran: Yeah. It's, show of hands. Who dealt with like turnovers or having to pick up from where someone left off or cleaning up other people's mess.

26:01
Anh-Tuan Tran: Alright. Definitely not unique just to us, right? So in this project, the craziest thing happened. We got the solution to the "go live" state. Now it's in the production floor, they're using it. And at the Mooresville plant there's a champion, at the Jonesboro plant, there's a champion, on our side, we have a project manager. And I don't know what happened, but at the same time, everybody turned in their two weeks. And that whole entire team was disbanded. Nice-Pak's like, we gotta assemble a new team. So when that happened, we were like, alright, what do we do? Because there's still a period where they're evaluating the solution and telling us whether it's working well, are the counts accurate? Are we doing the calculations? Are the reports working?

26:46
Anh-Tuan Tran: So, what we did throughout the project was that we just documented everything really well. So our function design specification, when we developed it, it was our engineering cutoff. But as we made and implemented the solution, we took screenshots of what we had and we plugged it into the FDS so that we have snapshots as we went through each stage gate to capture the as-built state that we were developing for the customer. And that really saved us in this scenario, because when they put on a new team and we assembled some folks to come in on our side to take over the project, that document allowed them to really understand exactly what was going on with the project, what are the deliverables, what our goals are, and how are we doing the calculations? What tags are we looking at to pull in these triggers and then what we're doing. So by dumping all that into one document, one central location, the onboarding process was a lot easier. So by having good documentation standards through your project, whether it's part of scope or not, we recommend that you always do it because it can save you a lot of time and headaches later on in the future.

27:54
Samantha Willins: Alright. So you heard a lot of challenges here. So, big thing here is all these challenges, I mean, they would typically result in a failure of a project. It would typically be very bad. After all the statistics show that Digital Transformation projects do not have very high success rates. I don't know why our image did that up there.

28:19
Drew Daff: But by adhering to our proven methodologies that we've gone over, we've transformed a high-risk project into a resounding success. And you can see we have some quotes up there from our customer representing that success. So, like Anh-Tuan mentioned before, keeping an eye on those icons on the screen up there. So throughout these challenges and obstacles that we've gone over, this is our secret sauce. What they represent is, like I said, and Anh-Tuan mentioned a couple of times, our secret sauce, digital operations transformation. So, what that is exactly is a set of scalable, repeatable processes that when followed consistently help us navigate, avoid, and overcome challenges on even the most complex Digital Transformation projects like we've gone over today.

29:06
Drew Daff: So, all these icons you saw are a specific set of service processes that we've standardized at RoviSys. Our team has decades of experience in Digital Transformation and all the scars that go along with it. So, what we've done is we've taken all that tribal knowledge that we have and expertise for delivering these successful solutions and packaged them up into these offerings that you see up here on the screen. By following some of the same standards we use, you can also de-risk your own projects and break through your challenges to success. There is a lot more behind these these standards here than just some pretty cool-looking icons. And we're happy to connect you with our digital operations team. And we also put a QR code up there for everyone to scan. It'll take you to our Digital Transformation website. And yeah.

29:56
Anh-Tuan Tran: Yeah. So, the big takeaway here is, as you are encountering these projects and you're working with customers, this strategy works guys. If you've kind of follow the format that we have, we know that this is a proven strategy for Digital Transformation projects. If you implement kind of that structure, it will mitigate the risks on those projects and then make you successful. So, if you have any questions, come find us.

30:20
Drew Daff: Yep.

30:21
Anh-Tuan Tran: And then you can ask us about these cool shirts.

30:23
Drew Daff: Yep. Cool.

30:28
Jesse Oehler: I can come on again, thank you three. Appreciate it.

30:29
Drew Daff: Yeah.

30:30
Jesse Oehler: We do have, we've got a little time left in our session, so we could have a little Q&A if people have questions, go ahead and raise your hands and we'll make sure you all get a mic. If we have more questions than our time allots, then these three will hang around for some additional questions afterwards.

30:50
Samantha Willins: You should be able to identify us.

30:52
Jesse Oehler: Yep.

30:56
Audience Member 1: First I wanna say thank you. That was a great presentation. I really appreciate your transparency and willing to share information. Could you talk a little bit about the initial part of the project, like the RFP process do... Did you find that the request for proposal had all of the necessary information contained therein to accurately estimate the scope of the project at the two different sites?

31:21
Anh-Tuan Tran: Yeah. So during the RFP process, actually first what they gave me was a PowerPoint that had their Industry 4.0 goals. And their goals were like really simple. They're like, "Oh, we want an ERP system that's totally integrated with MES. We want a digital CMMS or a digital QMS system also feeding information to our MES. And then everything's automated, everything's connected, and then everything's funneling up through the DMZ to the enterprise." I was like, okay, that's crazy 'cause you guys don't have any of that stuff right now. So we looked at it and we're like, "Okay, what is the biggest pain point for you guys right now?" And they're like, well, we're doing OEE and downtime tracking in Excel, and we print it out and fill it out, and then we go on the shop floor. And that's the easy starting point for us.

32:07
Anh-Tuan Tran: And they gave us these calculations of how they wanted to calculate OEE. They gave us their reason tree, and at both sites they also gave us their production schedule. So we looked at it and then we were scoping it out and it allowed us to kind of understand a good starting point to implement. But the challenge for us when we were scoping out was that they really thought they had all the data to give us to feed the calculations for OEE, and that was a gap. But what they did was they said, "Hey, let's grab some of our OPE budget on some of the screens and monitors that you guys were gonna buy and move that to labor, so that we can cover the cost of the controls engineer that you're gonna bring on site and work directly with our plant floor."

32:53
Anh-Tuan Tran: "And then we're gonna reduce the amount of screens that are on our line." And so we kind of like just worked with them. We were very, very flexible because it's money, like I don't care where you pull it from. If we can move it in and staff the resources and have the hours to do it, we did it. So we just made it so that we were in collaboration with the customer. And our goal is like, "Hey, if you can make their lives easier, they're gonna recognize that and they'll continue wanting to work with us." So that's our strategy.

33:20
Samantha Willins: Yeah.

33:20
Audience Member 1: Okay. Great. Thank you very much. And again, great presentation.

33:22
Anh-Tuan Tran: Thank you.

33:23
Samantha Willins: Thank you.

33:24
Drew Daff: Yeah. Thanks.

33:27
Anh-Tuan Tran: Right front...

33:31
Audience Member 2: I think one of the other presentations this morning was about the value of the Ignition community. And I'm really interested in OEE. Are you guys gonna publish any of that stuff to the [Ignition] Exchange?

33:41
Anh-Tuan Tran: We are trying to publish anything that is very reusable to the Exchange, to share the community. We created like Pareto charts that we've used in the past. I think some of the downtime screens that we've developed are at a level where it is customizable enough that we can share that, so that people can create their own downtime reasons. But we actually have a board and a group that are trying to build these reusable resources that we can share to the community. I don't know exactly which ones are selected because it kind of have to be standardized in a certain way... Yeah.

34:14
Samantha Willins: Yeah. So we have multiple different side projects going on, especially as we have projects that want things that are reusable, like so. So if we notice that there's a lot of a need to it, like PlantPAx and Ignition is huge. And we have lots of projects that want pretty much the exact same display but in Ignition. So, we actually are working on ironing out the last few minor details of that so that we can actually share those things, and we share them throughout the company as is with those alterations. But...

34:46
Anh-Tuan Tran: Yeah. But short story is we're Premier Integrators. We will contribute stuff to the community and downtime, especially downtime reasons entry is a great, it's a great use case that we can supply that.

35:04
Audience Member 3: You mentioned that one of the two plants recognized that one of the other plants was doing something really useful and they wanted to adopt it. Can you be more specific about what that was?

35:14
Anh-Tuan Tran: Yeah. It was really in the way that they were doing their shift management. The plants had different shifts, and they actually have a dedicated planner that was generating the shifts. And one planner was more sophisticated in terms of how they organized that information. And the way that we did it was we were able to pull in an Excel spreadsheet into Ignition, so that we can build the shifts because we had to correlate that data back to their downtime reasons and their OEE metrics for specific trips or shifts or specific SKU. And so, when the other facility recognized that, wow, your spreadsheet's so much better, we're gonna make our planner sit down with the other planner and learn how they're using their spreadsheet. And then that allowed us to really just make a few iterations of that spreadsheet so that we can import it back into Ignition. And then we actually pulled in their production schedule, so that when we display it on the dashboard templates, they knew what SKU they were producing, they knew what their targets were, they knew how much they needed to produce that day, and then how much one shift was doing against another shift. And then each value stream used the exact same template. Everything was plug and play. The UDTs just worked perfect and it made it really, really easy for us to implement and scale.

36:29
Audience Member 3: Did the old plant emulate the new plant or vice versa?

36:34
Anh-Tuan Tran: Yeah. It was actually different. The new plant emulated the old plant, 'cause the old plant was so outdated that they made a lot of creative solutions in Excel. So they were way more sophisticated in Excel than the new plant. So, yeah.

36:51
Audience Member 4: Hey, thanks for the presentation. I think at the start of the presentation, you had a slide there on the architecture. I'm just wondering, is that a, like from looking at the architecture, it kind of seems like maybe there was some work done in terms of Digital Transformation. I'm just wondering, was that something you guys did or would you come in at a later stage and finish off the project?

37:10
Anh-Tuan Tran: Yeah. So when we came in they wanted everything to sit on their Wi-Fi network, because we had to give them, so we use Elo tablets that allow them to have this touchscreen capabilities to kind of just enter in the downtown reasons. And then the dashboards were just Samsung TVs, but we needed a way to funnel that information but also protect the data integrity at the various plant. Because our Ignition gateway set on a VM on the corporate network. So we use Ignition Edge and we use OnLogic, which already had Edge built in it. And so we installed it there in different size of plant. The plant's pretty big, and it funnel all of the devices to Edge. And I think it was like 10 devices per Edge gateway. And that just funnel it through their firewalls up into the corporate plant. Everything's configured, it's read only. The only interactions really with the... The operators will enter downtime, but at the same time, we had a lot of trigger tags so that we could automatically generate downtime events as well in the background and categorize those. So...

38:15
Samantha Willins: Yeah. So everything we added is in orange. The blue was already existing on their previous system.

38:22
Anh-Tuan Tran: Yeah.

38:23
Audience Member 4: Yep. Thank you.

38:24
Samantha Willins: Yep.

38:27
Audience Member 5: Yep. So you did not decide to use the Sepasoft modules, right?

38:31
Anh-Tuan Tran: Right. It was out of their budget and at the same time the way that they wanted to do this was very, to them, very straightforward, they said. So when we were pitching it to them, they weren't really interested in it and they saw a solution that we've developed in the past that looked good, and they're like, that's exactly what we want. And ours is very similar. But then when we got to the design phase, we found a lot of differences, but the implementation is very templatized in the structure that allows you to really pull in any sort of reason tree that you want in the background, and then we will dynamically build out how many drill downs they need based on the plant model that they have. So, but yeah, this is, this is like, you can definitely build your own MES within Ignition if you wanted to, so that you didn't have to manage another module.

39:25
Samantha Willins: Yep.

39:26
Audience Member 6: What's the format of your guys' architecture review board? Like how does an engineer engage that board?

39:33
Anh-Tuan Tran: So, it's cross platform. So we don't actually, we bring in folks that have Digital Transformation initiatives. So it depends on the types of project that you're looking at. So like, if you have a question that is related to the OT/IT conversions, like we call it business IT. There's a different group there that have the networking expertise to kind of coach you through. In this instance, it was the MES group with Digital Transformation based projects. The challenge that we ran into was that we had one machine that could not give us counts. So, what we were doing was we were looking at the case packer to calculate the count, but the case packer needs to reset the count at a very specific interval. And the whole calculation became really complicated. So, we were just asking for some ideas or some options of how to implement this without having to spend a great deal of time or having to add in additional sensors. And so, they came up with a really good idea. I mean, you were part of that group, right?

40:32
Drew Daff: Yeah.

40:33
Anh-Tuan Tran: So, they came with a really good idea on how to implement it. We presented to the customer, they were satisfied with it, and then when we roll it out, it just worked. And they kind of gave a count that was very close to how they were already calculating it anyways in their spreadsheets. And after a couple weeks they started trusting that count and then they just shifted to using that count for the quality metrics.

40:56
Audience Member 7: Just curious if you could share how big the team was. And I may have missed the first couple of slides, and if possible, what the total duration of the engagement with the client was.

41:06
Anh-Tuan Tran: Sure. So the sales cycle is very long. On these projects, I don't know why it just takes a long time to get a PO. The team was very straightforward. We had a project manager who was responsible on the RoviSys side. We have a lead developer and then we had two software developers working underneath the lead. And so, the makeup was four people on the team. On their side, they had a champion, like an overall champion that was overseeing this solution for their global organization. And then each site had their own champion that was overseeing the production data and how to calculate the OEE and how to transform some of these manual-based process into more digitized process. And then each site had one controls person, at the Jonesboro site, we had a really good controls guy. He knew PLCs, he understood and gave us a lot of tags. At the Mooresville site, that wasn't the case.

42:00
Anh-Tuan Tran: A lot of the equipment we found out was so old we couldn't get the tags. And so we had to come up with a new strategy or approach on how to calculate or pull in that tag. And there were a lot of edge cases where, hey, if you can't give me this data, just enter it here and I'll capture that timestamp and I'll use that for now, until you can add a sensor and then we can just replace it with the tag. So, we had a lot of stop gaps like that where we just create, we created manual-based entry system to allow them to fake the tag and use that timestamp so that we can actually continue to build the OEE solution.

42:37
Audience Member 8: Hi. So you talked a lot about OEE as your MES deliverable. Do you have any other MES aspects that you gave for the customer or is it more driven by what the customer wanted?

42:47
Anh-Tuan Tran: So, scheduling was a huge one that was just inherently pulled in. We needed a way to understand the shifts and how to split up that data so that when they are generating the report, they can look at what shifts, what the OEE for that shift was. Or they had specific teams that they wanted to categorize, like there's a team A or team B to see who was performing better. So, what we did was we just treat it as master data, right? So if they gave us a spreadsheet and we understood the columns and the rows, then we can build it in as master data and then we can contextualize that on the reporting side. So, once they gave us the schedule and we built all that in, we can tie it to the OEE data that we were capturing, so that they can see exactly who was working on what and at what time and what was their efficiency. And so, what team was doing better and then what value stream was operating better than another. And so they had a couple of value streams that had very similar equipment, but some produced the same SKU, but they had older equipment and they can see real quickly what was the efficiency between one versus the other. And then we kind of broke it down so that they can see what piece of equipment was running really bad and then they can like upgrade it, so...

44:00
Samantha Willins: We typically do it based on customer wants and needs or things that we identify will benefit them in the long run. Like, "Hey, you didn't mention you want this, but this is something that might benefit you in the MES space."

44:14
Audience Member 8: Thank you...

44:15
Jesse Oehler: Yeah. I think that that wraps up the time we have available. I believe you three will hang around for a little while?

44:20
Anh-Tuan Tran: Yeah. We're hanging around. If you guys have questions, just come through, we're happy to share.

44:23
Jesse Oehler: Thank you all for joining...

44:24
Samantha Willins: Thank you guys for coming.

44:25
Jesse Oehler: These presenters.

How can you ensure that screens load fast and actions are snappy when using Ignition Perspective to create bigger and better projects? Learn how in this presentation, which will discuss strategies for optimizing screen development, organizing nested views, and analyzing Perspective execution. You’ll also get a look at simple rules-of-thumb for bindings, complex custom svg components, and where to strike the balance between performance and maintainability.

Transcript:

00:00
Moderator: This session is "Optimizing Load Time in Ignition Perspective," and I'll be your moderator today. To start things off, I'd like to introduce your speakers today. This is Elizabeth Reed and Casimir Smith from DMC. As the Senior Manager of SCADA and MES at DMC Elizabeth has extensive experience architecting and implementing Ignition SCADA systems with a background spanning industries such as energy, automotive, chemical, defense, and food and beverage. Elizabeth specializes in optimizing system performance and efficiency. She leads teams to create innovative high-level architectures that streamline operations, reduce downtime and maximize performance and productivity. Joining Elizabeth is Casimir Smith, a project engineer at DMC. Casimir is one of DMC's leading experts in Ignition SCADA and MES systems. He has developed cutting-edge Ignition and Sepasoft solutions in industries ranging from battery manufacturing to automated farming. Project highlights include designing production and planning maximization algorithms, MQTT Unified Namespace data models and user-configurable dynamic HMI screens. He is always looking to push the boundaries of what's possible in a Perspective interface. Please help me welcome Elizabeth and Casimir.

01:41
Casimir Smith: All right, let's get this show on the road here. So today, as we mentioned, we're gonna be looking at how to optimize performance within Perspective and to lay the groundwork, I want to first ask kind of what performance, what does it mean in our context? So there's a couple of different types of things someone can mean when they say performance, but we're really gonna be looking at this first one: perceived performance. And that really is how long do paid things feel like they take to load? What is that kind of initial on page load? There's some other things that are equally valid, but we're not going to be focusing on here, which is kind of responsiveness. How long between when there's an action and when the result of that action happens, as well as resource usage, right? What's your CPU memory load on your gateway? So we'll be looking at perceived performance here, and we really...

02:40
Casimir Smith: This is why we're here, right. You've been there, I've been there, tapping, waiting for your screen to pop up. Going to click a button and then having something replace the button that you were about to click. Sitting there wondering how long will this loading bar be? And this is what we're trying to avoid. This really is how can we make our user experience better and how can we make things snappy and make them feel good to use. To do that, we've got a whole host of tips and tricks here on how to design your screens and analyze your screens to make them as performant as possible. We'll be splitting these into some fundamental techniques here. Moving down the list, reducing the amount of data and calculation you have, reducing the layout recalculation that the browser does, reducing initial load actions and reducing heavy weight components in your screens. Those are some nice kind of fundamental tips, and if you have tried all those and you're still needing a little bit of help, we also have some advanced techniques here like analyzing the loading, using some browser tools, and also how to hide the loading and make things feel better than they might actually be.

04:01
Elizabeth Reed: So starting off, we're gonna start with a fundamental topic for reducing the amount of data and calculation that you're doing in the backend of your screens. So, one big thing with screens is bindings. We use them a lot in our screen development. Those are things like bindings and transforms, and there are some bindings and transforms that are more efficient than others. For instance, a direct or indirect tag binding are the most performant options versus a tag expression or a runScript expression. On the transform side of format or a map transform are the most performant and expression transform is medium and script is the least performant. And so, really, we want you guys to know this information and so you're able to make informed decisions when you're programming screens. If you could do the same functionality using a more performant binding or transform, you're gonna see a more performant system overall. And here's an example of a expression binding that is using three different tag expressions. Here on the right you see an example of the same functionality, but instead of using a tag expression, you are using multiple indirect tag bindings where you have three different properties that are using a indirect tag binding, and then you have an expression that is linked to the property that's displayed on the screen that is looking at those custom properties there. So, a great example of getting the same functionality but in a more efficient manner.

05:32
Elizabeth Reed: The next thing I wanna talk about is query efficiencies. And so this is most relevant for screens that display large amounts of data that you're querying from a database. One kind of basic tenant is always include a range limiter on queries that select from large tables. And so, this could be either time based or counter based. And really this is important, especially as a system is used over time in scales, you don't want unbound queries that in two years past deployment, all of a sudden your screen locks up because you're just returning too much data to that screen. So, keep the long-term vision in mind and always include some range limiter so you don't run into that issue in the long run. Next one is avoid polling. And so, if you are returning large data sets, you probably don't wanna automatically refresh that every 30 seconds, 60 seconds.

06:22
Elizabeth Reed: It's much better to instead have a refresh button to refresh that query instead. Obviously, this is not as optimal from a user point of view. Users expect automatic refresh and so use it sparingly in situations that it's needed with an especially large data set. The next one I wanna talk about is named queries with caching enabled. Named queries are a great tool that are better. They are a more optimized way to query the database. You can cache the data. They also can save the execution plan. And so it takes less time on the database side to compile the query. And they also just have better diagnostics for troubleshooting as well. So big fan of named queries. And then the last one here is with any large queries, you might be doing a complex query with some joins and things like that, and it might not be something on the Ignition side that's the problem. It might just be a really complex query that you need to troubleshoot in the database itself. And so there are a lot of great database tools that you can leverage in order to troubleshoot the query and write a more efficient query. On the MS SQL side, there's things like the query store execution plan monitoring, and in Postgres there's third parties like pgDash or a pgWatch that you can use to help troubleshoot and do more advanced database query efficiency improvements.

07:48
Elizabeth Reed: Next thing is scripting efficiency. So, scripting is great, we all use it a lot. Ignition is super powerful and because of all of the scripting capabilities that you can do, but you know, don't script unless you need to. It does add some complexity that could increase the load time of your screens. So just be cognizant of that and balance functionality versus performance. Obviously, avoid duplicate logic in a loop. And something that we still see around every once in a while is people using individual bulk tag reads throughout a single script as opposed to just doing one bulk tag read and then referencing the values throughout the script. So, just a reminder, I'm sure we all know, try and condense your bulk tag reads as much as possible into as few bulk tag reads as you can.

08:39
Casimir Smith: Alright, well Elizabeth talked a lot about how you're gathering data in your Perspective session, and that is really great when you're looking at your bindings and your scripts and your queries. But there's a whole other side of this for how the browser takes the components and the containers on your screen and how it generates a viewable page off of those. And that's what we'll be looking at. Next is the frontend side for reducing layout recalculations. So when we talk about how the browser renders a page, there's two concepts that I think are very important for Ignition and they are reflow and repaint. On the bottom here we can see a chart. It's not that important to understand the whole thing. We're starting with our raw HTML and CSS and in the end we have two steps here, our reflow and then our repaint. And reflow is anything that is recalculating the position and geometry of things on your page.

09:39
Casimir Smith: And for the browser, this can be an expensive process if you have to do it over and over again. In contrast to repaint something that affects the visibility but not position or layout, like changing the color of a component, that can be relatively quick. So if you have the choice between when something is alarmed to change its size or to change its color, often changing its color can be a way to reduce load on the browser. And really we just want to avoid bindings that alter that page layout over and over again. That can be things like a binding that changes the basis of something or the display property of something or its size that really is what, when overused can cause strain on the browser. So, we'll take a couple tips on how to reduce the layout recalculations here. One that is a bit of a niche topic, but one that I think a lot of people could use easily is persistence.

10:38
Casimir Smith: When you put a binding on a property, its persistence will be automatically set to be false here. And what that means is that instead of starting with a value, when the page loads, it starts to null when it loads until that binding loads and evaluates. And when you have something starting at null and then getting a value, that can really shift around if that property affects the layout of your page. So, oftentimes we like to set that persistence back to true, give our property a starting value, and then that can help us have our page initialize and not have to recalculate as much when the binding evaluates. And that can avoid some of that pop-in on screens that can also avoid some of those red overlays on initial load. Another thing that we see all the time, again, a favorite tool of people that can be overused is nesting embedded views.

11:39
Casimir Smith: And so, this animation on the right here shows just each level down is one extra embedded view deep. And I don't think anyone here is using eight embedded views nested deep, but there is even a real difference between something like two versus four nested views deep. So we try to avoid nesting more than three layers deep. We try to pass in things like tag paths instead of passing in large data structures so that we use our indirect tag bindings on the very deepest level and we try to play around with both with-parent and after-parent loading behavior. Unfortunately, there's not one clear answer on which one is better between this, it really depends on what you're looking to achieve and the structure of your view. The last thing I'll note on this is that this is a case where performance can sometimes contradict or compete with maintainability. So, if you have one core embedded view that gets used across a lot of templates, it can be really nice to use that one extra layer of nesting. But that's something where you need to balance it between do I want to have this one core embedded view and maybe suffer a little bit on performance, or do I want to spend that extra gain, that performance gain but not have to, or but have to maintain the same thing in a few different places?

0:13:09.6
Elizabeth Reed: All right, the next fundamental topic we're gonna talk about is reducing initial load actions. Now, what do I mean when I say reducing initial load actions? This is when a user pulls up an HMI on their screen and it first loads. So, how do we make that initial load happen faster? So the first thing is talking about calculations that might be intensive and moving those to a gateway scope. So, on the left here you see a more traditional architecture. The user opens a view, maybe there's a binding that has a script transform on it, that script transforms running some pretty intensive data calculations, and then it's writing that value back to a property that is then being displayed on a screen. So, this is executed every single time a user opens a view. And so if you know five people have that screen open, it's executed five different times and it is triggered based off of when the screen is opened.

14:06
Elizabeth Reed: So after the user navigates to that screen. So, an alternate way to do that that is a little bit more performant is moving that calculation instead to a gateway scope. So, thing like a gateway timer event, that gateway timer event will run the script to get the data, it'll then write that data to a tag. Then from the user point of view, they open the view, they read the tag from an indirect tag binding and they write the data back to the property. And so, it's a lot faster. A general note on this is that you can't use this in every single situation. For example, if you have a filter on the screen that the user puts in that alters the data calculation in any way, that would need to be client specific. And so, you'd still want to do that more traditional method where you're running the script directly on the screen. Maybe there's a way you can get that done still in the gateway scope method. But just know that there are some instances where you'd still want the other method there.

15:07
Elizabeth Reed: And then what does this actually look like? So right here we have the traditional workflow. The user opens the screen, there's a tag binding that's linked to the current tag here. And so, this is linked right there. We're running a script on this binding here that looks at the tag history and calculates the average over it. You can see there's about a two second delay between the tag binding loading here and the run script transform loading right there, which is pretty significant difference in load time. On the other side of it, this is using a tag right here. So still you'll have the average or the value down here. Instead we have an average value that is being written to by a gateway script that is running the same script that we ran on the screen, but at a gateway level. Then when you load the screen, it's instance, the difference between loading the current and loading the average is the exact same, which is why we do not have a GIF because the GIF would be instant for both of them. So not a very good GIF.

16:11
Elizabeth Reed: And then the last fundamental topic we wanna talk about today is reducing heavyweight components. So, Ignition has a lot of really great built-in components that we all use all the time. They have a lot of functionality. Both all of that functionality, they sometimes are a little bit heavier to load than a lighter weight component. And so, kind of a bare bones thing you can do if you're before Ignition one or 8.1.31 upgrade Ignition, in that version, they introduced React 18, which is much more performant. And so if you're seeing some slow load times, highly recommend upgrade to the latest version, you'll get react 18 and probably see some improvements there. So, that's a easy low hanging fruit improvement. If you're still seeing issues you can consider things like a custom lightweight component. And so this is a embedded SVG graphic.

17:05
Elizabeth Reed: And it's really helpful in the use case where you have a lot of repeated components that you're using on a screen that take a while to render. And so, the Ignition Exchange has a lot of really great examples available. Things like gauges and charts that you can use as a starting point. And so, although you are building a custom component, there are still some good resources that you could use to decrease your development time with the Ignition Exchange. And some particular heavyweight components that we, in the past have replaced with embedded SVG graphics or the XY chart, the gauge and pie chart and the markdown. Especially the XY chart, it is such a powerful component and it has so much functionality built in, but if you're displaying five, 10 of those on a screen, it could really add a lot to the load time. And so, in instances where you don't need all that functionality, taking some of that functionality out using an embedded SVG graphic instead can make that screen a little bit snappier with the load.

18:11
Elizabeth Reed: This is an example here of a, out of the box gauge Ignition component. We have it in a Flex Repeater with a 100 different instances of it and you can see how slow the load time is. It's pretty significant the amount of time it takes to load all a 100 instances of this. To counter this, this is the lightweight SVG component. And so it's obviously a lot faster. It does have less functionality, but for what we're using for it in this dashboard, it still is able to get the same data across. And again, just to go back to really emphasize the difference in load times here, the heavyweight out of the box component and then the lightweight SVG component here. So this is a great example of when you care more about the fast load time versus maybe some of those added functionality of the built-in components.

19:13
Casimir Smith: All right, well that was a great look at a lot of the kind of tips and tricks you can use while designing Perspective screens and projects. If you have gone through every single one of those and you're still wondering what is going on, you might want to look at some of these advanced techniques here. So we've got two that we're gonna talk about today real quick. First one is analyzing the loading in the browser using a browser tool like DevTools. So this can be really useful if you want to create two variants of a page and compare them against each other. Or if you want to look behind the scenes at how the browser renders your page to figure out why is it still slow, even after I've done all of these other optimizations. Next we'll also look at ways to cleverly mask or hide the loading within Ignition. This is if you have really optimized as much as possible, but you still have pop-in or screens that look strange when they're loading in. Or if you want to improve the page feel, regardless of what level of loading times you have. So to start looking at analyzing our loading, we are going to talk about Chrome DevTools. So a lot of browsers have tools like this. Chrome is just one of them that is very popular. You can get to it by just opening up Chrome.

20:38
Casimir Smith: It's built in. You don't have to do anything else. And opening up your screen, and then pressing either F12 or Control-Shift-I, or Inspect Element if you're used to that. When you do that, your screen will get smaller. You'll have tons of other information and controls on that top and side. And you can use this to test a lot of different things. One of the basics that we use all the time is not strictly related to performance, but instead to responsive design. And that is to change the dimensions of your screen, either just custom dimensions or pick a certain device. And that can test the mobile friendliness of your design or how it looks on different devices. Another one that we don't see as much is right next to it, the Throttle drop-down, where you can test how your screen might perform under different network loads. So you can really simulate what a slow client or a bad network might look like. The star of the show, though, in our minds, is over on the right here. We'll just look at the performance monitor and how you can use that to take a quick look at what's going on behind the scenes. So we've got an animation here.

21:56
Casimir Smith: I'm gonna let it run through once and then look at it kind of step by step. But again, we just need to open up DevTools, switch to our Performance tab, and then we can start recording, play around with our screen, and then stop recording here. And I'll go with it on this next one. So we can open up DevTools with F12, go to the Performance tab on the right, click that Record button to start recording, and then navigate in our page as normal. So we can click around, go to multiple pages, even do button actions and other things, and it will be recording that whole time. Then once we stop, it will generate an analysis of our performance that we can take a look at. And when it generates that analysis, there's a lot of stuff going on here, and it can be a little bit overwhelming, but there's a couple key things that we can take away from it. Starting at the top, we have the timeline. So that is where you can see the entire time that it was recording, and what the browser is doing during that time, and what the load of the browser is.

23:07
Casimir Smith: This also is very key, because you can highlight over it if you drag your mouse over it, and that really works well with the screenshot on that right side. So the screenshot is where if you hover the timeline, you can see the page and what it looked like at a specific time. Using those two tools together, you can connect the quantitative measurement of what the browser was doing at a given time with your qualitative measurement of what the page looks like while it's loading.

23:38
Casimir Smith: And you can really connect those two things and kind of unify them in your mind when you're doing your analysis. One other thing to look at is that process gauge at the bottom left. So, that shows just what time the browser spent doing certain actions. And because JavaScript and the browser is single threaded, it's only doing one thing at a time. So you can see when it is spending a lot of time doing that scripting, and when it's spending a lot of time doing that rendering, which relates to the reflow stuff that we talked about before. So, those are some really useful tools. There's also the stack trace, which in my mind is a bit too complicated for someone if you're just looking at how to analyze your page. So we tend to skip over that part and focus on those other three items here in the performance monitor. Lastly, we're going to look at how you can hide the loading. So how can you either incorporate animations, loading bars, other tips and tricks to make things feel better. And really, that's the key here. A user does not have a stopwatch when they pull open your SCADA screen. Things don't need to be fast, they just need to feel fast. And some delays are unavoidable. Maybe you have a Sepasoft script.

25:00
Casimir Smith: Maybe you have a remote tag provider binding, which has a one second baked in delay. So there's a lot of things that you need to work around. And some strategies, we're gonna look at avoiding overlay flickers with persistence and hiding them with fade animations. So, persistence, this is a quick one. We talked about it before, but again, this sets a starting value, a temporary value, while the binding loads. This is an example of what a screen might look like if there's not persistence. While all of those bindings are loading, this is in the case of a remote tag provider, we're getting red overlays while it waits. And that can be a little bit annoying. But if we have a persistent value where it defaults to a known value, let's say zero, it takes the exact same amount of time to load, but you don't have those scary overlays, which again, makes things feel a bit better. But we'll go one step further, and we can look at making a style class that animates our fade in, and can give our pages a really premium feel. We'll be releasing this so we don't have to copy down every single part of this style class definition, but what we're doing is we're creating a class that animates from zero opacity to one, and we can make multiple different classes with different delay intervals. The end result of this is a screen that can look really premium.

26:30
Casimir Smith: Wow. And it looks a lot like some of the more advanced web applications that you might be used to, where you have a skeleton that loads in, and then your applications load in on top of it. And so, to me, this can be a really nice way to make your loading feel like it's a process, and feel like it is not just slamming in all of our components on top of each other, but that we have a structured, nice way for things to come in, and the user oftentimes will like this, even if it's not any faster.

27:07
Elizabeth Reed: All right, so we talked a lot about a lot of different tools that you can have in your back pocket when you're trying to optimize the load time of your Perspective HMI. So, to kind of summarize the fundamentals, we talked about back-end and front-end improvements, including optimized bindings, transforms, queries, and scripts. We also talked about the toll of browser layout recalculations and how to avoid them, when to have scripts run on the screen versus a gateway event, and how to use embedded SVGs to create lightweight screen components to replace some of the more heavyweight, out of the box embedded ones. On the advanced side, we talked about some advanced loading analysis tools to have in your back pocket. And we also talked about how to hide loading when you tried all other optimizations and you're still seeing some lag in your system. So these are just the ones that DMC has found most useful in our development. I'm sure there's many others that you guys also have used in your development. But one thing I do want to emphasize with any code development, it is always important to balance performance versus maintainability. A very famous quote is: "Premature optimization is the root of all evil." So, don't try and solve a problem that doesn't exist.

28:19
Elizabeth Reed: Gather user feedback, then consider optimization. And many of the topics we went over today, it might introduce custom or duplicate code that makes it harder to maintain. Going back to a point that Caz made about the nested embedded views. Sometimes you want to use that library object, three or four layers deep, because it's easier to maintain and you don't care about the performance hit you're gonna take with that. So, just a reminder, don't go ahead and use all the tools we showed you today just because they're snazzy and nice. Do consider the overall architecture and the performance of your system before prematurely optimizing. And that is all we have. If you have any questions, feel free to contact us and also be Q&A.

29:07
Audience Member 1: I have a really quick one for ya. How many seconds of page load do you go, okay, no, we just need to start optimizing? Two, three?

29:18
Elizabeth Reed: Depends on the client. I mean, like some customers don't care about like a fast load time. Sometimes it's just an HMI that is on the production floor and they never move away from that HMI. So, is a fast load time as important for that application than somebody that's clicking around a lot, probably not. I don't know, what would you say?

29:43
Casimir Smith: Depends on the screen, right? If you have a screen that you use once a week, is that as important for it to load fast as a screen that you use once an hour? But I think for those snappy ones, really you want it to be within one, two seconds, but for the longer ones, that's when you start to see different needs.

30:05
Audience Member 1: Thank you.

30:08
Audience Member 2: So you talked about embedded views, and I agree it's not a good idea to use them, but what about the actual components and the... When I'm nesting components, if I use Flex container, I can get eight, nine layers deep, or I can just throw the XY container and have just one layer deep, basically. So what's better? Is there any performance penalty as I'm adding more layers to the component hierarchy?

30:39
Casimir Smith: So a couple of notes on that, in terms of balancing the niceness of the Flex container versus the performance of the XY. As far as I'm aware, at the current time, the XY is more performant, but the difference, especially in later versions of Ignition, is not a large difference. For us, we tend to focus on using nested Flex containers because of the added benefit for maintainability and readability. But there are some times where we will use those coordinate containers. I would say that's a case where the maintainability of the Flex container outweighs the performance of the percent XY container.

31:33
Audience Member 3: Is there a performance difference between buttons versus SVG, and especially if you need events or actions to be triggered off of the SVG?

31:42
Casimir Smith: Are you referring to where the SVG has individual zones for clicking within it, or just the entire thing as a whole?

31:52
Audience Member 3: Like your example with the hundred different things, if they needed to be able to click on those SVGs, versus just show some text on a button, what would be more performant?

32:07
Casimir Smith: So, an SVG with a click event, as opposed to a button with no graphics and a click event, the button is going to be faster. Because it doesn't have to pull up that SVG rendering engine, but it's not gonna show the chart, of course. Right, so anytime you can simplify, that is better. You don't have to bring in a rendering engine, you're just showing text, that is going to be faster. And that is kind of the same approach between why an indirect tag binding is better than an expression binding or a script transform. It's the system having to load in extra frameworks to use.

32:47
Audience Member 3: Okay, and especially because that's a standard component as for web, web technology is easier to generate, but as for the event piece, is there any overhead hit by triggering an event off an SVG versus a button?

33:03
Casimir Smith: I'm not aware of a significant performance difference between a click event on a non-button versus the on action performed on a button.

33:12
Audience Member 3: Okay, thank you.

33:21
Audience Member 4: Are there any approaches to reduce the initial Ignition load, especially where it's there saying loading resources and just doing stuff? Is there anything that can be done to reduce that initial Perspective load?

33:39
Elizabeth Reed: Good question. I don't know. I mean, that's like loading all your resources in your project, so probably not, although we didn't do a lot of research on that one. You have a better answer?

33:54
Casimir Smith: I don't. I know that it's module dependent and things like Sepasoft or other third-party modules can introduce more loading at that step, but in terms of do the components on your page affect that initial load, we'll have to do some research and get back to you on that.

34:18
Audience Member 5: I pretty frequently make use of the global script library for very repeatable scripts to retrieve data or format it somehow. Have you noticed a difference between a script binding and calling a runScript for whatever you need to do when a page loads in?

34:38
Casimir Smith: So, in terms of a script, are you referring to the runScript expression?

34:44
Audience Member 5: Yes. So, a binding calling runScript with a saved function off in your script library versus a coded on the binding, script binding.

0:35:00.8
Casimir Smith: We tend to avoid runScript expressions whenever possible, especially in older versions, but I think still in newer versions. RunScript tends to be worse than other ways of calling scripts on a page, like events and even, I think, script transforms. But in terms of calling a script from your project script library versus trying to run it on the action itself, we will always recommend having a script library no matter how small it is, because that just makes maintaining your code that much easier. Don't give him the mic. Oh, no.

35:42
Audience Member 6: I can't let that one go by. I've actually tested the performance of runScript versus script transforms and documented it on the forum. RunScript as the primary expression operation is somewhere on the order of hundreds of microseconds faster than passing a value than running a script transform when either one of them is calling a project library.

36:09
Casimir Smith: Thank you a lot.

36:10
Audience Member 6: RunScript blows the doors off of script transforms.

36:17
Audience Member 7: And as a farther note, if you turn them into classes instead of functions within the Python library, it loads faster as well, because of how Java handles classes. They're pre-loaded instead of at runtime.

36:33
Audience Member 8: Well, I have a question, if nobody else does. So DMC is competing in the Build-a-Thon. Are they gonna win tomorrow?

36:40
Elizabeth Reed: Fingers crossed. It's our redemption from two years ago.

36:44
Casimir Smith: That wasn't in my bio. It was Build-a-Thon runner up.

36:49
Elizabeth Reed: We didn't bring the race suits this year, though. So we were tired, though.

36:55
Audience Member 8: Thank you.

36:58
Elizabeth Reed: Alright.

Project Summary:

The Short-Baseline Near Detector (SBND) is the latest large-scale neutrino experiment at Fermi National Accelerator Laboratory (Fermilab), which will be used to analyze the properties of neutrinos, a family of elusive fundamental particles. The main volume of the detector consists of 112 tons of liquid argon, kept cold and pure by an elaborate cryogenic system, which is monitored and controlled via Ignition.

Problem:

One major opportunity for modernization and improvement on this project was the implementation of an object-oriented approach, including use of User Defined Types (UDTs). This stands in contrast to past projects, developed on another platform, in which every device (e.g., pressure sensor, control valve) had to be programmed individually with its own popup in the HMI.

Instead of adding custom features to select devices on an ad hoc basis, all devices needed a standard suite of features, permitting consistency and flexibility to our operators. For example, all transmitters (i.e., pressure, flow, temperature) should include scaling, filtering, simulation, error detection (open/short circuit), and trending. Furthermore, operators need dynamic alarms, ones they can enable, disable, and modify on the fly. On past projects, alarm management was handled by the PLC, resulting in a hardcoded set of alarms that was risky due to PLC restarts and laborious to change.

Solution:

The primary solution was a library of standardized objects, which Fermilab calls FermiPCL (Process Control Library). It includes heavy use of UDTs, both in the PLC programs and in Ignition. On the PLC side, instances of common function blocks pass information to each other in the form of UDTs, permitting them to share not only the process value, but also engineering parameters, error and simulation status, and the name of the object from which the value originates. On the Ignition side, Fermilab implemented a hierarchy of UDTs. This begins with a template UDT containing a common set of tags and parameters. The custom parameters, which are referenced by nested tags, identify the appropriate OPC item path, database, and alarm notification pipeline, such that these do not need to be configured on individual tags. Via inheritance, the template UDT then becomes the basis for 14 other UDTs, each of which corresponds to a function block definition in the PLC and has accompanying template(s) and a popup in Ignition. These UDTs each contain multiple instances of nested (and some nested-nested) UDTs, which correspond to the inputs and outputs of the function blocks in the PLC.

To address the challenge of creating UDT instances, Fermilab created a tag administration window. It uses Python scripts to facilitate this process. Each of Fermilab’s PLCs has an onboard OPC UA server. In the window, one button runs a script that scans the OPC UA server for tags corresponding to function block instances and displays them in a table. Another button then creates the corresponding UDT instances. When it encounters custom function blocks — those not in the library — it creates a new UDT definition and instances as necessary.

Fermilab also moved alarm management out of the PLC and into Ignition. Ignition has alarm management features built into the base platform that meet industry standards, such as ISA-18.2, right out of the box. There is no need to burden the PLC with managing alarms. By way of the Alarm Notification Module, Fermilab can alert appropriate personnel when problems occur, so they know to login and make changes as needed.

Results:

With the FermiPCL set of UDTs, templates, and popups in place, along with the tag administration window, developing individual projects is now much easier. This is especially beneficial on a large-scale project, such as the Short-Baseline Near Detector cryogenic system.

Adding sensors, valves, and other devices to the system has become a breeze. Given the device has been added to the PLC program, Fermilab simply scans and creates the corresponding UDT instance with the tag administration window. From there, Fermilab can drag-and-drop the UDT instance from the tag browser onto the desired window to place an instance of the corresponding template. And it’s done. Absolutely no manual configuration of tags is required whatsoever.

The ultimate result has been satisfied operators and smooth operations. Operators are very pleased with the new features and freedom of control that they have on this latest project. When they request additions, whether it be a new device or some new functionality, Fermilab can satisfy their requests expeditiously.

Start Date: August 2022

Deploy Date: February 2024

Project Scope:

Tags: 42,834

Screens: 63

Clients: 15

Alarms: 1,770

Devices used: 8 Beckhoff PLCs

Architectures used: Basic with redundancy

Databases used: 1 PostgreSQL database

Historical data logged: 2,157

Project Summary:

Goodman Fielder is a food manufacturer with a portfolio of well-known grocery and foodservice brands. Goodman Fielder’s markets span Australia, New Zealand, Fiji and the Islands, Papua New Guinea, and New Caledonia. This project includes the Goodman Fielder Baking division in Australia, starting with their three largest bakeries: Clayton in Melbourne, Victoria; Moorebank in Sydney, New South Wales; Burleigh Heads in Gold Coast, Queensland. Goodman Fielder envisaged streamlining the day-to-day production processes through Digital Transformation and implementing modern Industry 4.0 best practices and technology. To enhance production efficiency and product quality from the mixing equipment, Goodman Fielder identified the need for additional data automation, prompting the establishment of a SAP, Recipe, and Scheduling Initiative.

Problem:

Goodman Fielder Bakeries were facing production challenges stemming from outdated operational data management practices. These practices were hampering the realization of potential efficiencies and product quality improvements.

The daily operations team managed production using a combination of basic HMI interfaces as well as printed Excel sheets, with no integration into other production or business systems. This led to labor-intensive information management, with minimal automation and manual data capture prone to information and decision errors, hindering real-time understanding of operational conditions.

Some quality issues were only evident following the completion of the bread-baking process. Quality loss consumed significant additional processing costs and had a negative green impact to all the sites.

Deloitte identified that the key goals moving forward were:

• Right-first-time dough mixes.
• Reduction in scrap.
• Increase in dough mixer availability.
• The scope included five baking lines across three sites.

Deloitte identified two major issues:

Management of mixing recipes

The recipes governing ingredient addition and mixing parameters were stored and managed directly on the mixing equipment. This practice of “siloing data” led to customized recipes for each mixer, making it inefficient to implement updates and recipe enhancements across all mixers at a site.

Management of mixing schedules

Mixing schedules were communicated to the operations team through a printed SAP information data sheet, which was then manually entered into the mixing equipment. Adjustments throughout the daily production schedule necessitated multiple versions of printed schedules to be distributed to the operations team and subsequently re-entered into the mixing equipment. This cumbersome process introduced errors and restricted the realization of optimal production schedules.

Solution:

The first stages of Goodman Fielder’s digital strategy have been addressed by implementing a modern SCADA/MES platform built with Ignition and Sepasoft MES. The technology has enabled equipment connectivity as well as a rapid application development environment.

Goals for the new system include:

• Provide increased visibility of previous, current, and new batches.
• Allow SAP production plan to be updated dynamically.
• Remove dependence on Excel spreadsheets.
• Create a foundation on which additional best practices can be added such as track and trace, material consumption, etc.
• Develop and implement a recipe control system to ensure the optimized recipe is always applied.
• Increase operating efficiency of production equipment.
• Improve production visibility and transparency.
• Introduce a software platform that provides a solid foundation for future business initiatives through rapid application development and continuous improvement initiatives.

Deloitte recommended a two-staged implementation approach for recipe and schedule management.

The new automation of data from SAP to the factory floor represented a quantum leap in the working method used by the site operations team. Goodman Fielder decided to roll out the recipe system initially. This provided a view of the new system to a smaller audience. The system was used extensively in a short time with immediate positive feedback, allowing the technical baking staff to create, edit, and delete recipes based directly on BOMs pulled from SAP. The recipe parameters were then written to the PLCs. The objective was to create a recipe system that enables production teams to regularly review and adjust production recipes to ensure product consistency and quality.

The recipe system was followed by an interface that processed and sent production instructions-based SAP production schedule to respective workstations.

In parallel with this project, Goodman Fielder also envisaged introducing new automation interfaces where visualization and connectivity were sorely lacking in the process.

Goodman Fielder needed to achieve minimum functional compliance that retained the existing weigh station (used for manual/hand additions) and included viable products required to enact recipe and schedule management. This included:

• BOM SAP interface.
• Production planning SAP interface.
• Creation of recipes based upon SAP BOMs.
• Implement business rules against materials or material types.
• Dynamic use of the SAP-generated production plan. i.e., updates in SAP would be immediate.
• Workflows for abnormal conditions.
• User interface in weigh-ups for operators to view production plan and recipe. The Mettler Toledo RMS (Real-time Microbial Detection System) would be updated manually.
• Connection to Baker Perkins Line PLC to update recipe parameters. Bulk adds + mix. Reports and dashboards to provide visibility on: Previous, current, and future batches. Data for analysis for technical teams.

Results:

The following is a list of some of the improvements that Deloitte has seen as a result of implementing the Ignition MES/SCADA system:

• Improved accessibility to reports with the ability to download data to client PC makes it easier to use data in issue investigations.
• Reports can now be generated using up-to-date real-time data or historical data for comparison of current status to previous status.
• Visualization of plant and factory operating conditions allows ad hoc investigation if issues occur.
• Visualization of plant cycle times identifies potential issues before they occur. Reduction in material variance due to accurate scheduling.
• Downtime and waste reduction due to automated scheduling from ERP to plant equipment.
• Reduction of paperwork — less actual paper used and less time skilled operators are spending copying data from HMI to paper forms.
• Reduction in unaccounted waste.
• Better and more consistent quality of final product due to increased ability to modify product master recipes.
• Tracking/audit trail of process parameters allows for better outcomes from root cause analysis of production issues.
• Improved accessibility to information due to integration of MQTT broker and IIoT devices.

Start Date: May 2022

Deploy Date: Ongoing

Project Scope:

Tags: 13,000 at each site (x3)

Screens: 30 screens at each site (x3)

Clients: 12 at each site (x3)

Alarms: 8,000 at each site (x3)

Devices used: Existing office desktop computers located in the manufacturing areas. Additional tablets are being introduced when a suitable WiFi network is available in the plant.

Architectures used: Enterprise

Databases used: MSSQL server and EAM at Clayton, Moorebank, and Burleigh Heads. SAP Staging Tables — Custom Recipe and Schedule – Sepasoft Alarm DB - Ignition Historian DB - Ignition

Historical data logged: Event data is logged based upon the start or completion of a batch. The majority is logged in either Sepasoft schemas or custom built. Time-series data is logged via Ignition historian. Currently less than 1,000 tags are being logged per site.

Project Summary:

Madkour Group needed to achieve Digital Transformation on the SCADA agriculture project infrastructure and automation system for the National Project for Developing the New Valley in Toshka. The project aims to reclaim one million acres outside of Cairo as part of Egypt’s overall plan to reclaim and cultivate three million acres in total. Leveraging Ignition’s scalable architecture, unlimited licensing, flexibility, and rapid development tools, Madkour established a central control building to easily operate, manage, and maintain a large number of sites, equipment, and facilities spread out across this vast desert area.

Problem:

The area that Madkour is cultivating — part of the South Valley Development, a vast area in southern Egypt, approximately 1,200 kilometers away from Cairo — was originally barren, with no soil, people, or water. Due to this distance, Madkour faced difficulties transporting materials and equipment to the site and eventually established facilities to produce brick, steel, and concrete locally. The logistics of the construction were substantial: Madkour excavated over 3.2 million cubic meters of rock, poured more than 252,000 cubic meters of concrete, and incorporated an extensive quantity of steel structures, totaling more than 1,852 tons.

Originally, the pump stations were operated manually, and with each station an hour apart, this setup was not feasible given the massive size of the SCADA agriculture project. This led to the idea of creating a control center to manage the entire area of Toshka. To accomplish this, Madkour needed a platform with no limitations that would allow them to begin from a small scale during the first phase, then expand to a larger scope in the subsequent phases, and ultimately encompass the entire project.

Madkour’s challenge was to build this scalable, customizable, and reliable central system that could comply with the Toshka project’s unusual requirements and large scale, all in a relatively short period of time.

Solution:

Madkour ended up choosing Ignition for its scalable architecture, unlimited licensing, flexibility, and rapid development tools. The Toshka control center is designed to monitor and control all elements of the irrigation system, which include more than 200 irrigation pump stations, five main lifting stations, 20 electrical MVSG, LV transformers and electrical panels, and more than 2,000 pivots. Using Perspective’s web-based UI flexibility, Madkour built dynamic templates backed by hierarchically structured UDTs. This iterative approach allowed them to deliver a scalable system in a short time.

Results:

The system now gathers real-time data from remote locations and provides the operations team with the reporting and analytic tools for making data-driven decisions.

Each pumping station can operate automatically as it pumps water into the main canal to supply the substations and agricultural areas in Toshka. If any issues arise, operators can react quickly and efficiently, accessing the Ignition system remotely from any mobile device. The system records events and alarms and stores them historically. The operator can display them either in real time or as analytical data to help with corrective actions.

Additionally, operators can easily monitor all the aspects of the station like production rates, electricity and water consumption, cost per cubic meter of water, as well as compare the performance of equipment, and make predictions based on historical data by combining data from the historian with real-time data.

The Ignition system interacts with the electrical signals and measurements of each station. This interaction extends to medium-voltage distributors and transformers, along with various vital signals and readings of the SCADA agriculture project.

Madkour’s development group has grown from one person at the beginning of the project to a team of ten. Over 4,000 workers were involved in Toshka across all companies, including other organizations working alongside Madkour.

Ignition reduced the costs overall, particularly in manpower. Madkour started the project with four operators working at a single station, and now, one operator can manage 10 stations.

By the end of 2024, Madkour will have reached a total of 167 irrigation stations, 1,811 pivots, and five water-pumping stations over an area of 200,000 acres. Madkour aims to reach 300 irrigation stations and over 3,400 pivots in the next two years with a total cultivated area of approximately 600,000 acres of the Toshka project’s goal of one million acres.

Start Date: August 2021

Deploy Date: March 2022

Project Scope:

Tags: To be extended 800K tags

Screens: 25

Clients: 20

Alarms: Around 150K

Devices used: Around 150 M580 Redundant PLCs - 13 WAGO PFC200 RTUs

Architectures used: Standard

Databases used: 3 MSSQL (HIS, GIS, Reports)

Historical data logged: Around 160K

What’s the power of tracking your organization’s energy use? Understanding your energy data reduces your operational costs, and helps you assess equipment health and meet regulatory or ESG guidelines.

It’s hard to manage what you can’t measure. In this session, you’ll see how to quickly incorporate energy monitoring into your Ignition projects using free Ignition Exchange resources. Plus, you’ll hear from a State of Indiana representative who created the Energy INsights program that helps Indiana-based manufacturers address energy use while taking steps toward digitally transforming their business operations.

Transcript:

00:00
Rob Huddleston: Hello, I'm Rob Huddleston, and I'm a Technical Trainer here at Inductive Automation, and I'm gonna be your moderator for this session. To start things off, I'd like to introduce our speakers today. Benson Hougland is the Vice President at Opto 22. With 35 years of experience in information technology and industrial automation, Benson drives product strategy for Opto 22 automation and control systems that connect and secure the real world of OT with the systems and networks of IT in the cloud. Benson speaks at trade shows and conferences, including IBM Think, Arc Forum, and ISA. His 2014 TED Talk introduces non-technical people to IoT.

00:38
Rob Huddleston: Becca Gillespie is a Managing Director at Energy Systems Network. Becca joined ESN as a Managing Director in January of 2023. Prior to that, she had worked as a New Products and Services Lead at Duquesne Light Company and was a Sales Director and Product Manager for Unit Energy Technologies. She also worked at Federal Energy Regulatory Commission as an Energy Analyst and as a Propulsion Engineer at NASA.

01:07
Benson Hougland: Fantastic. Thank you, Rob. Welcome, everyone. Glad you're here. It's been a long ICC. Well, not a long one, but a great ICC. Everybody enjoying themselves? Had some good sessions and whatnot?

01:21
Benson Hougland: Right on, right on. That's good to hear. Thanks for hanging out all the way to the end to be here. I appreciate that. In the spirit of this year's ICC, of course, which is "Breakthrough," the title of our presentation is "Breakthrough Power and Energy Barriers with Ignition." So again, thank you for attending this afternoon. And thank you to all of you out there on the virtual sessions. Glad you could join us as well. As you guys know, these sessions will be recorded. So, as Rob said, my name is Benson, and I will be your host for this journey from your energy-consuming devices into Ignition. And as Rob said, I'll be joined by Becca Gillepsie. Gillespie. Sorry, Becca. And Becca is a customer of Ignition, of course, and of Opto 22. And she's gonna have a great story to tell you about her project in Indiana.

02:17
Benson Hougland: Now, I've decided to forego the obligatory Opto 22 slide and just... Well, if you don't know Opto, we've been around 50 years. We are a Southern California-based manufacturer of hardware and software. And we've been in business for 50 years. We've got thousands of applications all over the world, including one hopefully you just saw at the Build-a-Thon. So, yeah, we're involved in that as well. So, with introductions out of the way. Oh, not really. I love this drone shot. I got a drone. I thought, oh, this would be fun. So, that is our factory. And, indeed, it's in Temecula, California, about an hour north of San Diego, which makes it about eight hours south of here. And it is where we design, manufacture, support everything. So, indeed, all of the stuff I'm gonna talk to you about today that's relative to Opto is, indeed, made in the USA.

03:12
Benson Hougland: Alright. Now, with introductions out of the way, quick review of today's session. I'm not gonna read that to you. You've probably read it already, and that's why you're either here in person or have joined virtually. But, in short, we're gonna cover why monitoring power and energy in your facility or your organization can be beneficial. So, we're gonna show you how you can quickly start doing that with a pretty simple product and Ignition and get you on your way to doing some interesting things with energy. And then, following that, Becca will come up and discuss her Energy Insights program.

03:50
Benson Hougland: Okay. So the big question. Still got mic? The big question is, why? Why are we gonna monitor energy? Well, probably the obvious reason is, what? Save money? Typically, that's what we see. And there's no question you can actually do so. And there's a couple of reasons why. The big one is, well, there's several big ones, but one is that rising cost of energy. We heard Becca on a panel earlier this week talking about that's some of the things the state of Indiana and all across the country, in fact, across the globe, we are dealing with rising energy costs. The other thing that we're having to deal with is something called dynamic pricing. So now you're getting charged a different value for your energy based on when you use it. And then we have another situation where we have what we call phantom loads or phantom... Basically devices that might be in your plant that are using a lot of energy that you don't even know about and are adding up on your bill. But the big one, this one right here at the top, the demand charge. This is something you're probably not even aware of.

04:53
Benson Hougland: And let's be frank. You're probably not paying the power bill for your plant. Somebody else is. But, indeed, a demand charge is one of the highest parts of your bill. And what is it? A demand charge is when you're pulling energy from the grid into your plant, you're gonna pay for that over time. That's called kWh, right? And so how much you use in a month, you get charged for that. But you also get charged for the largest amount of peak power you use during that billing cycle. And that means when you fire up all of your loads within a facility, you may draw a whole bunch of peak power at one time. They peg that. You get charged for that. We are a manufacturer in the state of California. Energy is expensive here in this state.

05:39
Benson Hougland: And, indeed, when we started doing this, we ate our own dog food in quite a big way. That was the biggest part of our bill. Our demand charge was more than our consumption. So tracking that down is really important. Bottom line, you can't control or monitor your energy costs without actually monitoring your energy in the first place. Now, there are some other reasons why power and energy monitoring might be important. And it has to do with the health of your equipment. Putting an energy monitoring device on your equipment is like putting a stethoscope on there. So we can start getting some really valuable information.

06:15
Benson Hougland: For example, let's say a pump was starting to... You know, the current draw was starting to go up on a pump or a motor or something like that. And we see that happening over time. It may be a reason to call somebody in maintenance or set an alarm or something like that to go take a look at that asset before something damaging occurs to it. So that's a big one in understanding the health of your machines. And then, finally, we have something here called ESG guidelines. What are those? Environmental, social, and governance. Bottom line, it's a sustainability framework for people to monitor or at least track what their sustainability footprint looks like. And for those of you who did attend the keynote with Kat earlier in the week, clearly she made a pretty big point about how important sustainability is. And, in fact, a lot of that keynote was.

07:07
Benson Hougland: So there's a lot of companies that have to address these guidelines or other regulatory compliance goals. And, again, you can't do that if you're not monitoring your energy. Okay. So enough about why. Let's now start talking about what it looks like and how. So what I'm gonna do, I'll start using this thing. We're gonna do something that's an architecture build-out. If you've been to one of my sessions before, you know, I love putting pictures up and going through that flow. Now, don't worry. I'm gonna get into some of the details of each of these steps. But just as a big-picture look, let's take a look. We've got our energy loads. And you can see those up there as, in this case, an air compressor that provides machine tool air because this is what we have in our own facility. And, yes, we are tracking that.

07:53
Benson Hougland: And then just another nice image up there of an electrical hydraulic press. And, indeed, what we do is we monitor these devices by connecting RIO EMUs up to them. And I'm gonna get into that detail a little bit more. Once we do that, these RIO EMUs just fit right on the LAN, on your Ethernet LAN. So once they get on the Ethernet LAN, I'll use my PC or workstation, and I'll configure that device. I'll go in there. I'll create an account. These are cyber secure devices, by the way. So they're IT friendly and so on. More details on that in a moment. And then once I've done that, I'll configure the load, basically the size of the load. And then I'll turn on the built-in OPC UA server. And once that configuration occurs, I'm now ready to start configuring Ignition, which we'll get into. We'll configure the OPC UA client here in Ignition to the OPC UA server in the RIO EMU, and we'll start building out our application.

08:50
Benson Hougland: In fact, I'm gonna show you how simple it is to build this application and the reason why. We have Ignition Exchange resources. In fact, if you were at the Build-a-Thon, you saw there was an honorable mention for Alex Marcy's with Corso Systems, that Exchange resource. We're gonna use that to make it really easy to start pulling this data in. Okay. From there, where can you go with this? Well, clearly, I'm a big MQTT fan. I'm also a huge fan of Ignition Cloud Edition, and that's the next logical step.

09:24
Benson Hougland: We can use MQTT to start to get this up into, say, Ignition Cloud Edition or, frankly, to any software that can consume the MQTT data. For example, Snowflake. Maybe I'm gonna start taking some of my energy data and throwing it up there to Snowflake for analytics, for storage, all kinds of stuff. So aside from the fact that you've already got all this power in Ignition for reporting and historical, alarms, and so on, now we can extend that functionality very, very easily. So that's really cool. And, in fact, Becca's application she'll talk about is using a component of Ignition Cloud Edition. And I'd be remiss to not say that, yeah, the real EMUs also support MQTT natively. So we could actually connect directly to the cloud from them, but we're gonna keep this simple. We're just gonna go with this configuration here. Very, very simple EMUs to Ignition. You all on board? Let's see the steps.

10:20
Benson Hougland: There's not a lot of steps, but there's important ones, so let's get going. These are all the steps, and I'll go through these in detail. But the big ones are, as you can see in the bold text, we're gonna identify energy load. We're gonna instrument it. We'll connect and configure. We'll get those resources, import them into our Ignition project, instantiate the UDT, and drag and drop into Perspective views. Once we get past that load side of connecting the load, it's literally five minutes to get this stuff up and running. But first, most important part, what load are we gonna measure? There's a lot of different examples there. A lot of these we use in our own factory, the compressors, HVAC systems, but presses or industrial refrigeration, there's a lot of big loads that you may want to look at, not only for cost savings again, but for load health and reliability.

11:11
Benson Hougland: So pick those loads, but keep in mind when you pick those loads, consider that you wanna look not just at consumption over time, kWh, but you also wanna be looking at what the demand is. So another way to look at it is when you fire up a big load, like say it's a big motor, what you would look at the energy profile for that, you'll see it goes...

11:32
Benson Hougland: Way high when it starts up, and then it tapers off, and then it kind of rides out. That peak part, that's what we wanna pay attention to. So once we've identified our loads, then we're going to sensor or instrument them, and we're gonna use something called CTs, these are current transformers. All they do is take this current that's on a given load, and they take it down to a secondary voltage, in this case, 333 millivolts, making it really safe and easy to work with. We also wanna probably choose clamp-on CTs. Why? Because it makes instrumenting a load much, much easier. We're not gonna have to unwire the load and stick donuts on and all that. We can just clamp it on. The big thing we wanna do here is choose the right CT or sensor for the size of the load. The picture I have up here is a 600-amp sensor, so as long as the load is 600 amps or less, this CT will work, but there's all kinds of ranges that are available everywhere. You can even buy these on Amazon, and they're about $100, $200 each, so pretty straightforward there.

12:38
Benson Hougland: We're gonna use CTs, and then we're gonna connect those CTs directly to the groov RIO, the groov RIO EMU, I should say. More on that in a moment, but we're also gonna tie into the voltage line right into the RIO as well, and the beauty of the RIO EMU is it will accept up to 600 volts AC directly to that unit, which is very cool, so we don't need potential transformers and so on. We have power over Ethernet, or you can use line power, and it supports a number of different load types, so maybe some of you guys are like, okay, what is an EMU? No, it's not an Australian bird. It's an energy monitoring unit, and that's what we're gonna talk about for just a minute. This is not a sales pitch, but to put it in the context of the kind of tool we're using, I'll briefly go over this. 64 channels of data coming out of this device, both power and consumption, so it's actually tracking over time how much energy you're using. 3-phase, single phase, you decide, delta or Wye configurations, PoE or line-powered, cyber secure, out of the box, and IT friendly.

13:51
Benson Hougland: Uses DHCP, it uses DNS, it uses all the tools that IT uses to manage devices on a network, so it's a first-class citizen on any Ethernet network, and it's all browser-based configuration. So there's a web server inside, and all I do is connect the web server, and I start configuring it. There are some other nice features in there, USB for Wi-Fi and so on, but it does support a lot of different protocols, MQTT Sparkplug B, OPC UA, and for those of you who are still clinging on to your Modbus registers, yes, that is supported as well. And again, it's compatible with all kinds of different current transformers. And there's a laundry list of stuff over on the side, again, outside of the scope of this presentation, but know that this has got a lot of cool stuff inside that solves real problems like remote connectivity, and it can even run a control program if you want to do that, but we're gonna keep it simple. We've got the RIO EMU on the LAN. Now we're gonna... Once it's connected to the network, we'll create an admin account. No default passwords, no backdoors, anything like that. We'll set the hostname, set the time, set the certs.

15:03
Benson Hougland: We'll configure the load type and the current and voltage values, and then we'll go and configure the onboard OPC UA server. Now what we're getting from these CTs and the voltage is two things: current measured in amps and voltage measured in volts. Those are the two primary pieces of information you need to start gathering all this information about, again, consumption relative to cost and health and reliability of a given load. Once we have that load type in there, again, it's just the size of the load and its configuration, then we'll configure the onboard OPC UA server so that we can get here into Ignition, and indeed we'll just use the OPC connection page right within Ignition, connect to OPC UA. It goes out, discovers the OPC UA server on the RIO EMU. If we just go through the wizard, couldn't be any simpler. Ignition's done a great job of making it really easy to connect to OPC servers. Once that's done, you give your new OPC connection a name, something unique to that particular load, whatever it might be. It could be a compressor, it could be a press, it could be whatever.

16:16
Benson Hougland: Once I have that done, now I'm ready to start making the job easier. Now, yes, you can just right from here start building your tag, dragging over OPC tags, your tag provider, blah, blah, blah. But we made it really easy for you. What we've done is we've created... I've worked with Corso Systems and Alex Marcy to develop these UDTs and Perspective templates that are freely available from the Exchange. Log in, download these, get them onto your computer. Once you've done that, we're gonna go ahead and import those into Ignition. First, what we're gonna do is import the UDTs. Pretty simple. I go for import, go where the file you placed on your PC, and boom, just hit that single step. I now have my UDT definition already ready to go in Ignition. So while I'm here in an import phase of my project, I'm gonna go ahead and import... Oh, yeah, I think it was already going down to that.

17:14
Benson Hougland: Let's go back to here. Once I get that, I'm gonna import my templates. So pretty simple there. All your templates and styles will come right in, and look at that. Under the Perspective folder, RIO EMU Template. We named it specifically so that it wouldn't overwrite perhaps some other styles or templates you might be using. Okay, we're in good shape there. Let's move on. Next thing, instantiate the UDT. We have the UDT definition. Now we're actually going to create the device in a tag folder. So we go new tag, data type instance, the UDT itself, and I fill out a set of parameters. Now this is cool because what we're doing here, look at these parameters. You're actually modeling the load with this parameter dialog. So I can give the load a name. I can give it its location, its install date, what the load phases are. I'm literally modeling my load. So I'm not just looking at volts and amps, right? I'm looking at a load, and it's configured all within that UDT.

18:16
Benson Hougland: So that makes it real simple to start moving the data up with context. Super important. So here we are. I'm pulling in this load, and I did pull in the compressor from Opto 22, so these are all real numbers. Yes, that compressor draws 39 kW when it's running, providing tool error to our manufacturing plant. Cool, huh? Next up, we're going to literally create a new view. I just choose the defaults here, and I'm gonna click on the UDT, and I'm gonna drag it to the canvas. And boom, there it is, all done. All I've got to do is resize it. It's fully responsive, so you can change its size around and do whatever you want. I've got it. I'm gonna save my project. Here we go. I'm gonna go load it up and launch Perspective in the URL or in the browser. Voila, how cool is that, right?

19:09
Benson Hougland: It's so simple. It's so simple. Now, these are free Exchange resources, so you can do whatever you want to them. You don't like the Opto red at the top? Hey, I won't take it personally. No worries. All of that is available, and as you saw, I can click through different tabs. I can see all the phase information. I can see all the totals, and I can see what? The modeling information. That's a Sullair LS-10. It is indeed on our manufacturing first floor, and the load type is 300 volt RMS wye instead of a delta. So, there's my completed application. Here, all I did was bring on two loads and the same thing, and I used the Perspective default template to put it in there, and now, within, again, just a few minutes, I now can see what my energy is doing for any given load. I can do the whole building. I can choose different loads, whatever you want, but it's really cool, and I did it all with this little guy. So, while Becca's getting up, 'cause that's who's up next, I'm gonna pass this little RIO around. So, it has my name on it, so yes, I'd like it back.

20:16
Audience Member 1: So it's signed.

20:17
Benson Hougland: Yeah, it is signed. It's autographed. And I do have an Apple tag in it, so don't try to walk away with it. So there you go.

20:35
Benson Hougland: Got mic. Test one.

20:39
Becca Gillespie: Is mine working now? Not yet. Okay. Oh, now it is. Great. Alright. Thank you, everyone. So, yes, I would like to share with you a little bit about how we use this architecture in the Energy INsights Program in Indiana. So the Energy INsights Program is a state-sponsored program meant to provide free deployments of pilot projects for small-to-medium manufacturers in the state of Indiana and show them something about their energy consumption and get them started on their digital journey. It's paid for by the IEDC, the Indiana Economic Development Corporation. Oftentimes, EDCs are seen as just whale hunters getting that next chip factory or battery factory, but they also, at least in Indiana, try to keep existing manufacturers competitive, it's a lesser known mission of theirs. But it's important, and keeping them competitive is what they're after in this program.

21:42
Becca Gillespie: Our program would be nothing without our integrator partners, because I'm just one person at ESN. I don't implement each of these pilot projects, and we work with Axiom, LHP, recently Brugh, Blue Ridge, who's here today, TensorIoT, MartinCSI, and NineTwelve. We would also be nothing without our vendor partners, Benson, of course, at Opto 22, and Inductive Automation, and then we have some channel partners who are also in the space of helping people begin their digital journey.

22:19
Becca Gillespie: Great, so Benson did a great job of explaining why energy is important, and Energy INsights in particular has these dual goals of helping them start on their digital journey and help them reduce their energy costs. But just to reiterate, one thing is, we want every small-to-medium manufacturer to understand and reduce their energy costs, and we think that it's a good pilot project because everyone pays for energy. It's something every manufacturer is paying for, and everyone is using, and so in that way it's easier for that to be a shared and make shared resources that are applicable to everyone. And they're also rising energy costs, as Benson mentioned. Another thing is they're not competitive, so can create a better space for collaboration, because one person reducing their energy cost, even if they're in the exact same field, really doesn't impact directly someone else's reducing their energy costs, so people can work together. You just both are paying the utility less, which is, you know, good, even though I used to work for one.

23:24
Becca Gillespie: And then there's all the other uses of energy data, which Benson mentioned, but also I've seen some really cool presentations here about how interesting amp data is because, you know what? It is the heartbeat of your machine. So, yeah, I don't love when people use it for that, but that is really cool, and I love to see how people are figuring out the health of their machine with amps. And then the GHG requirements.

23:50
Becca Gillespie: Essentially, just to describe the program at a high level, as if you were small-to-medium manufacturers in Indiana, which I know most of you are not, but just so you understand, essentially half of the grant goes towards the hardware and the software package we give. That's, as I mentioned, Opto 22 and Inductive Automation, and a little bit of extra money for the current transducers and the boxes and the other things that they may need to get it started, and about half the money goes to time spent with an integrator to deploy, integrate, work through all those IT/OT challenges I've heard so much about, and then also, hopefully, once all that's done, help them develop a real custom use case with their energy data or with their other data in their plant that kind of meets their needs where they are at that moment. We also have a pretty light training program, just meant to help people understand how to use their starter kit, what is energy data, why might they want to look at it, what are the things they're seeing there, what is their energy bill.

24:52
Becca Gillespie: We help them... We do a short training on upskilling and where to go next after this, and another training on scaling. So a lot of the whole purpose of this product is that they can grow with it, it can grow with them, so we do a training with them on that. But what do we hope that they walk away with? For one, we want them to have actual measurable insights. We want to measure a KPI of dollars saved, and we want them to really walk away with that knowledge so that they can chart their own course through the Industry 4.0 landscape. So if at the end of the program, no offense, Benson, it hasn't happened yet, but if they threw the starter kit in the trash, and they said, "But I know what I do want," that would still be a success for Indiana. And luckily, like I said, that doesn't happen, people really end up liking this starter kit. And of course, understanding energy data.

25:50
Becca Gillespie: So why energy data? What is so exciting about energy data? As Benson mentioned... Well, for starters, I mean, saving energy is a big project. There's a lot of things that a small-to-medium manufacturer can do that an energy auditor can help them do. An energy auditor walks through your plant and tells you everything that's going on at a single point in time. So I always recommend manufacturers who are in the energy space and want to save energy, do that too. Getting everything at once, but at a single point in time is really important. But data over time helps you in a really different way. One of the key ways that data over time can help you is with that demand charge reduction, as Benson said. Reducing one's demand charge, it's more of an art than a science.

26:34
Becca Gillespie: Your demand charge happens whenever all your loads are firing at the same time. And you can't really... You have to almost play with sometimes the startup sequencing, which is basically the corrective action to startup sequencing often, or the, sort of finding of natural storage. Natural storage would be like your building can stay cool. It has a thermal capacity. So you could pre-cool your building so that your AC's not on when you're also firing your big equipment, finding natural storage opportunities. But sort of flattening that peak, taking... Maybe you're using the exact, oops... I don't know how to... Oops. Maybe you have the exact same energy, you know, the integral under that curve hasn't changed, but now it's flatter, and you save a whole bunch of money on your energy bill. The other is energy efficiency. Some of the examples... And examples from the program of demand charge reduction have been just that, startup sequencing. We have someone who's working on changing the way they process things with respect to when their solar's online, and figuring out ways to flatten their demand curve.

27:40
Becca Gillespie: And one that just came on that also wants to sort of optimize when multiple pumps are running at the same time, because they have some flexibility, so that they don't have as big of a demand charge. The next is energy efficiency. For that, some of the... Again, that's where, you're actually measuring that area under the curve, the amount of water you drink, if you sort of think of the water analogy. It's energy efficiency. And so for this one, how does data help? Well, yeah, it is good for you to have that energy audit. They walk in, they say like that there's a leak in your compressor system, or there's, that motor's way too old, and if you bought a new one, it would pay for itself in three months. Great information. But the leak in the compressor system is also something you could discover with data over time. So if you're monitoring your energy every day, it's going up, and up, and up, you know something's wrong. Now you're using more energy than you were a month ago, probably there's a leak in there. Another one has been, that's been used for a lot in Energy Insights is justifying an investment. So some people compare like an old line to a new line, figure out how much energy they save on the new line, and then they can justify some investments or upgrades to their old line.

28:58
Becca Gillespie: And in one particular case, a customer was able to save 20% off their energy bill by figuring out how much a VFD would save them, and then watching that change, and then installing VFDs throughout all of their fans and their system, and running it at a low. It's essentially running it at an optimized speed instead of just a fixed speed, which is what AC motors do. But yeah, again, most people wanna use it for other, the other category, which as I mentioned, you've heard a lot about today, we had one group work with this to do sort of an OEE, a very rough OEE of their equipment, how often was it running above a certain kilowatts, to get a sense of how often that equipment was on. Another one of our base dashboards does a part counter, which again, it just looks for those humps in the amps, or actually in power, because we wouldn't just use amps, because we're using Opto 22.

29:54
Becca Gillespie: So it looks for those humps and says how many times did it go above this many kilowatts, and then you can also measure sort of kilowatt hours per bump, so you can get that sort of production real time, how much energy was per part, if these are parts. Now often we're testing these things on Benson's data, so I'm counting cycles on a compressor instead of actual parts, but one of our customers is using it now for their part counting. And then, so monitoring, just the most simple one of monitoring when equipment is on or off. So this is the architecture. We are very similar to the one you just saw, and I learned a new word this morning, so I'm excited to say I think our UDTs are referencing, they're referencing Benson's UDTs, and we take that same information that he gave, the raw data coming out, and do some information with it.

30:57
Becca Gillespie: You have to plug in someone's demand charge, dollars per kilowatt, you have to have all these dashboard features, and where it's located, what the temperature is there, things like that. So we have all of our dashboard-related analytics and configurations referencing the UDT that Benson made, and then we have a base dashboard set that helps these people get started. I actually forgot to mention this one, production, that's actually an old version of it, but production is just kind of on or off. I guess I don't have one with the part counter. Anyway, but yeah, essentially energy, power, and so on. But yeah, essentially the program gives people three points in their plant, so we often advise them to do something that looks like it will be an interesting study, or the three biggest loads, and then we do allow for the on-the-cloud version, but because so many small-to-medium manufacturers are not yet ready for that, we also have an on-prem version as well.

32:00
Becca Gillespie: But that's pretty much it, what makes Indiana unique. I went into this a bit yesterday, but there really aren't a lot of other states that say the best way to digitize is through helping people pilot it. Often there's just the workforce development aspect, but I think that this is a really unique program because of that. It wants to... It doesn't just train the people who are working on it, and trust me, our training is not training them, it just points them to Benson's many YouTube videos, and Inductive University, and gets them very barely started, but getting their hands dirty is a really great way to learn. But also it trains the CEOs, it gets them used to it, it gets them comfortable with it, it gets them thinking about smart manufacturing differently. So I think pilot programs are a great way to do it. But yeah, that's pretty much what makes Indiana unique. So I think that's all my time, any questions?

33:03
Rob Huddleston: Okay, well thank you Benson and Becca, let's give them both a great big hand.

33:10
Rob Huddleston: So we do have some time for questions. Please raise your hand, and please wait for a microphone, the streaming people can't hear if you just ask.

33:27
Audience Member 2: Alright, I'll be green. Becca, are those smart dashboards available on the Exchange?

33:32
Becca Gillespie: You know, they aren't right now. I'm learning about the Exchange right now. I think when they're mature... I mean, they're pretty mature. But they're not there yet.

33:41
Audience Member 2: The quicker you give it to us, the more than we can play with them.

33:43
Becca Gillespie: Yeah, yeah, sure. Okay, I mean, yes, I think I can make them available on the Exchange, and the reference UDTs. I think, not knowing that word, I had a hard time explaining it to people, but it sounds like that would be meaningful to you. If I told you what a reference UDT was, you'd all get that, it sounds like.

34:01
Benson Hougland: A reference tag to the UDT. So that's...

34:03
Becca Gillespie: So it's like...

34:04
Benson Hougland: The references.

34:06
Becca Gillespie: Yeah, I can't say...

34:07
Benson Hougland: The engine tags that are coming.

34:09
Becca Gillespie: Yeah, I didn't know how to explain that before.

34:11
Benson Hougland: And just so you know, Becca and the state put this program together, they also paid for the development of these dashboards. And indeed, she's been willing to share. So Becca did share with us these dashboards, and we just launched a pilot project for McDonald's stores in Southern California. So they're using the same templates that Becca's team put together. So indeed, I think that's our next step. Let's get these guys on the Exchange as well.

34:48
Audience Member 3: While we're getting that figured out I can ask my question. When we talk about historizing data, have you found like a sweet spot for how quickly to save energy data so that you can aggregate it into like a total monthly usage?

35:10
Becca Gillespie: How quickly? So I usually take Benson's raw data, which comes out once a second. His 64 data points come out once a second. By the way, he's actually can get harmonics off of his, Opto 22. He's measuring at 4,000 hertz, and then turning it into many data points, including harmonics, real and reactive power, all of these things. But I take that once a second and use it... We've only basically compressed it with dead bands as opposed to compressing it further. But it is a little bit cumbersome sometimes to access the long data for monthly reporting. So actually, they take a lot of load. So if you guys have suggestions on that.

35:52
Benson Hougland: Yeah, we offer both kW and kWh. And I think that's important because the kW, of course, is real-time power at a given moment in time. Great for dashboarding real-time values. But the devices are also capable of storing the data, the kWh, which can be remotely reset, say at the end of the shift, at the end of the day, at the end of the month. So now you can start collecting that data too. But when you get it into historization, yes, you're probably grabbing those sample data and store them in a historical database. But I think...

36:22
Becca Gillespie: I should add, yeah, for the peak power, actually when you need to aggregate the kilowatt number, it doesn't actually make sense to do anything more refined than what your utility is using. And 99.9% of all utilities use a 15-minute data window for their peak power calculation. Now you might not hit the exact same 15 minutes as they're hitting. And so you might get it off. But we do collect 15 minute, we have a separate data point that's just on the 15-minute data. So that's a good way to get the peak over the course of the month. And then, like I said, for the... Like Benson was saying, for over the course of a month, you can look at the end energy and the beginning and subtract them. And that's a pretty good way to do it. He collects that every 30 seconds.

37:08
Benson Hougland: Yeah. And that UDT, when you download it, you can get into the UDT and we're actually doing the calculation for the interval data in the UDT. So we're getting that 15-minute kW and it's at the top quarter, half past the hour, set on the time of course of the gateway. And also kWh, 15-minute interval. So you know how much you consumed over that time.

37:32
Audience Member 4: Okay. So you mentioned you were at FERC. So you probably know what an ISO is.

37:37
Becca Gillespie: Yes.

37:37
Audience Member 4: ISO, that's the world I deal in at the grid level.

37:41
Becca Gillespie: Oh, great. Yeah. Love that.

37:43
Audience Member 4: Okay. So my question in this program is you're talking about peak demand, which is a utility chart...

37:48
Becca Gillespie: Yes. Yeah.

37:49
Audience Member 4: But are you anything with like 5CP or are you're... Not yet? Oh, good. We're...

37:54
Becca Gillespie: No, we're not. I wish we were. I'm so excited that you asked that.

37:57
Audience Member 4: I'll help you do that because that's a revenue stream...

38:02
Becca Gillespie: I know.

38:02
Audience Member 3: That they could tap into. 'Cause are these customers using wholesale or retail?

38:07
Becca Gillespie: So most of them are retail. They often do have access to demand-response programs. I literally don't wanna use the word "demand" to describe two things. Like when I say demand charge and they're just learning about that for the first time.

38:18
Audience Member 4: Right. I don't wanna confuse you.

38:19
Becca Gillespie: And then I go here demand response. This is a totally different thing about the hottest day of the year. So I haven't breached it that much, but I like would so love it. In fact, we had a utility tell us.

38:30
Audience Member 4: We do that as a company.

38:31
Becca Gillespie: Love that. Yes. I would love to talk more...

38:32
Audience Member 4: I'll talk to you after this because we have... We actually, I think, knew about you guys...

38:38
Becca Gillespie: Oh, cool.

38:38
Audience Member 4: Doing this and I'll talk to you afterwards about helping you with the peak demand, that kind of stuff.

38:42
Becca Gillespie: That's really great.

38:43
Benson Hougland: Yeah. We've been involved in DR programs at NYSERDA, at MISO, at CAISO for dozens of years. We're on our own DR program at Opto. Oh, perfect. Yeah. PJM. That's another one we did.

38:56
Becca Gillespie: One of our partners actually told me one of the reasons that they have a hard time implementing DR at manufacturers is because the utility cannot tell them in a real time what they're consuming. And so when they say, go down to one megawatt from three, they can't say if they've succeeded or not. And that has been a huge hurdle for them. So they said, why don't we put all these Energy INsights programs in those? But you know how utility... I mean, I used to work for one, so I can bad mouth them. But yeah. So, you know, they can't really work with you very effectively. So typical. No. But I would love that. I would love that. Yeah.

39:42
Audience Member 5: So I was just gonna answer some questions that were asked. Brandon from Blue Ridge. So the integrators are working together right now to put together things for the Exchange. We're mainly working on converting ICE to on-premise. So that helps answer that question. Once we have it all packaged and vetted out, we'll get those out there. And then as far as seeing the historical data and how we can aggregate that, we ran into some issues with Power Charts and the way they were working. So we're working on building custom components to show the aggregated data better, if that helps answer that question.

40:12
Becca Gillespie: Yeah. Thank you, Brandon. Yes.

40:14
Benson Hougland: Yeah, that's exactly...

40:15
Becca Gillespie: One of our beloved integrators.

40:16
Benson Hougland: Yeah. And Blue Ridge did a fantastic job on some of this early templating and the Perspective styles and templates and styles. And that's another reason why I'm really excited about 8.3 and the new Power Historian. So I think we're gonna see some really cool things there in terms of storing this kind of energy data using the new Power Historian.

40:46
Audience Member 6: How would an Indiana small business get involved or an Indiana integrator get involved in this?

40:53
Becca Gillespie: Great. Yeah. Great question. For the small businesses, we have a website. It's energyinsights.tech. I probably should have plugged that here at the end.

41:01
Benson Hougland: Yeah, I just never thought about myself.

41:03
Becca Gillespie: I'm the worst. So but yeah, and then essentially that contact form goes to me and that would be a way to get involved. We don't really have a process for growing our integrator base. We're kind of just doing it as the program grows. So we have just grown to include Brugh recently and we haven't necessarily expanded beyond that. But certainly we're looking for additional sustainable funding options. We're looking at other states for sustainable program opportunities. The DOE just released a grant that was for basically exactly at this intersection of smart manufacturing and energy. So as those grow, we can open that capability again. But as we are, we're just working with this group to try to continue to churn through the projects.

41:47
Rob Huddleston: One more question.

42:02
Audience Member 7: Thank you. This was pretty good. Are you seeing this... And you did mention this briefly, we're going out to other states or other countries, this process that you worked out, which is government-funded support to small-and-medium sized manufacturers?

42:19
Becca Gillespie: Yeah. So there is, like I mentioned, there is this DOE grant, but we didn't necessarily have other states submitting on our behalf for that. That was due on Monday, sadly. But maybe your state submitted it and it is, I can send you the link if you come up after and you can see if your state went after it. And then there's SESAME, it kind of works in that same intersection as well. They do pilot projects in the intersection of energy and...

42:51
Benson Hougland: Smart factory.

42:51
Becca Gillespie: Smart factory. They're not as so prescriptive as this. This is kind of a unique... It's a little bit prescriptive for some people's tastes, which I understand, but it's also a way to get started. You know, pros and cons. But they're less prescriptive. They're more of a, like, choose-your-own-adventure pilot. And then Purdue is starting a ManuFuture program. And it's manufuture.net. And they may work with us to continue to pilot these programs. But no, I think we'd still be open to sharing it with more states and countries. It just hasn't happened yet.

43:28
Rob Huddleston: Alright. Well, thank you again.

43:30
Becca Gillespie: Thanks.

43:30
Benson Hougland: Thank you, everyone.

We have even more exciting Ignition 8.3 features to show you! Join us in the second of two sessions as we continue to share what’s new with 8.3. This time, we’re looking at some project-level resources and other features available through the designer, including new Perspective features, changes to the Tag Historian Module, and the brand-new Event Streams resource.

Transcript:

00:13
Reese Tyson: Hi, welcome to the second session of 8.3 Deep Dives. Honestly, we're super thrilled to be sharing some of the newest features of Ignition that will make... Honestly, this is going to be the best version yet. So, we're super excited about all these features. As you heard from some of these previous presentations, obviously there's a lot of great things coming out. And so, we're just excited to see how these features and dive into these features and see how they can really expand the platform, make them super dynamic and scalable, and honestly, the most flexible platform yet. I'm Reese Tyson. I'm a Sales Engineer here at Inductive Automation.

00:52
Matthew Abran: And I'm Matthew Abran, Sales Engineering Manager. And you might be wondering, what the heck is this giant chameleon for? What does it have to do with Ignition? And if you weren't here in the previous session, if you didn't have the right context, you know that's a valid question. So, yeah. We're doing a deep dive, essentially, into all the features of 8.3. In the previous session, we talked a lot about the platform features and some various things that Carl and Drew went over. So, now we're going to talk about all these next incredible features that Ignition, it's gonna take Ignition to the next level. But so we're not done yet. Let's go ahead. Let's bring out that whole basket of features.

01:40
Reese: Yeah, Paul. Paul doing the heavy lifting over here. All these features in here. All right. Well, so let's get into it. So, right, we're diving into some of these features. So, the first feature that we have here is actually going to be associated with these crayons. So, I am a father of a two-year-old. I'm very familiar with crayons, right? My daughter, she makes some beautiful drawings. Whether the drawing stays on the piece of paper or whether it gets onto the wall sometimes is another question. But these crayons represent the first feature that we'll be talking about in this session, and that is drawing tools. So, drawing tools, of course, allows you to create incredible visuals inside of Ignition. It's a first class, fully embedded SVG editor for Perspective inside the designer. For anyone who's been paying attention, this has certainly been a long time coming, right? So, this is the most requested feature on the ideas page, as you can see. You all asked, right, our community, we listened, and 8.3 we delivered. And it turns out that building a fully featured SVG editor is not really an easy task.

03:04
Reese: There's only a handful of folks that have actually done this out in the wild. And then, marrying the fact that we also wanted to make this really seamless to integrate with the designer and this SVG editor. And so, you can imagine there might be a little bit larger task than what you might expect. But, as you can see here, Drawing Tools is a way that you can create shapes, lines, merge objects, specify design details, and so much more. In fact, for those of you that have used Inkscape, I know a lot of folks have been creating visuals in Inkscape. For those of you that have been using Inkscape, this will look familiar to you, right? It's a similar experience. You'll be pleasantly surprised because we actually used Inkscape as kind of our inspiration for this new feature. So, let's dive into the details of what this really actually looks like inside the designer, right? As you can see on the right-hand side here, we have a brand new Perspective component. This is called the Drawing component. And so, you drag that onto the screen, just like you typically do with Perspective components, and it gives you a brand new, a blank SVG that you can, of course, build from scratch, anything that you want, right?

04:28
Reese: But you also might be asking, "Well, Reese, I have a whole host of other SVGs that maybe are existing or that I want to bring in a motor faceplate" or those types of things, and you might be asking, "Well, can I use those as well?" And the answer is, of course, yes. We can import SVGs into the designer as well, and then it's as simple as going to that SVG and right-clicking on it and converting that to a drawing. And so, this example here actually shows a motor, and so any SVG-based components inside a Perspective also have this capability, right? So, whether it's an SVG that you bring in and import or if it's an existing SVG component, we can convert both of those to a drawing component. Once it's a Drawing component, then you can just simply right-click on that component here and edit the drawing.

04:28
Reese: It's that simple. It's that easy to access the drawing editor there. So, here's a quick snapshot of some of the different functionality within the drawing editor. So, just to kind give you a lay of the land here, across the top you have, of course, your undo, your redo, your merge, your bring to front, all those common things you'd expect out of an SVG editor. On the left-hand side, we have the pointer tool, the line. You can create different types of shapes, triangles, rectangles, those types of things, text boxes, and then on the right-hand side, right, you have the ability to tweak these components and change how they look, whether that's the width or the height, the color, the stroke, all these types of things.

06:11
Reese: So, you can really dial the components down into exactly what you want to craft and how exactly you want that to look. One of my favorite features, and this was highlighted briefly in the tech keynote there, but one of my favorite features here is actually the bindings and how they interact between the designer and the drawing editor. So, you can see here, I just created a basic binding inside of the drawing editor, and then as you click through the elements of this SVG, it's showing up there inside of the designer, and this actually works both ways, right? If you make a binding on or inside the designer, it's going to be copied over and available for visual in the drawing editor. And so, this kind of goes back to we wanted to make this experience as seamless as possible. But really, that's just one of the features, right? There are so many different features that are available. We definitely don't have time to go into all of them, but some honorable mentions here: rename elements, browsing the elements, bringing icons and components from front to back, and so forth using the gradient tool, right? A lot of things that you would expect out of an SVG editor. And then just one more example here of things that are capable within the platform, right?

07:32
Reese: I was able to spin an image of this, of the Drawing Tools up here, and I wanted to just create a windmill, see how it worked and how easy it was. It took me about just a few minutes here to create a windmill that looks like this inside the Drawing Tools and just kind of duplicate and replicate that across your project. So, there you have it, folks. Drawing Tools, it really gives you a way to make custom visuals all within Ignition inside the designer. All right. Well, let's see what we have next in here.

08:18
Matthew: Yeah, let's stick with the Perspective thing. Okay. How about that? Yeah, that triplicate paper.

08:22
Reese: Triplicate paper.

08:24
Matthew: What is this for? What could this form be used for here? So, of course, we're talking about the Perspective Form component. So, yeah. So, for anyone that saw in the keynote, you saw a little bit of that there, and we're gonna do a deep dive into what is the Form component. Before we do that, let's kind of backtrack. Can't we already do that in Perspective? Well, of course, as mentioned, we certainly can. You can build forms. You can build really nice forms. They can be very complex.

08:52
Matthew: They can handle validation. You can submit data to all kinds of different processes. But the way they're built today is it's a little bit more cumbersome. You have to manually place all of your elements. Usually they're nested inside multiple different containers. Your views component tree looks a little bit like this. And then if you need to go back through and maybe make some changes, that could end up possibly breaking some paths, which is important when you start looking at how you have to deal with validation and submitting this data to whatever end point that you're looking for. So, of course, this very simple example doesn't even cover 80% of what you might typically do here. But you can imagine if any one of those paths changed, you'd have to go back and redo that, kind of rethink that. So this new component is really built specifically for forms of codes. That is the Form component. But it has all of those concepts in mind. So instead of specifying one individual element as part of the normal component tree, you actually specify just rows and columns and different widgets from a list of standard input fields. And then it also includes, just by design, it's used as CSS Flex. So that means it's already responsive. So you don't have to go back through and figure out that styling.

10:18
Matthew: It just does it for you. But you can also go through, of course, and customize it. You can do customized styling. So let's go ahead and take a quick look at the basics here. So we drag out a Form component just like that. You can see in the component tree on the left, it is just that one component. So it simplifies that part. It's also similar to maybe dragging out like a Menu Tree component. You drag it out, and then you can configure the items in it as a property in Perspective's property tree over there on the right side. So new fields are just simply added in different rows, different columns, and you select which widget that you want for that. It also works, of course, with standard styles, as I mentioned, and it uses a standard GUI for that. So you can go in here and you can see we can change the style pretty easily, just as you would expect, but we can even apply it, say, to the entire form pretty easily. So overall, it definitely simplifies the design aspect, but not only does it simplify that visual design part, it also simplifies the functional side.

11:19
Matthew: So validation support is included and has many different field types just automatically included that help with that. It also can populate fields and even hide or disable fields automatically just based on a little bit of configuration, which we'll go through as well. So you can see here, here's an email. It is incorrectly formatted. We can immediately see what is wrong with it. As an end user using this form, I can clearly see that something is typed in wrong, and we didn't have to create this style and create this feedback. At the same time, you can see that submit action is already disabled. So it's very clear, and that was just all part of the Form component. So to configure that, it's really just a set of standard properties, like I was saying. It gives you the control but keeps it simple. So we can go and just enable some sort of maybe pattern or a range. It can't be above a certain number. It can't be below a certain number. It all depends on the field type that you're using, the input type. But again, it is all just configuration, and so it is rather simple. So let's take another look at some more of the example fields here. This isn't even all of them, but it has all the expected ones that you would think of.

12:43
Matthew: So text, email, URL, phone numbers, passwords, telephone, radio buttons, check boxes, everything that you would typically throw into a form, and it can certainly do even more than what's listed here. And as just a quick note, I was playing around with this form to create this demo, and I had originally created it as one single column, and I decided it doesn't fit quite right. So all I had to do was right-click, copy a section of the property tree, paste it in a new location, and now I have the two columns. So I didn't have to redo anything, change any of the validation. It's all ID-based, so it worked out pretty well. And here's an example of showing that that same Form component, that Form component that I configured, is just automatically responsive. If I shrink down the screen, you can just see that the fields shrink down, but also radio buttons, check boxes, everything wraps. So I didn't have to do anything extra, anything special. It just handled it right away for me. Another cool feature of this that makes it really powerful is that the data can be populated ahead of time through the properties.

13:49
Matthew: You can see a data property on the right side; various ID-based kind of input components are listed there. So those actually go all the way back into the property tree that reference some sort of field, some input field that you have specified, and it's all ID-based, so even if you move things around, it will show up in the right place. So I can go in, play around with it in the preview mode, make sure it's set up the way I want by default, and then that's it. So it doesn't matter if you move things around. Data is just collected in one place, which makes it a lot easier to work with. The other feature I was talking about earlier, about the disabling and hiding different properties here, that's, again, just configuration. So you can see all I have to do is specify that. When do I want this field to be enabled? Well, when a certain other field is in a certain state. So if this toggle is off, then I want these disabled. So the checkbox and radio buttons are disabled. If I turn that toggle back on, then it's all enabled again. And a quick thing to point out here as well is a lot of this is just all clients, all browser side.

15:01
Matthew: So that's why it works well overall is because it's not firing a lot of different bindings that you have to control. It's all browser-side. It helps remove kind of that isolation of the individual components that you would normally have to configure. So it all goes into one place, which does make it easier to handle that submission action, which you can certainly do through standard actions like you'd expect. So if you originally were building forms and you put a submit button on there or a cancel button and you do an action event for that, you can still do that. You have an on submit, an on cancel as well. And so you can just take that data from one place and be able to write your script around that. If you have to make changes later, you don't have to worry about differences in locations and paths. But besides that, there's another option for the Form component. So you can actually specify that you want it sent through the submission event system. So there's a process flow that will go through. It will queue up that event and actually send it. And if you are offline temporarily, it'll queue up. Once you're back online, it can send it.

16:17
Matthew: And there's even more to that as well. And all this really does is end up in a session event handler like you would expect. And it provides the parameters that you would need to get the context around what happened here. And a lot of this is very important for the offline mode. So the form component certainly works with Perspective's new offline mode. So let's see if we have something else here in the basket.

16:37
Reese: Got another item? All right, well, looks like we got a mangled Ethernet cable that we've scrounged around from the IT department.

16:48
Matthew: Yeah, certainly. So, yeah, with the offline mode here, sometimes you're not always hardwired. You might be wireless. You might even be in a remote location. So what happens if you're in a situation where you need to open up your Perspective app to input some data and you have no connection at all? Well, that's where the offline mode comes in. So it's a new mode for Perspective projects. You can make a project actually launchable inside or in this offline mode. So not many people know this, but certain features of Perspective will still continue to work while you're offline if you already have the app up and running. But if you did not have that, then you can't get back into Perspective.

17:35
Matthew: So you can imagine some different scenarios where this would be quite useful. And so it actually just downloads the resources to your device, keeps them up to date, and that's how the form component also still works. It works because it works off of a lot of browser side and through those resources. So that means if you create certain views in your project and you enable it for offline mode, you can still go through, and just like this example here, be able to access those pages. So maybe you need to pull up a diagram or something that you're looking at, and you don't have an Internet connection or a connection to the gateway at least, and you can still do that. Maybe pull up a static line diagram for a piece of equipment that you're looking at. And so it's pretty useful for doing this kind of somewhat offline remote data entry, those kinds of scenarios.

18:32
Matthew: It does require the Perspective mobile app, so it works on Android and iOS. It's an opt-in type of model for a project, so not all projects are automatically exposed for this offline mode. You can, as the developer, decide what project goes into offline mode. And then users on their side, they get an option to go and download it, and then it will download it and keep it in sync, as long as they stay connected. And so there's an indicator provided to provide feedback there. So just like what we're showing here, I'd go in, find the project I want, click Make Available Offline, and then I'm good to go. So what we can look at here is kind of what's the use case? What's the user story around this? And I kind of alluded to it earlier. If you're driving out some remote location, maybe there's no network at all, no cellular, nothing, and you still need to be able to take advantage of Perspective and go through that Form component, especially, input your data, and then just keep going. You're not slowed down. You don't have to make notes in paper and then come back to the gateway and do it later. It's all done, and it's all right there. And so it makes it far more easier. So, yeah, I think, Reese, it's time to bring out the next item.

19:56
Reese: The next item? Well, honestly, I've been looking at this, and I'm not sure what this is or how it made it in here, but how this is... Before your applause happens, this is actually not a part of 8.3. It was completely a joke. So, we're just getting ahead of it, right? We knew you were gonna ask, so we're just, like, addressing it here in the keynote, all right? The next feature is actually an atomic model. So this is atomic model, of course, is represented by a nucleus and electrons and protons and how they revolve around one central place, right? How they all interact with each other. And so this next feature actually is Event Streams. So Event Streams gives us a way to receive events, filter them, and transform them out of the platform. So it's a brand-new module in 8.3 that allows you to do this functionality. So you might be saying, "Well, Ignition is already a place where I manage all my data. It's a central place to manage the data," right? So, yeah, that's absolutely correct, right? In fact, our first module, our first product, Factory SQL, did exactly that. And used Ignition as the hub to push that data to the database.

21:25
Reese: And so over the years, right, that has grown to include the different items that you see up here. Modbus, Omron, these different devices, DMP3, polling data from a SQL database, bringing in data from web services via Git requests, right, MQTT, alarm notifications, tag event chain scripts. There's a lot that goes on inside of the platform. And so it's become a little bit tricky, right? Especially if you're brand-new to a project, you're getting your feet wet. It's kind of hard to tell where these events originate and how they flow through the Ignition gateway. And so that's the first thing that Event Stream solves is a centralized event management within Ignition. The second thing is getting event data via subscription and not polling. You might look at these devices or at these different ways we get data into the platform and see that we're polling data out of the devices, bringing them into Ignition via tags. We're polling the SQL databases via SQL queries, web services with Git requests, right? But it's all these different polling ways of bringing that data into Ignition. And it hasn't really been until OPC UA and MQTT protocols that we start to get into subscribing to that. For example, with MQTT, you're publishing to a broker, and then we're subscribing to that to bring the data into Ignition.

22:56
Reese: And so that's great, but that was always external to the platform. Event Streams is a way that we can do this internal in the platform as well. And the third thing here is gaining flexibility in how the data is actually used, right? We know that folks out here are using enterprise message busses like Azure Service Bus and Amazon SNS to subscribe to data around their whole enterprise. And we know if we can just get the data up to those layers, then they can do the IT folks, and cloud folks can really do whatever they want with that in a familiar environment. And so just zooming into Event Streams a little bit more here, right, there really are four main parts to Event Streams. So the first is the sources, right, where the events originate. Second would be filtering, where we can filter the events that are processed through this event stream. And then the transform stage is where we can augment that data and provide more context. And then the handler would be where we stream that data out of the platform. So an 8.3.0, the initial release of 8.3, these are the three sources that will be available.

24:26
Reese: Event Listener, which is essentially a way that we can create a script and send events to this Event Stream all around the whole gateway, or around the designer and in the gateway. HTTP, which is a way that we can basically create this event stream as an endpoint that other systems can hit, and then we can process that information. And then finally, Kafka. And I'm gonna get a little bit more into Kafka for those of you that aren't familiar. Essentially, it's a large-scale enterprise messaging kind of platform that allows you to publish and subscribe to data. So that's the sources. So the second stage is the filter, where we can, of course, like I mentioned, filter the events that are coming through this Event Stream. So take this example. So if you have, say, five lines in your manufacturing environment, and you maybe only want to receive events for line one, right? I don't really care about the other lines. I only receive events for that line. Filtering is a way that you can do that. Once that line one is the only one receiving that event, then we can also transform that event flowing through this via live tag data or querying the database, whatever you wanna do within the designer, right?

25:33
Reese: And then finally, the handlers. So the handlers are going to be a way that we can stream data out of the platform, like I mentioned. And upon 8.3.0 release, these are the ones that will be available. HTTP, which of course allows us to post information to another endpoint. The logger, which allows you to log data or the event to the gateway logs. Database, for those of you that have used SQL Bridge at all, right? You know that you can map data to certain columns in the database. Very similar concept here that allows you to stream or receive an event via the source and stream that into a database. And we have scripting, gateway events, gateway messages, and then, of course, Kafka. So those are some of the handlers and sources that will be available upon release here. But there's a whole host of other sources and handlers that we do have planned for this, right? As you can see, there's a whole host of tags: MQTT, Ignition Events. These are just a handful of them, right? But really, what I wanna drive home on this slide is that there are limitless possibilities.

27:03
Reese: We're viewing this as a framework for you all to manage your events inside of one umbrella, right, and then utilize this platform to extend more and more handlers onto your Event Stream. So say you already have an existing event stream, you just plug another handler into that, right, when and if that comes available. And so you can see it's extensible. We can mix and match these sources and which ones come in, which ones go out of the platform. It really allows you to integrate with so many different systems. So, that's Event Streams with a lot of words, right? But you all wanna deep dive into the designer, so let's give the people what they want here. The first thing that I wanted to show in the designer is really just what this looks like when you open it up. As you can see on the left-hand side, there's the event streams. I'll call it a workspace, right? And creating a new event stream is as simple as right-clicking, or there's a little GUI as well. You might have seen that earlier in the tech keynote. But it's very similar with how you create new other items inside of the designer.

28:10
Reese: Then we're met with the source, right? This is where the event originates. So in this specific example, I'm subscribing to a Kafka topic, right? Bringing that event in. Then we flow into the encoder stage. This didn't really make the four main stages I was talking about earlier, because it's a smaller one, right? It's just a way that we can transform the data type. So say you have a JSON or a string; you can convert that into maybe a different data type very easily within this stage. The filter stage here, again, is where we can filter that data that's being processed through this Event Stream. And so, again, going back to that line example, right? Line one or two, or three, you can specify that here, just using the string language that you're already used to within the designer. Then we go to transform, right? Where we can transform this data, as I mentioned, whether that's reading a live tag value or polling data from the database, whatever you want to do with that, you can augment that data before then sending it out to the other handlers there. Once the transform stage is done, then we're going back into yet another encoder stage.

29:24
Reese: So, again, you can encode that data type into something else, and then we get to the buffer stage. So the buffer stage is really a very unique feature to Event Streams. There's really no way natively to buffer data unless you kind of create a custom application yourself. And so I'll give you an example of what I mean. Say you have a thousand tags, right? Each of those tags maybe has an event change script on them; maybe you are doing something on that change; you're gathering other data, logging that to the database. Each of those inserts to the database is going to be a separate insert statement. So you can see, as you scale, that can become not very performant. This buffer stage kind of allows you to batch all of those together, and it's really controlled by two different properties here. There's a couple other ones here, but the two primary ones are the debounce and the max time.

30:27
Reese: And so, imagine you have event streams coming in. We're going to continue to receive those until we hit the debounce time. And so what the Debounce time is, essentially, it's a rolling window. So every time we see a new event, it resets that rolling window. Receive event, reset. Until we receive all of these events, and then if we hit the Max Time, then we wholesale batch that into the database with one single insert statement. So you can see, this is really great for handling spikes of data, and you can tweak these properties exactly how you want them to be tweaked. Finally, the last kind of portion of the Event Streams here, there's a couple auxiliary UIs I'm about to show too, but the last kind of portion of the event streams kind of flow here is the handlers. So I just have a couple examples, but as you can see, there's a little plus icon there on the right-hand side where you can add more handlers.

32:06
Reese: So you've created this whole stream, and now I can send it out to ten different applications if you want. But just an example here with the logger: you can send the event.data, which is how this event is handled within each of these stages. This is just a JSON structure, so you could absolutely do a square brackets, right, key to grab the value out of that payload. So you could log the whole payload; you could log individual parts of it, up to you. That's a logger, and then the database, again, like I mentioned, similar to the transaction groups, right, where you can see you're mapping essentially the value expression.

32:09
Reese: Event.data and curly brackets item count, or square brackets item count, to column name one, or column one. So that would be how you can kind of interact with the handlers there. Now, like I mentioned, there are a couple different auxiliary kind of UI spaces here. This one's really nice to be able to handle errors gracefully. So this thing can handle thousands of events in subseconds. So if there was an issue that happened to one of those last night, like, how do I get to be able to find that information and debug that? So error handlers will capture any errors that happen within the handlers, yeah, any errors that happen within the handlers, and you could then, of course, log that to the database; you could send out an alarm; you can do whatever you want with that. The status page is going to be exactly what you imagine a status page has. Status is on the different stages, right? Events received over the lifetime of this, actually since the last time that we saved this event stream. Max times, min times, averages, average times of how these stages have executed, and so forth.

33:28
Reese: And then finally here, the test mode. And this is actually my favorite feature because, coming from a development background, this gives you a way to actually test this whole event stream without actually having to connect to a source to begin with. Okay. And so what happens here is you can see in that Test Controls there on the right-hand side, you have can specify JSON object and hit run all at the bottom, and you have the test results there across the bottom going through it's a good, through the source, through the encoder, the filter, et cetera. And if any errors were to happen, they would show up here. So that is kind of Event Streams. It's a great way where we can manage all of our events within the designer, and it's one central place and be able to kind of have a cohesive spot to put those.

34:22
Reese: So I mentioned Kafka earlier. And so Kafka is actually a brand new service connector in 8.3 that we'll be releasing. Kafka is an enterprise event streaming platform that's really, it's used by thousands of companies for high-performance data pipelines, streaming analytics, data integrations with IT tools and mission critical applications, really so much more. But by connecting to Kafka, it really opens up a huge ecosystem of tools that have Kafka connectors already. It's a very common enterprise streaming platform. And so we know that, again, if we can just get that data to that level, there's so many other tools that folks can utilize to do what they need to do. So what does this look like in the designer, right? This is what the handlers and the sources, which we've already discussed, looks like. So within the Kafka source, there's actually two different ways that we can subscribe to a topic.

35:31
Reese: And so that would be done by using either a consumer group or a partition. As you can see, there's a couple other settings that you can specify. The partition specifically, the max records that you're pulling at a time from Kafka, and so forth. And then on the handler side, right, on the handler side, you certainly have the ability to publish to a topic as well. And so that's Kafka. That's Kafka as well as Event Stream. So, yeah. I think we're ready to look at another feature there.

36:04
Matthew: Yeah. Yeah. Let's take a look at the last feature we're gonna be talking about today. So, yeah. Is it in there, Reese? Or did you leave it off to the side, maybe?

36:14
Reese: You know what? I do not see anything in here, and that's because I was playing with the next feature here.

36:23
Reese: What do you got there, Reese?

36:32
Reese: We got a super fast car. This thing's got so much power in it. It's got frickin' scissor doors. It's got everything, man. Honestly, as a kid, I wish I had this. Kids are so spoiled these days.

36:48
Matthew: It's a powerful machine. There you go, Reese. All right. So, yeah. So, with this powerful machine, we've got the Power Historian. So, what is the Power Historian? So, we've kind of talked about it earlier, but it's essentially a new time series database-backed historian for Ignition. So, it uses QuestDB as the backend, and it is embedded in Ignition. So, that means no separate installs required. You just go create a new history provider, and it's taken care of for you. It's also built on the new historian API, so it has a lot of those features that were mentioned previously in the last session about native aggregation and all of that.

36:54
Matthew: There's a lot of features, of course, that we'll continue to add as well in the future, but certainly it has a lot already going for it. So, taking a quick look here, it certainly supports partitioning and pruning as you would expect, but it's all handled by the database itself. It uses write-ahead logging, which helps with performance and robustness. It has a native aggregation capability, so the Ignition's no longer having to do that. It's all pushed onto the database itself, which is far more efficient. And as mentioned previously, renaming your paths does not break history, which is pretty critical for anyone that's gone through and had to rename things. It can be a little bit painful, but the new API and the Power Historian certainly address that.

38:24
Matthew: It also supports automatic archiving, where you can detach a partition and move it to a new storage location, which is pretty key for larger setups there. You need to think about your long term; what is your data storage going to look like, and how do you take care of that? But you still want to be able to keep that data somewhere. So archiving it certainly helps out there. But enough about all that. Let's talk about performance. So I went through, and I was able to do some preliminary testing with the current system. And so I threw together something that was just throwing only 4,000 data points per second continuously into it. And of course it was handling it just fine, and I was measuring query time at the same time while running a Perspective session looking at the tag history data, so all in one system here, and then comparing it to what the current internal historian option is, which is SQLite-based, as well as the dedicated Postgres database just for comparison.

39:20
Matthew: So first question, of course, is, was that heavy on the resources? If you have an internal historian running alongside Ignition, does it take up too much? Is there any kind of issue there? And no, the system actually in this test was using just 4% CPU and 700 megabytes of memory. Is actually really low to be able to store millions upon millions of records in a partition like that. So it was actually performing extremely well and still being able to keep up with everything. The next question you might be thinking of is, does it use a ton of extra storage? If we're storing all this data next to Ignition, what are we gonna have to do with that? And no, it doesn't store a lot of extra data. It's historical data, of course, but it's comparable to all of the other options.

40:13
Matthew: So you just have to again, plan ahead for how much storage you need, and it will take care of it for you. And you have now the options to do the automatic detach and migrate the data to an archive location. So it actually helps out there. So you can offload that older data, for example, to something maybe a little bit more slower, discs, or something that's just more efficient for that type of data. But the real question is how performant is it? You know, was it performing well while all of this was happening, even though it's all local to this one in process storing? And of course it was great. Yeah, it significantly outperforms, of course, the alternative, which is SQLite. If you use SQLite for anything more than even 100 data points a second, you'll probably be running into, you know, performance issues because it is not going to be able to keep up. The Power Historian certainly can.

41:07
Matthew: We're talking like milliseconds worth of query time here, querying a tag for raw data over say an hour's worth, so thousands of points, and it was able to just do that. It certainly is comparable to a dedicated database, but yeah, it significantly outperformed SQLite so much that SQLite in the end was taking two minutes just to query data and ultimately failed. It couldn't actually keep up. It had to stop inserting. So if you're looking for that local historian option, but something that will actually be able to keep up and perform, then Power Historian is certainly great with that. And we are constantly adding onto it. So even just this morning I received messages that we've added even more to it. So this is all preliminary, but one of the improvements we've made already, and this was actually asked, I believe, in the last session, is: can we connect to the Power Historian and get data out of it externally?

42:07
Matthew: And so they added the ability to connect to it using a standard Postgres connection, and so you can query the data right out of it. So yeah, you certainly can do that, and we will continually add more improvements like that and improve query times and all of that moving forward. So there's a lot that it does today already, and there's a lot more that it will be able to do. So there's questions about can it store things like engineering units, and the API certainly supports that, the metadata, but as well, Power Historian will be able to support that as well. Support, eventually storing UDTs, things like that, that you would really, really want. So yeah, overall, the Power Historian, it's plug and play; it's designed to be that way. It is performant, and we're gonna add even more functionality in the future, of course. So stay tuned for all that. So at this point, we can open up to any kind of questions for everyone. Mic runners should be running mics down. Yeah. It looks like we've got one at the top already about...

43:19
Audience Member 1: Yes. Cool. So if we take a look at this Power Historian, how can we relate to that, if I compare it with a normal SQL database? Is it capable of storing terabytes of data?

43:40
Matthew: Well, yeah. It's a time series historian. It can record gigabytes, terabytes of data over time, just like you would expect a time series database. It all works as a tag historian. So yeah, are you asking for anything else specific? I mean, the storage size is purely gonna be based off the size of the hardware that you're running, right?

44:03
Audience Member 1: Of course. Yeah.

44:03
Matthew: So that's certainly like the size of the historian.

44:06
Audience Member 1: Yeah. There are no limits, like 1 terabyte or whatever.

44:10
Matthew: Well, yeah. We're not gonna impose a limit. What would actually happen is your partition size would matter, and there's only so many rows you should put into your partition. I believe it's, you know, hundreds of millions. And so as long as you configure the partition size, then those are going to go into new files, and so you can keep storing and storing until you run out of space.

44:29
Audience Member 1: Cool. And you can also set it then that you will not store all that data on your install drive. Your C Drive, for instance?

44:37
Matthew: Yeah. So right now it stores into that local. If you've seen the collections there, it stores into local, but I believe we'll be able to store it elsewhere, but we'll have to get back to you on that one.

44:51
Audience Member 1: Alright, thanks.

44:54
Matthew: The worst case, I was able to do it myself by just mounting the directory to somewhere else, and then I didn't have to worry about it.

45:01
Audience Member 2: Hey. Is Ignition Edge gonna get Power Historian and receive all like full features?

45:08
Matthew: Yeah. So we're definitely testing that right now to make sure it can perform on what your typical edge device might be, like a small embedded PC, but that would certainly be possible. Yeah. And it outperforms its SQLite option, so it's great.

45:24
Audience Member 2: Thank you.

45:27
Audience Member 3: How does Power Historian handle redundancy? Does it synchronize while it's running?

45:33
Matthew: So it currently does not do that. That's definitely something we can evaluate, but yeah, it currently does not.

45:47
Audience Member 4: For the new Forms component, will users be able to submit photos when they submit a form, and for the validation support feature, will that work offline?

46:00
Matthew: Yeah. So the...

46:00
Audience Member 4: Yep. Sorry.

46:01
Matthew: Oh yeah, yeah. Yeah. So there's File Upload components; I believe there's more field options as well. But yeah, you could usually with the File Upload button; it allows you to snap a photo if you're looking for that with your device. But yeah, it would support that. And then the validation, all of that is browser-side, so it doesn't require the gateway to perform that action.

46:21
Audience Member 4: Nice. Is the offline function just for forms, or you mentioned it could work with static views?

46:29
Reese: Yeah. You just have to imagine when you design a project, bindings and scripts transforms. Those are on the gateway side, but the form component has certain features that work, you know, on the browser side, as mentioned. Other components, they're just resources, and so we would download those onto the device so you can navigate around; you can see the images text that you have, but you're not going to get live tag updates while you're offline. So you have to keep all of that in mind.

46:53
Audience Member 4: Understood. And would there be an indicator for whether the app is offline or online to let the user know that their changes are gonna be queued and then forwarded?

47:04
Matthew: Yeah. So with the offline mode specifically, you actually launch into it. It's not something where you would temporarily revert to offline and then it would auto-reconnect to online and back and forth like that. It is, you would go launch it in offline mode and you are in offline mode, or you go launch it online.

47:24
Audience Member 5: For the Kafka streams or for the Kafka integration, is there gonna be any support for consumer groups to like ensure that a certain Kafka message is only processed once by a consumer?

47:38
Reese: Sure. Yeah. So right now, the way that you do that is by the offset of the Kafka topic. There are definitely plans right now to for... Basically, what you're saying is an acknowledged message for that source, right? So right now that is not something, but it's definitely something that we are planning on putting into that.

47:54
Audience Member 5: Okay. Also, what about schema registry?

47:57
Reese: I'm sorry?

48:00
Audience Member 5: Schema registry?

48:01
Reese: Schema registry? I'm not really familiar with what you mean by that.

48:06
Audience Member 5: Okay. It's basically a framework for Kafka to define what a payload looks like. Like, basically, if you define a proto buff for a certain topic, it's a way of having a centralized store of saying, you know, what payload should be produced on a topic.

48:24
Reese: Okay. Yeah. I couldn't answer that one off the top of my head, but I could certainly connect up with me, and we can chat about that for sure. Do we have any up, up in the balcony there?

48:34
Matthew: There's one up there.

48:35
Reese: Yeah. Looks like one over there.

48:37
Audience Member 6: Yes. One more. So with the Forms component, does it also support adding additional views in there? Your own created views?

48:45
Matthew: So the Form component is a component inside of it. It doesn't have an embedded view field type. The problem with that is then we would have to figure out what your specific view would be doing, and so it would probably break the functionality of it.

49:01
Audience Member 6: Right. Makes sense.

49:02
Matthew: But you could always put a view alongside it and still... It's still a component.

49:08
Audience Member 6: Yeah.

49:14
Reese: Yeah, right here.

49:15
Audience Member 7: In a previous keynote session, it was listed that you can poll up to like 1.8 million record in one second or something. So how was the performance on a GUI side if we are pulling that kind of data on a history trend?

49:32
Matthew: So that I believe was ingestion rates. I think it was like 1.4 million a second. And so that is literally what the database could support on a performance system. Querying that back, I mean, 1.4 million data points, it's... That's a lot of data, but that's not what that graph was showing, but you can certainly query. I was querying millions of data points, and it was taking maybe a hundred millisecond, maybe 200 milliseconds, to query through all of that. So it is performant, but again, it is still preliminary, so we'll have more numbers, of course, later. All right.

50:07
Audience Member 7: Any change in a trending package?

50:14
Matthew: Any change in like trending overall? This is all standard historian. It all works with the same components, so there was no change with the trending there. You do get the native aggregates, but the functionality should be the same. The end result's the same.

50:25
Reese: We'll do one more question here. Yeah. Right over here.

50:33
Audience Member 8: Yeah. Alright. So talking about offline mode, when going online, when two or more upper people are, make changes to the same, let's say, talking about a database field, what about conflict resolution?

50:53
Matthew: So the...

50:53
Audience Member 8: Last in wins, or is there gonna be a mechanism to solve these conflicts? And on top of that, what if let's say that I'm talking about a database table and what about... What if the schema changes when the device was offline? How are those conflicts are gonna be resolved?

51:18
Matthew: Yeah. So what would happen in that case is you have your package, your data there that would get sent up, it ends up in your session handler, that special Form component submission event handler. And it's essentially gonna be a bunch of data that's gonna be provided to you. So that form component doesn't send you; I have, you know, this column of data. It sends you, here's my essentially JSON package. Your handler at that point, if the schema had changed, it would be up to you to fix your script. And at that point, the new data coming in later, as long as you can interpret it and understand it, if that part of the data didn't change, you could send off a query to insert that and that would be fine and it would be in the order that it is received. So if you insert and then insert or if you do an update and update, that last update would override it. So that would be part of your handler logic.

52:10
Reese: Alrighty. Well, thank you everybody for coming to the second session here. Really appreciate you coming out.

Hear from a panel of industry thought leaders and experts as they explore how utilizing data and technology can inspire new ideas, open new opportunities, and drive digital transformation efforts in industrial organizations.

Transcript:

00:04
Don Pearson: So welcome everyone to our panel discussion with the Industry Panel today. The focus is innovation and transformation in industrial organizations. And I think we got a really good panel. I had a chance to meet with them all yesterday and today, and just to get a little sense of what kind of things we're gonna cover. So I really appreciate the opportunity to be the moderator today. My name is Don Pearson. I'm with Inductive Automation, and this is always one of my favorite panels of the conference. First thing I'm gonna do is introduce each of the panelists, and then I'll go back through and have them each give a real better introduction of themselves and a little bit about their company and what they do and how they're actually engaged with Ignition inside their various activities and organizations. And then I have a bunch of questions.

00:50
Don Pearson: We have some seed questions and things, but we also have runners. And really it is your opportunity to ask questions of any panelists. I also noticed in our discussion yesterday, some of the panelists started asking each other questions, so that's open, fair game for that too. Just wanna make this interactive and really a useful time for you to sort of see what they're up to and how it may relate to some of what you're involved in. So first off, I'm gonna start to my right and introduce David Lam. He's the Business Development Director of Vertiv.

01:21
Don Pearson: He's a motivated and detail-oriented professional and a strong communicator and collaborator who thrives in dynamic environments. He has a passion for innovative solutions, a solid sales and business development background in EPMS, automation and control systems, and two years of Ignition experience. His dedication to continuous improvement, learning, and growth has helped him foster strong team dynamics and networks, and he's excited to see how his industry transforms through innovation. So please help me welcome David.

02:00
Don Pearson: And to his right is Trevor Nichols. He's an Electrical and Controls Engineer at Fermi National Accelerator Laboratory, where he designs and supports control systems for the cryogenics on particle physics experiments. Inspired by best practices found in industry and other laboratories, he developed a library of function blocks for PLC programs with corresponding UDTs, templates, and popups for Ignition, providing an object-oriented framework for control systems design. This approach has been implemented on newer experiments that employ sophisticated liquid argon cryogenic systems to study neutrinos. Now, I learned a little bit about neutrinos earlier today with Kevin. Maybe some of you already knew all about it, but we learned a little bit about it earlier today. It's a class of elusive fundamental particles, and it was a presentation as a Firebrand Award winner that was talked about earlier. Very glad to have you on the panel. Welcome Trevor.

03:01
Don Pearson: To his right is Dan Stauft. He's the Director of Operational Technology for SugarCreek. He spent the first 21 years of his career in manufacturing engineering for automotive assembly plants where he specialized in process automation, data visualization, and analysis. In 2013, Dan was hired by SugarCreek. It's a large privately held food manufacturer, and he was hired to lead their Digital Transformation. Over the past 10 years, Dan has led a team of engineers who utilize Ignition to enable decision makers access to real-time production data and historical analytics. In 2017, SugarCreek won a Firebrand Award for their initial MES project, which monitored six manufacturing sites. Currently, SugarCreek has over 20 Ignition gateways and edge tag providers that monitor over a quarter million tags and host over 30 projects utilizing both Vision and Perspective. All of SugarCreek's Ignition development has been done and completed in-house underneath Dan's leadership. Please welcome, Dan Stauft.

04:12
Don Pearson: And to his right is Becca Gillespie. She's been the Managing Director for Energy Systems Network since 2023. Prior to that, she worked as the New Products and Services Lead at Duquesne Light Company, the electric utility for Pittsburgh, Pennsylvania. Before that, she was Sales Director and Product Manager at UniEnergy Technologies. It's a low battery startup in Washington. She was also an Energy Analyst at the Federal Energy Regulatory Commission, and a Production Engineer at NASA. Becca has a Bachelor of Science and Engineering degree in Mechanical and Aerospace Engineering from Princeton University and a Master of Science degree in Public Policy and Management from Carnegie Mellon University. She also holds a patent for a nitinol valve for in-space propulsion systems. So please welcome Becca.

05:12
Don Pearson: To her right is Dick Willis. He was educated and trained for 30 years to be an industrial software tool builder from PLC-based control systems to OEE monitoring systems to full-stack MES in an automotive factory. He helped create the OEE software engineering services company after that. The software platforms they use range from RSLogix, Visual Basic, Wonderware ArchestrA, .NET, and now Ignition. He points out that he's not yet certified but working on it. So that's good. Thanks. But working on it. At Trane, his responsibilities include connecting legacy equipment to their data network and creating tools that collect, monitor, alert, and notify and escalate to reduce the amount of time spent searching for data so that the time can be spent problem solving and making changes instead. Please help me welcome Dick.

06:10
Don Pearson: I do wanna start by, I gave an introduction to a little bit of their backgrounds, but I've asked each of them to talk a little bit about what they do, where they work, and how they're involved with Ignition, and there's a lot of people at different states of the journey, and I was really pleased also when Becca could join us because she works in the public sector, but they work with a lot of manufacturers in Indiana and I'm very excited about the program they're doing. There's another session on it. You'll be with Benson, I think tomorrow, but we got a variety of talent here. So with that, David, I'm just gonna start left again and give you an opportunity to talk a little bit about what you do, what you're excited about it, how's it innovative, how's Ignition fit into it?

06:51
David Lam: Sure, sure. So good afternoon everybody. So David Lam from Vertiv. Originally, I spent, prior to my time at Vertiv, I did 10 years at Schneider Electric in the software business and Ignition was a very, very big, it still is a very big competitor to Schneider. So I came over to Vertiv to see what this is all about as they've been using it for the last five years. So Vertiv is a OEM manufacturer of MV, LV, and bus duct electrical equipment. And as part of that, I lead the BMS and EPMS controls and automation business globally. So we primarily deliver into enterprise and data centers. So we take everything from the source, i.e., renewables and utilities, and we deliver all the manufacturing switch gear into data centers. And then we overlay the BMS and EPMS solutions on top of that to essentially make the invisible visible so we can control, analyze reports. And we predominantly use Ignition now as our go-to platform.

08:09
Don Pearson: Good. Thanks. Good introduction there. Trevor.

08:12
Trevor Nichols: Hello. I'm Trevor Nichols. And so I work at Fermi National Accelerator Laboratory, which is United States' most prominent lab for particle physics research. So my background is in electrical engineering. So before I came to the lab, I actually worked in aerospace for 10 years working on electronics for the Boeing 787. So then I came to the lab as a controls engineer. And so I work on control systems for the cryogenics, primarily on our neutrino experiments. About five years ago, I was introduced to Ignition because it was used on a dark matter experiment that a colleague of mine was collaborating on.

08:58
Trevor Nichols: So when the pandemic came along, we all got sent home to work remotely and there was sort of a lull in our work. And so that was when I really got to work on trying to build something that I'd be able to use across multiple experiments. So I started building libraries both for our PLC code and on the Ignition side. So a function block instance on the PLC corresponds to a UDT instance in Ignition, and those are strictly one-to-one. And so this library, this framework for developing control systems, I've now been able to implement it on three experiments, and we have a couple more on our roadmap. So I'm looking forward to using it on a even bigger project.

09:42
Don Pearson: Great, Trevor. Thanks. Dan.

09:45
Dan Stauft: Hi. Dan Stauft. Excuse me. Happy to be here. You know, as Don said, for the first 21 years of my career, I was with General Motors Toyota Nissan, which has been doing what we're doing, you know, for the past 30 years. And learned about lean manufacturing, data collection analytics. As he said, I joined SugarCreek in 2013, and quite frankly, they didn't have a job title for me. They just knew that I could do something. So my first job was to write my job title. Shortly thereafter, we were looking for a machine data collection system and I had 10 different, Don loves this, I had 10 different applications we were looking at, none of which were Ignition. Wonderware came in and gave us their spiel. We asked how much it would cost, they said, "Two million bucks."

10:41
Dan Stauft: We said, "Haha, no thanks." And they said, "Well, if you can't afford us, there's this little startup in California that you might want to consider," and the rest is history. Our first project was an MES project. We put six sites on MES, I forget how many lines it was. It was around 20 lines. That took one person that was me and we tripled our OEE in two years. And it wasn't Ignition that tripled the OEE, it was Ignition plus a continuous improvement group, which composed of one guy who went to all of our sites and taught them how to identify opportunities, break down problems, identify solutions, implement countermeasures. So that pretty much paid for itself. I mean, I think that probably would've paid for Wonderware. When I joined the company, we were doing around 300 million in sales. Last year we did 1.2 billion in sales, and that was not through growing plants. Some percentage of that, probably 30% was growing plants. It was from our OEE improvement and tripling our capacity.

11:55
Don Pearson: That's great. And just a point for you and for David. You guys, they are wearing Ignition socks, so they get extra credit for wearing their socks today. It wasn't a requirement to be on the panel, okay?

12:07
David Lam: They match my shoes.

12:10
Don Pearson: Becca.

12:10
Becca Gillespie: Right. Thanks Don. Yeah. Thanks everyone. Yeah. I work for Energy Systems Network and we're a consulting shop that works, as Don mentioned in the public sector working with the state of Indiana to help them implement energy-related projects. The particular program that brought us to working closely with Ignition is called Energy Insights. And the purpose of that is kind of dual goal. On the one hand, it wants to help small-to-medium manufacturers just take that first step into their digital journey and start that first pilot program. We happen to say that pilot program should hopefully have something to do with energy, but we really let them be a little bit free there. And then the second goal is to expose them to their energy consumption and start them understanding how they may be able to use energy efficiency measures or data collection measures to improve their energy... To decrease their energy consumption.

13:07
Becca Gillespie: We do that with... We give each of these manufacturers basically hardware, which is our partner, Opto 22, which I'll be speaking with tomorrow, software, which no surprise is Inductive Automation. And then about half of the grant goes towards time with an integrator because we understand small-to-medium manufacturers can't necessarily use something out of the box. Everyone's processes are so unique that they actually need time with that integrator to develop it. And so basically the goals at the end of the program, what the state wants from each of these, is that they just have the capacity to take the next step in their digital journey, whatever shape that might mean. So we just want them to see that ROI so they can say to their boss the next time they want to actually pay for it themselves, "Hey, look at this pilot project."

14:04
Becca Gillespie: "Here's something we did and it had an ROI and now can we invest in the next opportunity?" And we also want them to get that sort of on-the-job training, which in Indiana's opinion, is kind of the best way to train a manufacturer. By letting them do a thing. So that basically brought us to Inductive Automation. I mean, there's a lot of software out there that can take energy data and zoink it to the cloud and give you energy dashboards, but that's not what we wanted. We wanted something that was scalable, modular, reconfigurable, all the buzzwords to say that, you know, this is your beginnings of your smart manufacturing platform, and yeah, you're starting with energy, but you can do anything. So we thought Inductive Automation is a great fit for small-to-medium manufacturers and it's a great fit for being scalable. And that's really what we wanted to give them to get started.

14:58
Don Pearson: That's great, Becca. Okay, over to you.

15:00
Dick Willis: Yep. About five years ago is when Trane Technologies divested from Ingersoll Rand and there are 50 factories. I work for the residential and the Thermo King factories now, and what we inherited was each of the factories had a wide range of thickness of their SCADA layer. Some machines were still not connected to the network. Some of the engineers on site did have Ignition skill sets and built some pretty significant things. One of our sites had a Ignition developer who'd been doing it, you know, for 10 years and it was his full-time job. Most of the other sites didn't have that experience, though they had an engineer who was dabbling in Ignition on-the-job training, did it as he, you know, found, you know, time and availability. But even then, in the first couple years of that development, we had some really good successes.

15:48
Dick Willis: We put in Sepasoft to two of our plants to monitor OEE. We then let the engineers develop their own faceplates for some of their equipment. And one of the... And there are two successes that came to mind, where in one of our machines was monitored by Sepasoft, the operators were putting in notes about what was the problem with the downtime. And one operator was pretty fastidious about that. And she was putting notes that says, "I'm down because I don't have any empty carts to put my material in when I'm finished." Nobody knew that. And all of a sudden we realized that a lot of these issues that we were running into and nibbling at us were productivity and keeping our OEEs low, were things we could easily solve. We just hadn't seen it. So again, making the invisible visible is a big part of it.

16:32
Dick Willis: And same with one of our sheet metal stamping presses. An engineer made a faceplate for himself to keep track of what the photo eyes were doing over time. Realized that again, one of his outages that was eating his lunch on that machine was because a photo eye was tripping a little bit earlier than everybody thought when they wrote the PLC program. He fixed the PLC program, availability went back up, and all of a sudden we're heroes. So we had really good local success, and we were getting more and more need for Ignition, but we didn't have enough local, you know, site developers. And we're still struggling with that. Our journey is now to go past, just thicken. We wanna uniformly thicken our SCADA layer so that everybody has OEE that's geared towards problem solving. To Dan's point, it's not just OEE the number, it's what it feeds to your problem-solving team.

17:21
Dick Willis: That's the key. You know, we don't pretend that having an OEE system gets you better numbers. You have to have OEE system that's credible that your people will then use. And then we also have a SCADA community that we're building. We have a SCADA governance team that we're building. So again, we can all have uniform capabilities. One of the important things we talked about this morning in the keynote was the value of this community. This is one of the reasons why I think we made a good choice when we picked Ignition for Trane Technologies, is because of the breadth of the community and all the help that we're currently getting. Now, our main challenge is to take this monitoring system, which has been showing a lot of good local results to make it uniform across all of our plants, and then take advantage of the alerting and notification capabilities to say, "I don't want you to watch the screen. I want you to go do your work. The SCADA system will tell you when the pattern you're looking for is a problem. So do your work and let SCADA help you as much as it can." So we expect that that's gonna yield even better results for us in a very short period of time once we get that uniform layer developed.

18:26
Don Pearson: Great. Thanks Dick. I think I'm gonna start with the questions. Maybe come back to you Becca. 'Cause yours is a little bit unique also. Many people already know this, but I learned it when I started going to Indiana when the program was first getting started. There's almost... Is it approaching 10,000 individual manufacturing companies in the state of Indiana? Yeah. Kind of a busy place.

18:48
Becca Gillespie: I don't know how you measure it. Yeah.

18:51
Don Pearson: But why small and medium business? We talk a lot about the first step, the journey, and Travis and Kevin were talking about the sophistication levels of deployments that you start someplace and you wanna go somewhere. Tell a little bit about why the target of the small and medium business, how it's going, what are some of the challenges of getting that entrance point going with those folks?

19:17
Becca Gillespie: Yeah. I think the entrance point for small-to-medium manufacturers, I mentioned a little in my intro, but it's a real one. It's that first cost hurdle. It's that ability to describe to a CEO of a company that's been running and running well for 50 years and manufacturing parts well for 50 years that looking at data can help them save money. That can be really difficult to explain. It can be difficult to articulate without a lot of hand-waving. And so the state says, we see the writing on the wall. Smart manufacturing, SCADA systems, data collection, this will keep you competitive. A lot of people within the small-to-medium manufacturers also see the writing on the wall. This is what's gonna keep us competitive. But they have a hard time getting that first investment and getting people to sign off on this kind of difficult-to-explain-and-it's-different-in-every-plant value proposition of data visualization, data analysis, and then, again, notifications. It's hard to know what those gem of a use cases are gonna be until they've happened. So that's one thing. But it's more than just money. I think a different problem in the small-to-medium manufacturers is that information gap.

20:31
Becca Gillespie: It's a very busy space out there. I understand that, frankly. I feel like I'm the filter for them of all of the IIoT and software and SCADA solutions that are there. And I feel that burden on myself, and I'm glad that I can take that off of their shoulders for this first implementation, 'cause there's nothing better than getting your hands dirty, starting a project, getting the pilot going, and building from there, especially with a reconfigurable or open platform like Inductive Automation that you can continue to use in some ways and bring on other pieces. But that's the beauty of it, that they don't have to dig into the world of all of the vendors at first. They can just get started with something. So we think that's a really good one. And then they also have the issue of they're starting to... Need to understand their energy, 'cause energy prices are going up. A lot of big manufacturers are levying greenhouse gas requirements on them, and they definitely don't know where to get started.

21:37
Becca Gillespie: It's coming from above. They hear this new accounting principle is now greenhouse gases, and they can't necessarily measure it. So they get this feedback, and the Indiana state says, "We wanna help you with this. We know this is important. We know it's hard to justify. We know it's a difficult space to get started in. But we think that if we can just give you this pilot, you'll be able to grow and scale and figure out, chart your own course, essentially, from there."

22:05
Don Pearson: Thanks. Thanks. I wanna turn to you, 'cause David, you guys are doing a lot of innovative things with 3D view, Digital Twin, things with the technology. Can you talk a little bit about that journey, what you think about that, where you think it's going, both in terms of making products and in your products... I mean, the manufacturing of it and the product itself?

22:19
David Lam: Sure. So Vertiv. We entered the Discovery Gallery this year. Vertiv has quite a wide range of manufacturing facilities. So we perform self-delivery with Ignition in our facilities, as well as being a systems integrator and selling to our clients ourselves. So first of all, we adopted Ignition in our own facilities, 'cause we have quite a wide range of manufacturing. Everything from heavy industrial electrical manufacturing of switchgear, right down to sensitive batteries and UPSs for the mechanical side. So we first deployed that, and a big thing when it comes to trying to cascade the right message and the right solution of what we can offer as an organization for something that inherently, electricity is invisible, is quite a hard sell. And no matter how many presentations or slides that you give out, nothing is better than actually walking the talk and seeing the true simulation or a demo. So we showcased our manufacturing facility using Ignition. We used Ignition Edge in all of our facilities, and it goes up to a main Ignition head-end using Perspective.

23:36
David Lam: From there, we were able to use it as a data center demo to serve our data center segment as a main client. From there, obviously, we live in a world that's extremely digital now. A lot of this is done remotely... Meetings, video conferencing, Teams, Google Meet, is all done remotely and virtually. So some of the innovations that we started to see in the video, we are able to do augmented reality using the Apple Vision Pro. We're able to generate 3D images from CAD images that were already created, and we leverage the designs off of our 3D switchgear models, embed that into Ignition. And then apply it to an augmented reality, and it allows engineers from anywhere in the world to come and test and see the actual device through the goggles and interrogate it and see the reports live. So it demonstrates efficiency, and that innovation going forward is perfect for training and upskilling new talent that's coming into our industry. It's a great way to see things live without having to travel all over the world to do live testing in a factory.

24:52
Don Pearson: Thanks, David. So, Trevor, I'm gonna go to you 'cause I know Kevin shared some of his excitement about what you're doing and where you're going and the whole work with Fermilab, but how do you, I mean, that's a unique application. How did you go about selling the idea of Ignition or a newer technology, if you will, to address some of the challenges you had with argon, with whatever the difficulties were in getting things going?

25:16
Trevor Nichols: Yeah. Okay. Yeah, I can speak to that. So I'd say one of the keys is being objective about it. I mean, it's great to walk in and be really enthusiastic and tell them, "Oh, it's great" and everything, but if you have some data you can point to, that's better. So in our case, we kind of came up with a set of criteria that was the basis of comparison. So we looked at Ignition and we looked at a couple of Ignition's competitors and we also looked at a homegrown tool and we came up with a set of criteria. We were looking at things like, is it commercially available? What does the support look like? Is it object-oriented? Is it modular? What does the licensing look like, the cost? And so we were able to compare different platforms on this basis and then I got it all documented in an engineering report that then gets released into our engineering document repository. So that way, it makes this comparison readily available 'cause you can imagine this conversation is gonna come up over and over and over again, you know, "Why do you wanna use this new product? We've never heard of this."

26:35
Trevor Nichols: So this gives you an easy reference, something that you can go back to and easily point to that, you know, this is documented, it's been reviewed by, you know, some of our subject matter experts, stakeholders. And then I also wanted to kind of jump off of something that David said 'cause David was talking about demonstration, which that's also really important. So in my case, I built a small demo project in a simulated environment that gave us enough confidence to use it on a smaller experiment. And once it kind of proved itself on the smaller experiment, then we were able to take it to the big scale and use it on something really big and something that gets, something that the lab has a lot more publicity for. So that was sort of the progression of it.

27:28
Don Pearson: That's great, thanks, Trevor. So, Dick, I wanna move over to you with a question that relates to, I know that you mentioned when we chatted yesterday, the day before yesterday, that there's, you're at a stage of the journey, not at the level that, say, Dan is with SugarCreek in terms of the 10 years of history, but you're also using internal and external sources, so you're using integrators. You had some comments on that that I think are worth maybe sharing of how do you make decisions or how do you balance who you work with outside, who you work inside, how you build your individual team, where does that balance lie?

27:56
Dick Willis: Right. And that is a significant challenge, right, 'cause we, Ignition is the kind of toolkit where you are expected to be able to launch it in the afternoon and have something running the next day. And that's true. I mean, like I said, that faceplate that the engineer built, he built it by himself, for himself, for his own purposes, and it worked great and yielded results pretty quickly. One of our concerns, though, was the next guy, right? How is he gonna hand that off, or is it something that we could take that pattern and replicate system-wide? And there was a lot of doubt about that. We'd already, as everybody in the building knows, you inherited stuff from the previous guy and you don't know how it works, and if it breaks, you don't know who to go to, and maybe he's dead, maybe he's gone, you know, there's a lot of things that get in your way. Or you wish he was dead, one or the other.

28:43
Dick Willis: I wish he was dead. So we pretty quickly realized we had to have two things, a SCADA community that was an internal resource for us inside the buildings, and then a SCADA governance group, which was trying to say, "Have you thought about this? Here's your standard, you're not quite standard, what's your game plan to get to standard?" And that also highlighted we didn't have enough subject matter experts in the building. So we are still looking for a way to increase the strength and depth of our bench. So I'm here this week also trying to figure out who can partner with us, who can show us what good looks like, but the goal is, I'm gonna say goodbye to you in a couple years 'cause you've taught me, and now I can design and maintain on my own.

29:28
Dick Willis: That's our goal. Whether it's practical, still to be determined, but that is our goal, is to become more self-sufficient than we are right now. But it's a wicked balance. We've been doing this for a few years now, and there's still a backlog of needs that we haven't finished.

29:44
Don Pearson: Sure. Yeah. I wanna reiterate what I said at the beginning, and I'll have to have some help with being able to see, but this is your time, I wanna give folks a chance to get acquainted with you a little bit, but any questions you have, we have folks running with mics, and you raise your hand and they will see it probably before I will see it. Also try and catch people up in the top. But any questions you have, raise your hands, a mic will be there, I'm gonna ask Dan one, and then I'll shift over to somebody in the audience who wants to ask one.

30:12
Don Pearson: But before, I wanna put you on the spot. I know a few years ago, about the time you won a Firebrand, we did a more extensive case study on SugarCreek, and there were some pretty good... We had good interviews all the way from your CEO all the way down to finance people and stuff, and I think one of the things that's really important about Ignition is, how do you have the justification throughout the organization for ROI? You mentioned some numbers on OEE and OEE change, for some reason or another, those people were all ready to go on camera and say how cool Ignition was, and they all have different metrics they're looking at. So how do you work up and down the organization to get the agreement, and what metrics are you using, and how are they going?

30:48
Dan Stauft: Yeah, for us it's pretty easy, because SugarCreek, even though we're a large food manufacturer, we're owned by one guy, his name's John. I saved John a ton of money in the first two years of the project. So it was pretty easy, but when we started out, I learned quickly that... My background, in the automotive industry, everybody at all levels, from the line operators all the way up, they are drilled with continuous improvement teams, so you've got a very, very well-trained audience. At our facilities, we didn't, and we hadn't had to. It's a 59-year-old company, second generation, now run by the third, but they were running things like when they started in 1965, they didn't realize what the potential was. So what we did is, we taught them that if we did an initial measure, and we were meeting our standards, and our standards were dead wrong, and we proved that right out of the gate, because our standards were based on tribal knowledge that had been passed generation to generation to generation, not based on the capability of the machines that were on the lines.

32:08
Dan Stauft: They'd upgraded the machines, but they hadn't upgraded the standards, but they were still held to the same standards, so they built to the standards. Easy, right? So I took a line where our productivity sucked, I put Ignition on it, and now everybody could see that our productivity sucked, and they could see that it sucked in real time. I love saying that. So the next phase, and it happened very, very quickly, 'cause we said your OEE is 27%, and they said, you know, they didn't believe it. But we were based on what the capability of the machine is on that particular line. You know, it's a microwave bacon line, and the bottleneck's the microwave, and a certain number of kilowatts can only cook so many pounds of bacon. So we did the math and said, "For this SKU on that line, we should be able to produce this much," and they said, "You're lying." And that's when Craig came in. Craig came from Conagra, and Conagra's got a good automotive style of thinking. So he taught the team leaders.

33:13
Dan Stauft: He created something called the SugarCreek Performance System that dovetailed into our Ignition platform to where we showed the data, they reacted to the data, he trained the operators, and then he got a daily cadence of meetings going. As soon as you start seeing incremental growth, we went on one line, the first line we did, in two months, we went from an OEE of 28% to 78%. So in two months, with no, I mean, very little investment. And then we did it across every other line in the company. So it's really easy when you start saving that amount of money, especially when it's all coming out of one guy's pockets, what John would say is, "Well, if we can't change the culture to match a continuous improvement culture, we will change the managers and get managers in that will agree with a continuous improvement culture." So we've been so far along in this that we're doing just super oddball stuff. I've got a great group of programmers with me now, ask me, and I'll tell you all the cool stuff. We don't have time.

34:23
Don Pearson: Yeah. Well, good. Thanks. So I appreciate some of that detail. That's great. There's got to be a question out here. Who's got the microphone first? Alright. Right here. Yeah.

34:35
Audience Member 1: Yes. Hi. This question has kind of become, I guess, an annual tradition for me. But whether it's Ignition-related or digitalization, many of the presentations today and what the panelists have talked about involve a lot more connections between the plant floor and the business level. And so I always ask, you know, what kind of cybersecurity best practices are each of the panelists using? And, how do those dovetail with the connections you made?

35:03
Don Pearson: Your annual question. That's good. Appreciate that. So everybody doesn't have to answer that, Becca, if you're not dealing with that with your customers at that level. But let's get a couple of answers to that. We'll start over with you, Dick.

35:22
Dick Willis: Yeah. I don't know how detailed you want that question, but this past year, all of our sites in the North America region have gone through an OT security segregation. So we now have VLANs. We now have firewalls. We have Ignition and its related pieces in what we call the DMZ. We've gone through a thorough review. We have appliances on the network that are scanning and detecting and sniffing, notifying us when rogue devices have been added to the network. So we've gone through a lot. It's been a lot of engineering network, you know, the secret network where the guy runs his own cable. We got plenty of that and it's gone. So we think we're much more robust, but it's still a journey for us as well. Big, big, big effort.

36:03
Don Pearson: Cool. How about you, David?

36:08
David Lam: I guess we're a bit unique here 'cause serving the data centers, they tend to look after the cybersecurity themselves. So they're very selective. They deal with a lot of the Ignition partners here that are here today, Phoenix Contact, Moxa, etc. So it goes through rigorous testing by those hyperscalers directly themselves. So we're quite fortunate that we don't have to really get too much involved in the cybersecurity pieces. They kind of take on that responsibility themselves.

36:33
Don Pearson: Okay, cool. Trevor?

36:37
Trevor Nichols: So I'm gonna, you know, Dick mentioned the VLANs. That's something that we definitely put into practice. I'll say I'm a bit out of my element, so I kind of depend on our IT folks for that. But I know that we lay out a number of different networks that have different levels of accessibility. So I mean, we definitely got to keep the PLCs safe. And so that sort of, since that's what's actually running the system, and so we use Ignition for monitoring and intervention, not for active control. So you could actually turn the computer off and the PLC will keep the system running. So that's why the PLC has to be the most protected. But we do have a fairly thorough cybersecurity review where they go through things, looking at isolation. They're big fans of multi-factor authentication. And so those are some of the things that we employ in our system.

37:38
Don Pearson: Okay. Go on Dan.

37:40
Dan Stauft: You know what those guys said. Yeah, so we're micro-segmented VLANs. You know, IT takes care of the majority of our security. We're pretty secure. At our latest plant, Cisco Advanced Design Services, whoever the hell they are, they design the entire system. And it's to the point where it's really, really, you can ask Nate, it's really, really difficult to get people into our network.

38:11
Don Pearson: Cool. Alright, we got another question out here somewhere right there. Do you have a mic? Perfect.

38:17
Audience Member 2: Hi, my question's for Becca. Dealing with such a broad range of end users, have you been able to quantify any trends and improved energy usage over that kind of portfolio?

38:32
Becca Gillespie: Yeah, it's been a pretty broad range. I don't know that I can give a specific number. So we would say that the thing we look for in our screening, actually, people often ask, which industry vertical do you most look for? And we don't look for an industry vertical. We look for a human that is the right fit to be a champion, a project champion. So the way we screen it is that. And when we have success, and when we don't have success, it's usually that that person has left the company or disappeared or got pulled into a different task. And so there are cases where that has happened. And then when we do have success, it can range really broadly. So there'll be cases like the sort of one-time savings where a big, there was an over-voltage event from the utility side, and all of the machinery was at risk, and they were able to unplug it and save it. And how can you, you know, quantify that? And then there's others where we'd hope that they're gonna use it for energy efficiency.

39:40
Becca Gillespie: And as a huge energy geek, I hate this, but a lot of times I use it for preventative maintenance instead. But, you know, they quantify that in a totally different way. So they'll say, "Hey, you know, actually, I saw the amperage going up on one phase compared to the others. And it means that one of the coils is bad and my motor," etc., etc. So sometimes the savings are energy-related, sometimes they're not. And even when they're energy-related, they can come as these huge chunks of change versus, I guess, the more sort of run-of-the-mill, which is justifying an investment in a new energy efficiency piece of equipment. So like understanding how much their new line saves versus their old line, or kind of watching a degradation over time and being able to like foretell and forestall those sorts of energy efficiency degradations over time, which is the beauty of data and... Trending it. And so, yeah, I mean, but roughly, oh, yeah, we would roughly say they sort of span the whole gamut of what they work on, but they typically can save some energy as well as sort of implement some kind of other manufacturing use case that is of interest to them at that time.

40:50
Don Pearson: Thanks. Dan, you wanna say something?

40:53
Dan Stauft: Yeah, so somehow we made the cut to get included in that program.

40:57
Don Pearson: You guys are our customers, so.

41:00
Dan Stauft: Right, so our biggest plant is in Indiana, it's about 400,000 square feet. It's ammonia refrigeration, wastewater systems. I think our power bill last month was $360,000. So we are in the program, and we're just now getting around to doing the energy part of the program. We obviously didn't use the integrator, and we're using Benson's hardware for something else, but we are now monitoring all 10 switchgear at that plant. We're trending everything. We're working on an AI system to do analytics, 'cause if we can get a 5% save on a $300,000-a-month bill, that's significant. Obviously, we'd like more, but any little bit, it's definitely worth the investment.

41:47
Don Pearson: Sure, thanks. Next question, back there.

41:53
Audience Member 3: Hi, thanks for your time. It was very, very interesting to know. I had a question because over the years, we've been speaking about IT/OT integration, Unified Namespace now. I'm just curious when new plans or new capacities are being put, is there any executive-level talk among the user, talking like a unified business, which is like reimagined, and are we otherwise consistently looking at continuous improvement? Is there a new generation of plants coming up that from a concept level, a different way it's done so that we are not fixing a problem on the legacy systems? Because some of the customers we have met, we've seen over the last 15 years, they have created new legacies because they could have avoided creating the legacy, you know what I mean. So I'm just curious what happens within companies, the manufacturing companies themselves. Is there any executive-level talk around probably reimagining how to put up new plants or some conversations like a unified business, how to look at it?

43:02
Don Pearson: Anybody wanna take a shot at that as you go forward? I guess it's the greenfield world maybe of where you go with plants into the future with all that exists right now, if I understood the question correctly. You wanna say something, Dick?

43:15
Dick Willis: Sure, yeah, we did have a greenfield plant come online over the last two years, and we did try to take some of the learnings from before we did start with Ignition. We started with Kepware and it's gonna become Ignition, and we have an MES stack, and we tried to imagine it from the point of view of problem solving right off the bat. I'm not sure we were always completely successful 'cause we ran into some snags, but it's certainly the approach that we talk a lot about Digital Transformation. It's one of our key milestones for the company. We've got a lot of effort and workshops going on to say how do we make that real even in our existing facilities, nevermind the new ones that we bring online. So I think it is changing, but it's, getting it proven out has been tricky.

44:00
Don Pearson: Okay. Yeah. Okay, any last comment, David?

44:03
David Lam: I think so, certainly in our segment with data centers, everything we do is greenfield, and obviously it's speed to market and getting online as quickly as possible. So where we're seeing now is we embed, we try to embed everything. We create a design philosophy with that client, and they will roll it out pretty much to all their data centers and then data center campuses. So it's speed to market. We can do all of the commissionings. We have all the UDTs specifically designed for that client. It'll roll out with all of the switchgear, with all of the thermals, and all of the cooling, and then they can decide to come and test in person or using the latest sort of innovation that we've been doing with augmented reality. They don't even have to come.

44:50
David Lam: They can just sit. We're talking about developers and people, techies that can be anywhere in the office or in their home, working from home, and do that testing from there, and then the equipment goes straight to site and it's powered up quick, and that's one of the beauties, I guess, of Ignition is the speed to market.

45:08
Don Pearson: We got maybe time for one more question. Is there a microphone in somebody's hand that wants to ask a question out there? Over here. Go ahead.

45:20
Audience Member 4: Hi, and thank you again for all your time and your feedback. Do any of you have any thoughts on the future integration of using an AI or general artificial intelligence in the industry and where that might fit in best?

45:38
Becca Gillespie: Yeah, I mean, I guess I do. I'll just add one to that previous question as well. I think we do try to standardize the tools for small-to-medium manufacturers, which is really bizarre, but we wanna give them all of the same replicatable things but it's the way to meet in the middle between making a bespoke energy system and giving them something scalable that has that. But with respect to AI, I have a pretty short answer, I guess. It's not your first project, and that we learned the hard way. Yeah, it's not the first project. So we do find that looking at the data, sort of getting human eyes on it and starting to have them see and uncover their first findings is really important. But there's certainly a role to play in the future and I'll let you guys, I'm sure you're already using it and finding success there.

46:32
Don Pearson: Anybody else want to comment?

46:33
Dan Stauft: I think probably the, not full-blown AI, but automated anomaly detection is something that is very valuable and pretty reliable right now. Whereas AI models, garbage in, garbage out, it takes a PhD almost to define what goes into the model, what the context is, how it's formatted, what you're looking for, what are the key variables. There's a lot more than just simply saying AI, but anomaly detection definitely.

47:04
Dick Willis: Yeah. We've got a couple of things on the burner where we're trying to look, when people are putting in notes about what's going on with their machines, we're trying to look for a current spike. Like all of a sudden we're complaining about this and trying to use AI to say what's noise, what's signal, and trying to see if we can get a quicker response to a problem that's just now popping up on the shop floor. And we also have some very complicated engineering problems in terms of managing yield. And a lot of what we're tempted to do is just throw everything into the AI and see if it can predict that on Tuesday at 10 o'clock we're gonna have a yield crash. So we're trying some of those things out, but we need a much thicker SCADA layer to be able to get any kind of correlation out of that.

47:48
Becca Gillespie: I mean, I think that, well, I'll just add one more thought. Adding context to the data is so important. And so when you, obviously in my case, if we're doing pilots where there's no context, it's just three machines are being monitored within the system. But it's so difficult to add, and yet it's the only way AI can really learn is with those context layers. Otherwise it can find things that just aren't real. So it can uncover that every Tuesday your machine is breaking down. Well, you know what? The only guy that can run that machine has a doctor's appointment on Tuesday, right? Or it's the most bizarre things because you don't have all of the context in there yet. It's capable, you can get it in there. There's ways to do it, but until you have that, you can't really, you can't always learn all those things.

48:36
Don Pearson: Well, as it often happens, we overran our time, but you guys did great, okay? But we're the only people standing between this group and a little activity at headquarters that they may prefer to this panel. But can we take a minute and acknowledge all of our panelists and say thank you?

49:00
Don Pearson: Thank you.

In this final session of the conference, we'll look forward to what's next. Join Inductive Automation speakers for exciting presentations and an engaging Q&A panel about the road ahead for Ignition's development, the expansion of technical support, and the evolution of Inductive Automation's customer experience.

Transcript:

00:00
Colby Clegg: Well, well, well, well, here we are. Thank you; we made it. We made it to the end, huh? This has been an incredible week. It's so great to see you all here. These are the diehards. And so we are excited to share this last session with you. Over the last few days, we've had so many conversations. We've explored so many ideas, shared stories, reconnected, and really have explored how this community can continue to push the boundaries of automation forward, blending your ingenuity with modern technology, of course, with Ignition as a platform in the middle and binding those together.

00:39
Colby: Okay, but guess what? We're not done yet. In fact, this year, we have something extra special for you, which is why we're doing this closing keynote for the first time. See, over the last couple days, we couldn't pack everything that we wanted into two keynotes, so we've created this story arc concluding this afternoon. If you can remember, way back to two days ago, we introduced you to Ignition 8.3. We talked a lot about the product itself, but we also talked a little bit about the values and philosophies behind it that we continue to try to express through our product.

01:14
Colby: Yesterday, we reviewed the state of the Ignition community and the many, many incredible projects that you are all doing each day. We saw the way that Ignition is being put to use in a very vital way to impact our world. In between, you've seen many incredible sessions, and there've been subjects as diverse as our industry itself. I feel like we've had something for everyone, and I truly hope that every one of you is feeling inspired, invigorated, and ready to go back home and get back to work to create the future today. But how about that word future? We've talked about where we are; we talked about what's going on, but what about where we're going?

01:58
Colby: Well, that's exactly what we're gonna talk about this afternoon in this session entitled, "Where Do We Go From Here?" It's a fitting way to close because after this session, it's gonna be an entire year before we're back together for the first time in a new location. Also, knowing how much all of us leave this conference, so fired up to get out there and do more, we thought it'd be the perfect opportunity, the perfect place to conclude this week's discussions and launch into what comes after today.

02:26
Colby: Now, perhaps you're thinking that that refers to the software, and perhaps you're even thinking, "Now hold on, I just got my mind wrapped around Ignition 8.3, I can't handle anymore." Well, don't worry, Ignition 8.3 is part of it, but it's only a slice. Ignition 8.3, in fact, plays an important step in where we wanna go, and we'll talk about that. But there's a lot more that we want to talk about as well. I hope you've noticed that in everything we present, there's plenty of practical information, but it's built on a foundation of values and principles. And this is so important to us.

03:01
Colby: Steve and Wendi-Lynn Hechtman founded this company to bring their experience as an integration business into the industrial software space that had become transactional and, I guess if I'm gentle about it, just cynical. Now, we, the leaders of Inductive Automation, are committed to carrying those values forward, and we fully recognize the important role we play in improving the industry through our value-oriented approach.

03:28
Colby: We believe that our values make us unique, and they lead us to doing a lot of things in our own way. This has led us to... It's led me to create a little phrase that we've started to use inside of our company called "uniquely inductive." We use this to highlight the things that make us different, the way we do things in a special way, things that lead to an unprecedented user experience, to industry-leading technology, and a dedication to the future. Today, you're gonna hear that phrase probably said a few times, because we're gonna explore some of the unique things that we're doing for the future.

04:06
Colby: First, the software, yes. What Ignition 8.3 represents in the big picture, and most importantly, where we see that picture going. But next, another key product that we offer, support. We've been famous since the beginning for our support and training. And we know that it's a cornerstone of who we are and what we offer to the industry. So I'd like to have our Directors of Support Services come out and talk about some of the important milestones that we have in front of us.

04:33
Colby: Finally, we have a special surprise. I won't say too much about it right now, but I will say that I am extremely excited to finally share it with you because I think that it perfectly represents what I mean by saying that we continue to deliver our values through our products. So that might seem like a lot, but we'll get through it, and we'll make sure to leave some time for everyone's favorite part of ICC, our panel discussion.

05:00
Colby: All of our speakers this afternoon will be here to answer your questions. I don't know if you have any left after all these sessions and conversations we've been having, but we'll see. And it's your opportunity to catch Carl and I on stage together and see what you can throw at us. So we'll see how that goes. With that, let's get into it. Please help me welcome to stage Carl Gould.

05:25
Carl Gould: All right, thanks, Colby. Good afternoon, everybody. Returning attendees of ICC might recognize this as the part of the conference where I get to be on stage and prognosticate about somewhat vague future plans. And I intend to do exactly that. But first, a note about the future of 8.3 itself. So I want everybody to remember that when we release Ignition 8.3, that 8-3-0 will be the first of many 8.3 releases. Just like 8.1, we will continue to release incremental improvements to 8.3 roughly every five weeks using our so-called release train methodology. And these releases are commonly packed with fixes, yes, but also performance improvements, polishes to the UI. And we also use them to continually build the value of the product by adding functionality to the new features we add.

06:21
Carl: So in the case of 8.3, this means things like adding to the Form Component, for example, which has a lot of widgets right out of the box, but there's more widgets we have planned, because in order to make our release deadlines, we have to get pretty strict about defining what is the minimum viable product for release, but then we use the release train releases to expand on that minimum. Take the Power Historian as another example. On the initial release, it's not going to work right out of the box with the redundancy mode, but that is definitely something we plan on adding synchronization for in a point release in 8.3 something.

07:02
Carl: Event Streams is another great example here where we have tons of ideas for new sources and handlers. We've been sitting on a bunch of ideas, kind of waiting for Event Streams to arrive. New ideas for service connectors that will expand the possibilities of connectivity for Ignition. We have plans for an AWS connector that will allow you to connect to AWS, SNS, SQS, and S3 services. We plan on being able to consume OPC UA events and ingest them into Event Streams. I believe we mentioned before that the MongoDB Module is going to be adding support for change stream subscriptions. We're also looking at integrating with technologies like JMS and AMQP. There's all kinds of really compelling ideas to add the functionality for sources and handlers for Event Streams so that you can continue migrating a lot of your applications to be more event-driven and less reliant on polling so that they're more scalable.

08:04
Carl: And looking past 8.3, again, we're going to get back to a faster release cycle, two to three years, we think is probably about the sweet spot for major releases, and we're gonna fix this numbering scheme, but it won't be Ignition XP. I'm gonna hold the line on that one. But hopefully I don't have to ever explain why we skipped a version number again, 'cause that's getting tiresome.

08:28
Carl: Okay, so with that out of the way about how 8.3 is gonna line out, I do wanna get into some ideas of what's in the future for Ignition past 8.3 in the next major version. A disclaimer: just because I'm up on stage here and have a microphone does not mean these are contractual obligations. We may not deliver all these in the next major release, but we're damn sure we are gonna try.

08:55
Carl: So let's start with the platform, as we always do. We spend a lot of time around here obsessing about Ignition as a platform. A huge, huge part of 8.3 was in renovating the platform to make sure it's really well poised and well suited to take advantage of today's architectural deployment approaches. But of course we never finished, so here are some things we wanna continue improving about the Ignition platform, and starting with scripting.

09:18 C
Carl: I was trying to get ahead of this question by putting it on the slides, but I've already answered it at least half a dozen times in the last few days, so oh well. Okay, let's talk about scripting. So we use Python 2 in Ignition, and I get asked all the time about plans to upgrade to Python 3. So a little bit of background for anyone who is not aware. The embedded scripting engine in Ignition is an implementation of Python 2 in Java called Jython. And it is a very powerful and effective approach. You all use scripting to great effect in your applications every day. Python 2 is objectively a great language. If Python 3 didn't exist, I don't think there would be too many complaints about Python 2.

10:05
Carl: The engine itself is very fast, very stable, and interestingly, the way that we've integrated it into Ignition, it allows you to, in your scripts, interact directly with Ignition's object structure because it's using a shared memory, which is pretty interesting and powerful. So if it's so great, why am I even talking about it? What's the motivation in the first place to think about moving to Python 3? I really think that it boils down to two major issues. Number one is that when you go to learn Python, you learn Python 3 by default, 'cause it has been the most recent version of Python for quite some time, and then you come to Ignition, and it's Python 2, and you have some cognitive dissonance there.

10:48
Carl: The other reason, the other motivation, is that you have found some external library for Python and you wanna bring it into Ignition. And these are usually libraries in the statistics or machine learning space, but it could be anything. There's a ton of great open-source libraries out there for Python, and then you bring them into Ignition, doesn't work.

11:09
Carl: So I'm sympathetic to these motivations. I think they are perfectly valid criticisms and... So why don't we just upgrade? Well, there's a few problems. Number one is that Python 3 is just a different language than Python 2, and apparently the Python folks aren't as into continuity as we are because they aren't backwards compatible languages. So if we were to just magically upgrade to Python 3, all your scripts would break, which we think is a bit of a problem. So that's one problem. There's another problem as well, which is that Python is a language, and then there's various runtimes, engines that run that language. And the one we run is Python and Jython. The one that you run externally, what if you were just to go use regular Python, is called CPython. And they're not the same thing. So even if there were a Jython 3 that we upgraded to, those external libraries that you found probably wouldn't work anyways, even though they're both Python 3, because most of those libraries are actually written in C.

12:12
Carl Gould: And then the real reason is that there isn't a version of Jython 3 for us to upgrade to anyhow. So these are all just excuses. But they're good ones.

12:21
Carl Gould: Okay, so how do we move forward? Is this just an impasse forever? No, it's not impasse forever. Here's the plan, so we are going to stick with the current Jython 2 scripting engine in Ignition for the foreseeable future because of backwards compatibility. So we plan on continuing to embed that engine in Ignition so that all your scripts you have now continue to work forever. We have forked this engine; it's an open-source project. We've forked it; we are comfortable maintaining it. It's stable; it's performant. I think it just needs a little bit of a rebranding makeover. We'll call it the Ignition Scripting Language or something.

13:01
Carl: But that's not all. What we wanna do in the next major version is add support for external scripting engines as a new extension point in Ignition. And so what this will allow us and other module authors to do is to gracefully integrate external scripting engines with Ignition, and this will allow us to have multiple scripting engines that could be supported. So, for example, CPython 3, absolutely. That's probably the first one we'll do. It seems like the most natural fit. But also, there's some really interesting other options that we are looking at that could offer some additional capabilities. Node.js might be really attractive. I think R has some really interesting possibilities as well. Rust Go, you can imagine any kind of external scripting language could be possible to integrate. I don't think we're gonna make first-party integrations for all those scripting engines because I think the support department would go mad, but we may pick one or two.

14:01
Carl: There's also some interesting benefits beyond different languages that you may have learned libraries in or expertise in already that offer additional capabilities. One is that by externalizing the scripting engine from the platform's process, we're able to offer, I think, stronger security guarantees. So the whole shared memory concept of our current scripting engine is incredibly powerful and flexible, but it also means that you need to have a lot of trust in the scripts that you run as you do because you write them. But there is some compelling security arguments to be made for the idea that in an externalized scripting engine, we could better sandbox the scripting environment, run it at a lower privileged user, and maybe sandbox its capabilities to access the various computing resources on the host. So that could offer some compelling security guarantees in some sorts of deployments.

15:04
Carl: Also, there is some stability reasons why externalizing the scripting engine might be beneficial. If you write a script that eats up a bunch of CPU or memory in the current system, you're eating up the CPU or memory share that the gateway is trying to use. If we externalize that scripting engine again, that isolation might help the stability of the platform. So that's some compelling reasons for us to consider these ideas, and we'll take those into effect as we implement this idea. So that's the plan for scripting. So I don't have to answer that anymore. Except for next year.

15:50
Carl: Now, if we add a whole bunch of new scripting languages, the development experience in the designer is not gonna get better. It's hard enough to create a compelling development experience for one language, not to mention three or four, right? So what we wanna do here is integrate support for LSP and the designer. LSP is a protocol, language server protocol, that allows for integration between a IDE code editing application and a code execution environment like Ignition of the designer. So the idea would be that you could really gracefully use an external editor like VS Code, which does support LSP for your development experience, write your scripts in VS Code. Some of you do this already today, but if we integrate with LSP, it will be a lot smoother, and that should be really nice.

16:46
Carl: Let's talk real quickly about embedded Java. So Ignition runs on Java. The version of Java that we embed in the gateway is currently Java version 17. Most of you probably don't ever think about this, which is great; that's how we like it. But some of you who write modules or embed Ignition on limited computing resources, embedded devices, might be thinking about this. And so in the next major version, we're looking at upgrading the version of Java to probably Java version 21, maybe version 25, depending on the timing of the release. There are some really exciting cutting-edge performance benefits in these newer versions of Java, like virtual threads that we are very excited about playing with, so we're looking forward to this improvement, and it should result in some improved performance for everybody, so that'll be nice. Okay.

17:36
Carl: Let's move on past the platform and talk a little bit about applications and some, I think, very exciting ideas we have for how applications work with Ignition. So we like to say, we often say that Ignition doesn't really do anything out of the box, right? It's a toolkit that you all use to build amazing industrial applications. And a big part of our strategy has been to make sure that we don't get bogged down by any one vertical industry's specific application needs. We really like to keep Ignition very broadly applicable to many, many different industries. And we definitely plan on staying absolutely true to that philosophy. But I think that once you either build or connect to a contextualized data model, hook up to a UNS, or build one directly in Ignition or a blend of both.

18:33
Carl: I believe that we can start offering some directly usable application functionality right out of the box in Ignition. So, I'm tentatively calling this idea Zero Development Applications. It seems to be catching on. We'll see if it makes it to the final marketing of these things, but consider this a whatever codename for now. What does this mean? So, in addition to the ability for you to create your own custom applications, which is totally our bread and butter, that's not going anywhere. We also want to add some pre-made applications that you could choose to add to Ignition. And they would give you some application functionality that would work right out of the box with no development beyond creating or connecting to a data model. So we have three of these ZDAs currently identified, and I wanna briefly introduce them to you today. Number one is an ad hoc dashboarding application. So, of course, you can build custom dashboarding applications in Perspective. Many of you do that all the time.

19:31
Carl: But we wanna have a different kind of dashboarding application available. One where all of the functionality is completely pre-made. All of the widgets are pre-designed by us. All of the data handling and data binding logic is built into the product, as well as all of the logic for end users to be able to build their own and save custom real-time dashboards. So again, once you have a tag model, we really have all the information we need to be able to do this, and so you could install this module and have a dashboarding application up with absolutely no development.

20:09
Carl: The second ZDA is an alarm analysis application. So using Ignition's alarm status data model as well as the alarm journal data model, we plan on building an alarm analysis application that can offer status views as well as historical views and analytic reporting. So these are things like analysis of alarming KPIs, like root cause analysis and flood rates, and top-end alarms, finding chattering alarms, those sorts of things. And the last ZDA that we have planned to build in the next major version is a historian explorer. So this would be an advanced charting interface that has ad hoc charting, statistical charting, multivariate analysis, as well as things like time-over-time comparison charts. And the interesting thing about this historian-explorer idea is that it would be totally engine-agnostic. So it would be agnostic as to the storage engine of the history. Remember all the discussion about the the new tag history API that's in 8.3? Well, part of that design is to support this idea so this user interface could be laid on top of any type of historian backend. So how do these applications fit inside of Ignition? They will be their own modules. So they can be used standalone with Ignition, but they could be purchased à la carte and won't have dependencies on the Perspective or the Vision module, for example. They'll be their own standalone application module.

21:46
Carl: And they'll have their own login and session management, and navigation infrastructure. So they'll sort of create their own new application surface area. And if you have more than one ZDA installed on the same gateway, they'll sort of zipper together into their own little navigation structure. So if you had the alarm analysis ZDA and the historian explorer, you would be able to log into one application and have both of those bits of functionality in perhaps a TAV navigation structure or something like that. So I started off by talking about how this ZDA idea will be different from the applications that you build in the designer and that they stand on their own. But you can also use them inside of your application. So perhaps this is, I think, the most interesting part of this idea is that if you also have Perspective and are building your own application inside of Perspective, these ZDA modules will also expose their functionality as components in Perspective so that you can embed them directly in your applications and use them that way if that's a better fit for what you're doing.

23:00
Carl: So we're pretty excited about that idea. Of course, the thing we're focused on right now is actually getting 8.3 out the door. But we do have a lot of exciting plans, including the ones I just shared with you right now. So a little glimpse into the future, and we're pretty excited about it. And I'm sure some of you are excited as well. And with that, I'm gonna now pass it back to Colby, and we'll keep on going.

23:31
Colby: Carl and I have been doing this for a long time, literally since the beginning. So while I sometimes think that my memory is getting a little fuzzy these days, I do know for a fact that he and I have discussed every major idea, release, and strategy over that 21-year time period. And so I say that because I wanna say this, which is that I really have never been more excited for where we are than I am right now. He barely scratched the surface of some of the ideas that we have post 8.3. I think with the emphasis on getting 8.3 out, we don't dare to dream too much about presenting them, but it's a very exciting time. So whether you've been with us for those entire 20 years or you just learned about Ignition here this week, this is a very exciting time to be part of this community. Okay, so making software is great, but do you know where the real magic happens? In getting people to use it. So, if magic is performed by magicians, that makes our Support Services division the veritable Hogwarts of automation.

24:34
Colby: From conjuring up incredible solutions to exercising the demons of performance issues trans-mutating raw engineers into world-class Ignition experts, our Support Services division does that every day. Still, we know that we can continue to expand the level of service we offer, and we work constantly to try to find new ways to improve. To talk more about how we're doing that right now, I would like to have you help me welcome to the stage our Co-Directors of Support Services, the real wizards of Inductive Place, James Hunt and Marcus Bellamy.

25:20
Marcus Bellamy: Thank you for that very generous introduction, Colby. Good afternoon, everyone. As Colby mentioned, we're here to invite you into the dark arts of troubleshooting, the mysteries of Ignition, and to really get down to why that Perspective worker thread is showing a script transform 300 times in my thread dump. But all jokes aside, everyone, providing high-quality tech support is a very demanding job and necessitates a huge team of dedicated professionals. So today what James and I wanna do is invite you into our world, into support services, highlight our collaborative workflows, our reimagined onboarding process, technical development initiatives, and of course expanded access across many different channels. All of this, as you'll soon come to realize, is really about one mission, and that's to make sure that we're providing the best support experience to you no matter where you're at in your Ignition journey.

26:23
James Hunt: This really boils down to meaning that what we're about in terms of support services is constantly refining our ticket workflows to drive down response times.

26:31
Marcus: As well as finding ways to make more information accessible to more people across multiple communications channels.

26:37
James: We're constantly striving to break through any obstacles that stand between the success of your project.

26:43
Marcus: And to sum this all up, Support Services has your back, no matter the project, no matter the challenge.

26:51
James: One of the things that really defines support services and makes us uniquely inductive is our close relationship with development. And the vital aspect of that relationship is bringing the customer perspective to Ignition development. With 8.3 just around the corner and plans already forming with the next generation of what Ignition will be, this is where Support Services really shines. We're your advocate in that Ignition development lifecycle.

27:16
Marcus: That being said, we work very closely with development's product teams from the genesis of an idea to its creation and ultimately its public release that's made all available for you all. We have a bevy of senior software support services staff, and they come from software support, they come from training, they come from documentation, applications engineering, and that's just to name a few. They collaborate deeply with the product teams to make sure that we're giving all of you a best-in-class product experience.

27:48
James: Our work doesn't stop there. We're constantly contributing to basically the greater review process throughout release cycles by providing feedback and analysis at every stage of that release. To give you a peek under the hood of how we do what we do, I think we really need to start with what the defect analysis team is. And basically, their primary function is doing in-depth root cause analysis for bugs and many more issues. And they basically support and back-end our software support engineers, providing basically that ability to help you and basically doing that analysis, replicating an issue, and finding a solution for you every day.

28:26
Marcus: And then concurrent with that process, we also have an internal applications engineering team who's taking the insights that we derive from those interactions of DAs, support engineers, support engineers back to DAs, and they're making more robust internal diagnostics tools for our software support team. And when we have interactions with you, it streamlines our troubleshooting process greatly.

28:42
James: And this kind of leads into another key aspect of what we do is working closely with development. Our documentation team basically assesses how best to harness all of that technical knowledge and information that we have and basically deliver that to you through various resources like the User Manual, knowledge-based articles, Inductive University videos, and many more things. And then all of that kind of goes into really helping us upskill our teams internally and enhancing your learning experience.

29:17
Marcus: Many of you have been on the phone with us, have been through email with us, and you're on the call and we're referencing; I've got to ask back-end. I've got to ask front-end. So to round out this big picture that James is putting to you, we also have internal dedicated Slack channels where our support engineers can interact with product experts in real time while working with you so that we can suss out these really heavy troubleshooting issues. And I think that that collaboration, those collaborative workflows, really lend to the high-quality support that we're always trying to drive.

29:50
James: And this really plays into what we're trying to do in terms of trying to provide a responsive support experience. To assist you when you reach out to us. And this is really part of the greater picture in terms of us refining our onboarding process for old users and new. And really kind of bringing new ways to bring you into the Ignition ecosystem, which I think is fundamental in terms of really enhancing your skill levels and bringing everybody up to speed in terms of what's out, latest and greatest with Ignition. And I think this all kind of plays into what our one of our bigger goals is really kind of like... support services wants to put you in the driver's seat of your development.

30:28
Marcus: With that, you've got to know that we take your learning of Ignition very, very seriously, and where that comes from is because if we know that we can communicate how to use Ignition to you but then also layer that onto how to make you be more effective with Ignition, two things happen. One, you're freer to innovate, and two, you can dramatically enhance the operations of your plant, of your industry, whatever it may be.

30:58
James: Exactly. This all boils down to us really placing a high importance on empowering our customers. That's you guys. We want you guys to have a top-notch, omni-channel experience with us. And speaking of channels, we'd be remiss if we didn't say Inductive University is turning a big 10 this year.

31:17
Marcus: Happy birthday IU, happy birthday IU. So if you're like me, you're wondering what's next for IU. And I've got the big secret. In a big way, we're putting you all at the forefront of IU's next development phase. Our documentation team under Paul Scott is poised to bring IU into the future by addressing the needs of our diverse user base. What we're gonna be doing to achieve that is creating learning paths that are actually correspondent to skill level. And what this means is that users that are being newly onboarded to Ignition, as well as you veterans out there that have a lot of accumulated experience, will have a more personalized way to derive maximum benefit from the platform each and every day.

32:06
James: Also playing into that, expect to see a course that is really devoted to our newer users, basically helping bringing you into the Ignition ecosystem. On top of that, we're dedicating a track to really kind of focus on our intermediate users in terms of helping them upskill their knowledge in Ignition. And all of this centered around, I want you guys to know, don't worry, the existing content that we have is still gonna be there. We're still gonna have materials that cater to a broader audience. That's fundamental to what we do, but what we are doing is updating that library and really bringing it up, basically modernizing everything that we have there so it's current with the times, and we're expanding that course catalog so you can expect to see over 70 new videos in 2025.

32:52
Marcus: Thank you. You'll also note that we're gonna be putting a really hefty premium on the hands-on aspect of learning. By renovating existing courses with what we're now calling learning labs, those are gonna be tangible examples that you can learn alongside with. We believe that by providing that more hands-on experience, even more users are gonna be propelled into more and more advanced levels of proficiency with Ignition. So we're very proud of that new development and so proud that we feel empowered to be preparing for IU's 20th birthday before we've even finished celebrating the 10th, and it kind of feels parenting at this point with all of this advanced planning.

33:38
James: Yes, yes indeed. All right, at the end of the day, what our primary goal is, is we're always aiming to bring the best support experience possible in the business. That's fundamentally what defines this, but I think there's also some additional opportunities for us with our training system. I think this is an area that we can really maximize the potential in terms of building up your skill set with Ignition. And so, based on trends and customer feedback over the years, our training team overseen by Bobby McKenzie is in the midst of a grand rejuvenation of our courses. Fundamentally, what this consists of is we're doing some significant updates to our existing courses, and we're really emphasizing a focus on Perspective, as well as we're planning to grow our course catalog with four new classes on topics such as CSS and Perspective, advanced scripting, containerized deployments, and Git. Expect to see these new offerings towards the end of 2025. And really, the goal of these classes is to allow you to take Ignition to that next level. Remember, these are advanced courses. So this doesn't; our existing courses will be still there. The classic offerings will be available. Really, our goal with these new courses is basically next-level development for you to really kind of take you where you wanna go with Ignition. So please stay tuned.

35:01
Marcus: Now I know some of you out there have been in a phase where you have a new technology that you wanna integrate with Ignition. You want the thing to talk to Ignition. And you feel it's the best opportunity to call us right then. And so after that first hour of the call, you get to the second hour of the call, you get to the third hour of the call. And at about the three hour and 45 minute mark, you say to yourself, I stumped him again. I got him with this new technology that nobody in support has ever heard of, and I've got to find the manual on the wayback machine somewhere or something like that. Now technology is changing all the time, and we recognize that, so with a constantly evolving technical horizon, the software support team that we have those that you communicate with over phone and email traditionally we realize that we have to put a big premium on learning and embracing the things that you all are learning about to try and stay in step in the times with you all. So we wanna diversify the range of topics that we're studying internally just to keep up. We realize that this is gonna take an awareness of what you all are learning and to try to develop some level of expertise of the technologies that you're leveraging every day. Because at our base, what we wanna do is provide support to you no matter where your project takes you or whatever technical challenge that you confront.

36:30
James: In conjunction to that, we are in the process of implementing basically three key initiatives. They're really big focus areas for us in support services. The first one is building our own in-house PLC training lab. The goal really around that is to make those resources more easily accessible to our team and really help them to better understand the ins and outs of the devices you guys use every day. Coupled with that, we're also working on creating basically a much more dynamic and scalable testing architectures for our teams to use in the DA and software support group. And basically the goal of those new architectures is basically giving us the flexibility to replicate and test systems in a multitude of environments. And this is coupled with an additional initiative, which is basically.

37:13
James: We're constructing challenge gateways. These instances are basically different gateways and things that we've run into while supporting all of you that have been challenging. And so it produces an interesting, unique knowledge set. And so now we can actually take those things and have our team work in those environments, honing their troubleshooting skills and really building out their knowledge in various Ignition subsystems and beyond.

37:39
Marcus: And as you can all recognize, the picture that we're trying to paint with all of these initiatives is to fulfill a goal that we've had ever since I've been here and probably even since before. And that's to be able to continue to empower our user base to embrace and confront the technical challenges of today and tomorrow. And I think that our commitment to training and knowledge development is only gonna help us bring a more senior type of role within the software support role and provide a path for our engineers who are very excited about Ignition, excited about the technologies that you're using to ascend within the ranks to higher and higher levels of troubleshooting. And when we have that in place, we can continue to provide a larger range of support services for you all. And with the complexity that you present to us as far as your projects, we can speak to that and be really, really effective partners with you today and tomorrow.

38:36
James: In many different ways. One of our primary goals is making support services available to more users. That's fundamental. It's like, how can we cut down the barrier to getting access to us? And one of those examples is really centered around Core certification. Over the past year, basically, we were working towards streamlining and making that process much more accessible. And so, basically, what that means is that Core certification test is now available on our website. You guys can purchase it any time of day, start working on it, and submit it. And the cool part is, is when you submit it, it's graded immediately, and you get that grade back. So basically we're cutting down the amount of time for you to get those, basically that feedback on what you've learned. And we're tremendously proud of that project. I would also like to say thank you to all the community members that have given us feedback while we're refining that process and helping it make the product that it is today. We appreciate that.

39:32
Marcus: Another example of this expanded accessibility. This expanded access really relies with our software support offerings. What we're trying to do is take what you love about the support that you're receiving and expand it, and in this case, across continents. So as we wind things down, I wanna let everybody in on a big announcement. What we're doing locally, as always, is continuing to bring more support engineers to our Folsom offices here in the United States. And also, what we're doing in Australia is not only growing but having a really close collaborative training environment with our Australian colleagues. And so starting in Q1 of 2025, what this is going to mean for you all is a 50% increase of availability for support. Now what does that mean in real-time terms? I think most of, if not all of you know, that right now you can call or email in, and between the hours of 6:00 AM and 5:00 PM Pacific time, interact with us. So with this 50% increase, you're going to be able to do that same thing, but from 6:00 AM to 11:00 PM Pacific time, starting all in Q1 of 2025.

41:00
James: In closing. I just wanna make it clear: Support Services is firmly committed to unlocking value for all of you. And through everything we do, we strive to help you learn, leverage, and harness Ignition with the least amount of friction possible. Through dev support workflow processes, the onboarding experience, technical development of our team, and expanded support hours, it's all in service to our larger goal, which is fundamentally propelling all of you into the future of automation through the power of Ignition. Thank you.

41:38
Colby: Thank you. Thank you. Thank you so much, James and Marcus, for everything that you and your team do every day for this Ignition community. You know when the leaders of this company get together and we talk about values, there is one word that comes up over and over again. You've heard it many times already this week. I heard Marcus just emphasize it himself, and that is empowerment. Support Services is obviously a key part to empowering a part of empowering our users every day. But at the end of the day, our goal is to empower you across everything to do, as we keep saying, to dream it, do it. So that core value of empowerment goes all the way back to the beginning. But I think back then we used to say it in a slightly simpler way to get out of your way. It was a very simple idea, but it turned out to be amazingly innovative for this industry. The idea that you should be able to access, learn, and develop everything you need on your own without any hindrance or need to talk to us unless you really wanted to. Think about it. You can download the software right now in minutes and install it very quickly.

42:44
Marcus: You can reset the demo as many times as you want. You can read the user manual, go through Inductive University, participate in the forms, learn everything you need to develop your project. And along the way, you'll know exactly what it's gonna cost you in the end because the prices are right there on the website. It was all designed to get out of your way. It was important to us then, and it's just as important to us now. But that doesn't mean we're perfect. Far from it. We know we can do better. And that's exactly what we're doing. So to tell you how, I'd like to introduce you to Nick Barfuss, the product manager on our project that's very special that he would like to tell you about.

43:30
Nick Barfuss: Thanks, Colby. We know that's you, real people who use Ignition to create our amazing projects. And that's why we've always supported you on your Ignition journey. We believe that it's access to these self-service tools that are a part of what makes the barrier of entry so easy for Ignition. And one way we've provided this access is through a free Inductive Automation account. With this account, new and existing users have access to free training through Inductive University, a free Maker Edition licenses to use on your personal projects. And as James and Marcus highlighted, access to knowledge via the forms, robust Ignition documentation, and, when needed, phone and web support. But what about the companies that you work for and the businesses that you work with? How can we put more self-service options in your organization's hands to empower your businesses to be even more self-driven? Let's quickly look at some easily identifiable organizations in our ecosystem and some of the issues that you all face. End users. You work with integrators and local distributors to make your projects reality, and you approach these external organizations with urgent questions, big ideas, and a desire to collaborate.

44:51
Nick: You use Ignition in various locations and lines and configurations, and you need access to information for auditing, budgeting, or reporting purposes. Currently, getting this information is difficult and usually results in a phone call to Inductive Automation. Integrators, you aren't just working for the customer; you're collaborating with them to build some really innovative and complex solutions. Whether during the design phase or the development or the deployment of your project, you often need to receive or pass the baton. You need tools to streamline license transfers and ownerships while maintaining the ability to access important information all along the way. Currently, this usually results in calling Inductive Automation and talking to a support or sales representative. Distributors, you understand the unique needs of your market. You are building a business culture with your customers and discovering pain points, solving issues with the same quality of service and support that Inductive Automation provides and that customers expect. You sell Ignition all over the world, and we think these sales should be able to be made 24/7 and in local currency. And of course, we are very mindful of our strategic solutions and alliance partner organizations. We want to continue removing obstacles to keep our relationships strong.

46:16
Nick: Your needs are varied. And while person-to-person communication is essential, we believe we can do a better job of putting data in your hands and metrics in the forefront. We wanna take a moment to let you all know that we see you. We are aware of the pain points and obstacles that are in your way. And in fact, we've spent the last several years researching, gathering feedback, and identifying many of these key issues that all of you face. And we've noticed a few things in common. Organizations need 24/7 real-time access to your information. Organizations are comprised of passionate people who, as Colby said, work best when we get out of the way. And organizations work together to make amazing things happen when they can connect. We've put a huge effort of providing self service access for individuals, and we wanna take the same approach for all of the organizations. This is why we're excited to announce the Inductive Automation Workspaces. This is our solution to provide self-service tools for your organization and the people in it, allowing even more collaboration in unprecedented ways. Think of it this way. If the IA account is designed for you, the individual, then the IA Workspace is designed for your organization.

47:41
Nick: Let's look at some of the features that our workspace will offer. With the Workspace, you'll be able to structure your organizations in a way that makes sense to you. Whether you're a complex organization or a single location business, you can create organizational units that can house a collection of people, licenses, and support plan information. We think this will allow your organization to become more autonomous and self-organized. And as your organization grows, you can continue to invite staff and assign them access to information they need. For example, you can create engineering roles to provide plant managers and developers the ability to access critical license information where they can diagnose problems without the need of having to contact support. Or you can create purchasing roles to empower trusted people in your organization the ability to upgrade, purchase, or renew support plans and licenses. So when we talk about purchasing, we're really excited to provide a wide range of features. Your organization can browse our entire product selection, from modules to support plans, to create any solution you can imagine. You'll be able to create estimates, quotes, turn those into orders, and share them with anyone. This could be finance or approval teams within your organization or even the customers that you're collaborating with.

49:02
Nick: And we're really excited to announce that you will be able to buy in your local currency directly from your distributor or integrator and gain instant access with payment integrations that will allow you to purchase with credit card or to set up a billing profile. We know getting real-time information about your licenses is critical. With a Workspace, you can inspect, organize, share, move, and report on the licenses that you own. You'll be able to name and tag the licenses so that your organization can easily find them and search for them and discover properties like module configuration, activation history, and support options. And just like licenses, you'll have even more clarity and visibility into the support plans than ever before. Wondering when your support plan is up for renewal or if you can take advantage of priority or total couch support? A workspace will help you manage your plans without the need of having to call Inductive Automation or track billing cycles in clunky ways. These are just some of the features that we're building, but we have many more planned, like a dashboard where you'll have access to contextual insights to inform your organization of what's changing and certification tracking features that will provide you visibility into the credential and certification journey of the people in your organization.

50:19
Nick: We can't wait to build upon this framework and provide you more tools and services. So now that you know about the features of the Workspace, let's look at the way we've been currently operating. We'll call this mode of operations Managed Service. Our sales teams consist of amazing people, and they've built a great relationship with you. But they aren't always available to help you get the information you need. Time zones, asynchronous delays, and other factors can slow you down. And for the most part, you don't have direct access to much of the information that you want access to. Now let's compare this with the self-service mode. With a Workspace, organizations can rely less on Inductive Automation sales or support staff when the need to keep moving is paramount. People in your organization can sign in at their convenience to find and update information, diagnose and analyze problems, and collaborate with anyone that you're doing business with. The real beauty of a Workspace is that your sales and support staff aren't going away. In fact, they'll both be able to assist you better than ever before. With assisted service, your sales contacts can provide more clarity, efficiency, and transparency to the purchasing process. You'll be able to work together to share quotes with others in your organization and bring your ideas from solutions to reality. The mission for Workspace is to get out of your way, put data in your hands, and help you connect.

51:46
Nick: And here are three ways that we wanna do that. We want to unify. A Workspace offers a simple, unified, browser-based interface for your organizations to consistently access and manage your information. We strive to empower. A Workspace empowers organizations to independently analyze and control their data via self-service or assisted service modes, and we aim to be scalable. Our Workspace sets our ecosystem on the path to growth by redesigning old architectures, restructuring our legacy models, and rebuilding these interfaces to align with the evolving and modern needs of organizations all across the globe. So when can you access a Workspace? Well, in the coming weeks you're going to be noticing changes to the way you sign into your Inductive Automation account, offering you much more security. And then later in the year you'll see improvement to your Inductive Automation account interface experience. And then in 2025, we'll continue our work, and we'll be sure to let you know when you can create your organization and join a Workspace. In closing, I would like to recap on a few points. And to do this, I want to use a little inspiration from past ICC themes. A Workspace is a browser-based interface designed to help you build a synergistic ecosystem.

53:13
Nick: A Workspace will elevate the entire Ignition experience by providing ways for you to manage your licenses, support plans, people, organizational structures, and more in ways that are unique to each and every one of your businesses. And our Workspace will transform the selling and purchasing process, allowing your organization to create estimates, share quotes, and order products when you want to and in your local currency. And just like your IA account, an IA Workspace will be free, allowing your organization to break through any obstacles that keep you currently from achieving. We can't wait for you to start using Workspaces, and we look forward to offering this for you next year. Thank you.

54:07
Colby: Pretty incredible, huh? Once again, our vision is to get out of your way to empower you to do what you need on your own terms. And I think that Workspaces is gonna go a long way to continuing that. So you remember my phrase from a little bit ago, uniquely inductive? Well, to me, Workspaces is uniquely inductive. We could have built a simple online store, but instead we're building an entire e-commerce platform to perfectly serve the needs of this community and the future that we wanna build. Just like we could have put training videos up on YouTube, but instead we created Inductive University, which is still regarded as one of the finest training resources available. Our dedication to support, the fact that all of our staff are in our offices here and in Australia, with direct access to all of the relevant systems and people that they need to solve your problems, that is uniquely inductive. Our approach to software, to pushing the boundaries for this automation industry to be innovative, but also in a way that's secure, consistent, and stable that leverages open technology and open standards, but while making them easy to use and reliable for the future. That is uniquely inductive. And finally, perhaps the most important unique trait of all, this community. Our ability to gather here together each year, collaborate, share ideas, and imagine, and then keep that spirit going throughout the rest of the year.

55:29
Colby: Well, I just don't think it gets any more uniquely inductive than that. So I just wanted to mention all that because I think what we have going on is incredibly unique. And I am convinced that working together, we can keep it going for a long time to come. So now, without further ado or philosophical stalling, let's get to the final portion of our day. Something that's always been pretty darn unique about ICC, our live Q&A. So please help me to welcome back to the stage all of our speakers. Okay, we've talked about so much over the last few days. And possibly with all the conversations and the sessions and whatnot, you have absolutely no questions at all. That would be great. We'd get out of here. But perhaps with all the content we just showed, something will come to mind. We have mic runners. Feel free to raise your hands. This is your opportunity to ask us whatever you want before we wrap this up. Don't hold back. If things get too wild, I have a car in back. I can run out there. It's no problem.

56:36
Audience Member 1: Hey guys, quick question. So we have different roles for different servers. So we have like, for example, the primary server, the backup server, IO servers. Is there any plans in the future to have a role basis on development server versus production server in an easy migration or promotion method bill to the architecture?

57:01
James: Different than the deployment modes we talked about in 8.3? Like.

57:06
Audience Member 1: Yeah, like a role-based.

57:11
James: I mean, I would say the purpose of deployment modes is to define various roles. So I guess that was our plan, and we did it.

57:21
Audience Member 1: Alright. Looking forward to it.

57:25
Colby: Are you asking about breaking gateways apart perhaps, or?

57:28
Audience Member 1: I'm sorry.

57:29
Colby: Do you mean like breaking gateways apart, breaking up functionality?

57:31
Audience Member 1: Yes.

57:33
Colby: The resource system will help with that, I think a lot.

57:36
Nick : I agree. I also think that's part of the idea behind the modular architecture is to be able to split up functionality by module.

57:48
Audience Member 1: And promoting like the, from the development mode to the...

57:50
Nick : Oh, you mean the actual deployment from one place to another.

57:54
Audience Member 1: Yes, sir.

57:55
Nick: There's a bunch of ways to do that. I do think that Colby, I think, answered it already, which is that by having the configuration entirely housed in the file system, it helps a lot. Now, that doesn't mean it's a feature of the software itself, it just allows you to integrate...

58:10
Audience Member 1: It's like a manual kind of process. But I was just wondering if there was gonna be any kind of architectural change or role-based kind of features for that architecture.

58:20
Nick: Possibly. I think EAM would probably be the right place for that to live.

58:26
Audience Member 1: Awesome.

58:28
Nick: All right. Front.

58:36
Audience Member 2: So there was talk about changes to the Core certification that were made this year. Are there any plans to update the Gold certification exam process and along with the new training that's coming out at the end of next year? Is there gonna be a higher than Gold certification to go with that?

59:00
Marcus: Well, currently the, yes, there are plans to renovate the Gold certification process. Training is hard at work on that. As far as new levels though, we did not have that planned. I think it's an idea that I definitely would like to explore with you; maybe after the panel, see exactly what you're looking for and like what needs that would address. But yeah, we are at work also trying to renovate the Gold cert process.

59:23
Audience Member 2: Thank you.

59:24
Audience Member 3: In relation to the increased training online, do you guys have any intent to add more in-person training resources for the certification? I know you guys have that on your own path, but at times there, it's difficult to get people to in-person training or scheduled training 'cause they're delayed by months. Is there any idea or thought process to increase the training abilities?

59:49
James: Well, I can say this is, we're constantly growing the training team. So, I mean, was there a particular class that you wanted to have in person? I guess maybe I'm trying to understand is: what's the key aspect of the in-person training that you find most valuable?

1:00:07
Audience Member 3: It's a little bit more formal training, right? In-person, right? So instead of having someone kind of go at their pace and then you have to really, I don't know, manage time a little bit better. The structured courses you guys offer give a lot better, more in-depth time, time to ask an expert really be there? So I guess it fast tracks training a little bit.

1:00:26
Colby: Are you asking about like increased capacity for that? So like...

1:00:30
Audience Member 3: Yeah, so we have people that we try to send through training, and sometimes there's three-month wait time to get someone signed up.

1:00:35
Colby: Yeah. They can blame me because I have a request for like multiple training hires I've been stalling on. But we'll get on that.

1:00:45
James: I mean, while true...

1:00:48
Colby: They're not used to this, but I am.

1:00:50
James: I mean another fundamental, like, catalyst for that is really demand, and a lot of times, the in-person training classes take longer to fill than our virtual. So that does kind of affect the cadence. But we are trying to expand that.

1:01:04
Audience Member 4: Will Workspace replace the integrator tools we have now? Like the license portal?

1:01:18
Colby: Yes.

1:01:22
Marcus: So the license portal, yes. This is really just a continuation and expansion of the license portal to make it more accessible to your organization. And then some of the, in other integrator tools that you have access to, like the integrator portal, where you're probably managing some of the information, the idea is really to have a unified experience to do that. So none of that stuff is going away. It's actually just all gonna be enhanced and unified into a better, more cohesive experience.

1:01:46
Audience Member 5: So I guess a bit of a two-part question. One was the LSP and the editor. I think personally I've had a few issues with, functionality of the editor versus say your favorite IDE. Is that one sort of a recognition that there won't be that much more development for the designer editor and to just sort of offload that to, like JetBrains or something like that, that the LSP would leverage? And second is with the scripting engine; I think like an insane proposition you just put forward, 'cause I just think of all the possibilities. Is it something that like only you guys could introduce a new language to? Or is it more like a something that has like a transpiler or a virtual machine that you could like potentially without IA needing to do it port, my favorite pet language to, because I want to, I'm insane, and I just hate future support, and I have my own custom language in there.

1:02:56
Nick: Gotcha. So part one of the question was, does integration with LSP mean we're gonna abandon the DevX experience of the designer? No. I don't want having an external editor to become a requirement. So I do think it's on us to still make our best effort to always improve the developer experience of our first party tools. But can we compete with JetBrains for developed editor experience in all languages? Of course we can't. And why would we try? So there's a balance there. And the second part was, could a third party integrate their own engine? Absolutely. So I use the word extension point, which I realize is sort of inside baseball. But modules, the way modules add functionality into Ignition is through this concept called extension points. And so it would require a module to be written, but that will be part of the public API.

1:04:01
Audience Member 6: Hi. Piggybacking on the first question, well, at least in my head, talking about the development and pushing into a production environment, have you ever considered a development license? For example, I would like to have an on-prem, not in the cloud, and resetting the trial version every two hours. It's cumbersome. So at one point, I did ask my sales engineer about that or sales rep. Sorry. But yeah, what about a dev license? It's because purchasing a fully full fledged license might be sometimes well, a considerable investment. So what about a dev license?

1:04:48
Colby: What did your sales engineer say?

1:04:51
Audience Member 6: Well, he's retired, so probably I can say...

1:05:00
Audience Member 6: Alright, well, the answer I got is just purchase another...

1:05:04
Colby: Ah, yeah, I can't see your shirt. So are you an integrator or an end user?

1:05:08
Audience Member 6: I'm an end user.

1:05:09
Colby: End user. Too bad. If you're not aware, integrators in the IA account right now can go in and request dev licenses. So just, that's why I mentioned that. Did you have something you wanted...

1:05:21
Carl: No, I mean, the question was, have we ever considered it? Yeah, it's something we actually, we do. It's a conversation to be had.

1:05:30
Colby: Dev licenses are one thing, but let's perhaps pivot off that to talk about the licensing. I know it's not finalized, but some might... We do envision some sort of a licensing link between these different deployment modes. It's a little earlier, but...

1:05:40
Carl: It's a whiteboard idea, but it... Yeah, I do think there's a... So this would be a similar idea where if you, one because logical system that has three separate environments is at just three X, the license cost, probably not what we want to do. We've toyed around with ideas of having something similar to the way we do redundancy where the redundant node is priced at 50% of the primary node or something like that. Maybe we do something similar for dev and staging licenses, but we don't have any formalized approach to that. But it's something we talked about.

1:06:18
Colby: Yeah, I wanted to touch on though, because I hear in the question that if you're thinking about these multi-stage environments, what's it gonna cost? So we're thinking about that. Alright, how about on here?

1:06:29
Audience Member 7: Yeah, I have one really weird question and then one sort of not weird. The first one is the in 8.3, like in 8.1, the scripting engine on the non-master or non-active node is kind of dumb. It doesn't run. In 8.3, is there gonna be any way to have event scripts or some kind of thing run on the inactive node to maybe do some cleanup after a failover or do certain things that only would be done on the inactive node? That's question number one. And to question number two, I'm a registered professional engineer, and I have to do a continuing education. I would love to not have to go out to a company and spend several thousand dollars for absolutely worthless training material just so I can keep my license up to date. I'd like to go to Inductive Automation University and is...

1:07:30
Siri: That's not nice.

1:07:36
Audience Member 8: Siri Just said that was not nice that I said that about those training people. This is my life. Anyway, so my question is, is there any... I have no idea. From a training perspective, you guys are the professionals. Is there any way to get some of your training materials certified for professional societies to use? Like I'm just like, Cisco has training stuff and network training, network security. There are certain things you can do that is applicable everywhere. Is that any possibility?

1:08:12
Carl: I guess that's definitely further out, but there's a lot of things that we're considering in terms of, like what it means to really provide training resource and materials versus just like explicitly a class. You know? And I mean obviously, a lot of that's done with, like, Inductive University through the videos, user manual. Like there's those things, but I see what you mean in terms of like actually having almost like a course that you could just purchase the course and then go facilitate that. That is definitely on the books. But in the future, we're working that out.

1:08:50
Colby: That's a great question, actually. And I haven't heard the subject of trying to get our courses accredited in that way brought up. So we'll certainly go research that. I think that's great.

1:08:58
Carl: The first part of the question was about redundancy.

1:08:58
Colby: Oh yeah, redundancy. There's...

1:09:01
Carl: So having some logic that runs on the redundant node it's certainly something that we could consider doing. We would have to do it on purpose, as in the whole point of the redundancy setup is that you are supposed to only think about one cohesive set of functionality that then is the configuration is synchronized and then only becomes active when needed. So it's not that the scripting engine is dumb; it's that we're just intentionally not duplicating your configuration and running it twice, right? So in order to do something like that, we would have to add some sort of scripting resource that is intentionally trying to run on the backup, which could play into like the warm, cold, hot modes or something. So it's a neat idea. I don't; I haven't heard that one before, but...

1:09:49
Marcus: Yeah, no, I haven't either. And I was gonna say, it doesn't; to me, that's not a question that depends on the version. You could request that today. Now, I'm not saying we'll get around to it before that timeline. We're kind of busy, but as Carl said, it would be a purposeful thing, and it makes sense. So. Alright, in the top perhaps.

1:10:07
Rafy: Up here. Rafy from Kenard Engineering. With the extended hours of support coming through later, is there a plan to take it to 24 hours a day later sometime?

1:10:21
Marcus: Yes. It's either really cold or I'm nervous about that question.

1:10:27
Colby: Will you come to the conference next year? And...

1:10:30
Marcus: But...

1:10:33
Rafy: Yes.

1:10:37
Marcus: As far as plans go, as we've articulated, we're definitely committed to expanding access. As far as the concrete timeline that we could give you and the different things that we need to get together on our side, it's multiple pieces, but definitely believe that we have been having that discussion, and it's definitely hot on our mind. So I can't give any more concrete details than that; except for that, we are definitely planning for a future where we are fully accessible to you all.

1:11:04
Colby: Yeah.

1:11:16
Audience Member 9: Hi. As far as the work space and comparing to the existing integrator dashboard, is there gonna be a way to manage who within the organization have access to change stuff on Workspace and...

1:11:32
Colby: Absolutely. Oh, sorry.

1:11:35
Audience Member 9: Yeah. And also, for right now, there is no correlation between the Inductive University users and the Workspace. So is there any way to manage who can get from there to there, and also, when somebody from the organization leaves, how we can manage that to make sure that they don't have access to these kind of stuff?

1:11:58
Nick: Okay. So, okay, I'll kind of go backwards. So one kind of crucial part of this is your certification belongs to you, right? Like as you get certified and maybe you move on, we want that certification belong to you and not the organization. So your organization is comprised of a bunch of certified individuals. So absolutely, that certification will stick with your IA account and progress with you; let's say you move on. You'll be able to track your employees or all of your staff's certifications. Like I mentioned, that's one of our future things that we're gonna be doing, but very, very hot on our minds of is being able to expose all of your individual's certifications, right? You want to be able to see who in your organization is certified at what level.

1:12:42
Nick: So you can track that in a lot more clear way. Maybe you wanna build groups so you can see different departments and different structures of where those people are organized. So there's a lot of organization or features for that certification journey there. And then, as far as the roles go, yeah, like this is gonna be fully role-based systems. So you'll be able to assign roles to managers. Let's say managers might have access to see all those people with their certifications. You can even divide that within your organization into a bunch of different structures. Maybe you create a finance department or you have a certain line or a location you wanna assign people to. You'll be able to apply, assign roles to, has access to say even see licenses, be able to make orders, be able to fully access all parts of your organization. So yeah, fully robust roles and permission system on Workspaces

1:13:31
Audience Member 9: Thank you.

1:13:32
Colby: To go even further. That's actually the organizational structure is one of the places we've put the most work, and why it's kind of such a unique product, right? There's so many unique relationships in our community. You have integrators that have a relationship with end users, but that comes and goes or evolves over time. End users come in as a location, and they grow. And so you have different business units, different areas of your enterprise. So we've put so much work into modeling that for this use case.

1:14:01
Audience Member 10: Yeah. By offering this external IDE, is that one way we can get sort of the dark mode?

1:14:23
Colby: I am sure you'll be able to get it in the external IDE.

1:14:34
Brennan Jewett: Hey folks. Brennan Jewett with Flexware Innovation here. I have a question pertaining to support. I'm really excited that we're gonna have these extended hours and following up on the earlier question about 24-hour support. I'm curious if you have thought about maybe leveraging external resources. So, I heard you know that there's some integrators that have been helping you guys with awesome instruction for the certification courses. I think back to last year, there were some integrators walking around here with shirts that said, Hey, ask me about 24/7 support. So my question is, have you considered maybe offering different tiers of support where maybe integrators who are doing this kind of work every day could potentially help out with some of those initial kind of questions or support calls and maybe leverage a wider network to get that 24 hour support? And then if someone gets stumped, maybe that goes on to tier two, 'cause when I think back to learning Ignition seven years ago, I had silly little questions that could be answered in 20 minutes, and then I had questions that might take three hours, or I have to get on the phone the next day with you guys when somebody comes back in the office. So just curious if that's something you've thought about, and if not, I hope that you maybe consider it.

1:15:51
James: I mean, we've definitely thought about that. I mean, just to kinda put this in context, I mean, we average, I mean, what is it? Like 3,500 tickets a month we're average working on. I mean, so in terms of like our workload, it's always a pretty hectic environment in terms of what we're looking, working on. So considering, like, how best to serve all of you and give you guys access to resources and making that something that basically lowers the barrier of access. I mean, yeah, we've definitely considered those things. There would be a lot of different pieces that we'd have to figure out to even implement something like that. So while it makes a lot of sense, there's definitely some concerns around quality control and then consistency in terms of what information is communicated and stuff like that. So, not to say that it's off the table, but there's definitely a lot of consideration in terms of how we would implement something like that to ensure that people are getting the help we would expect.

1:16:49
Marcus: Yeah, because the customer's experience is really key. And to the extent that we can have an influence on our brand of hospitality and our brand of care, that's been instilled through like the generations of support, we want to stay really close to that to make sure that the people on the other end, though they might not be seeing us, they definitely feel like it's our touch that's been added there. Not to say that any other support couldn't add its own, but we're very, very protective of the customer experience and want to make sure that it stays not only consistent, but that it actually accelerates and evolves and even gets better. We have a lot of lessons to learn. So if in the future, that plan could make for some partnership or some evolution of a higher-level customer experience. Who knows. But for now, we're sticking as close to it as possible.

1:17:49
Colby: So unfortunately, we are at the end of our time. And so I think I was gonna say one more question, but this could go on all day. So unfortunately, I do think we should probably wrap it up. I wanna thank everyone up here for being here.

1:18:13
Colby: Thank you for your wonderful questions, and above all, thank you all for coming this year. It's been so incredible. We can't wait for our new location next year to welcome you all back and many more. And so until then, thanks again. Have a great trip home, and we'll see you next time.

Discover which pivotal new technologies and trends are reshaping the future of automation for industrial organizations. In this engaging panel discussion, some of the Ignition community's most successful integration professionals will share their strategies in response to these evolving technologies.

Transcript:

00:02
Chris Fischer: Okay. Hello, everyone. Welcome to ICC 2024. Thank you for joining today's Integrator Panel, where we discuss industry trends, Ignition successes, and challenges, and the larger ecosystem as it exists today for integrators. The theme of today's discussion is, "What tech trends are breaking through?" We're looking forward to a great discussion. We'll have some time for Q&A towards the end. My name's Chris Fischer. I am the Integrator Program Manager and have been in Inductive Automation for about five years. I work with integrators of all sizes across a wide variety of industries that Ignition touches. We've got a great group of panelists, so let's go ahead and meet them.

00:45
Chris Fischer: First up, Leah Warren is an Automation Engineer and Idaho Branch Manager at Tamaki Control in Twin Falls, Idaho. She has over a decade of experience at Tamaki, where she's worked on designing Ignition projects and applications, control strategies for various processes, and implemented and managed many large-scale projects. When she's not programming, she enjoys family time with her toddler, where her troubleshooting skills are put to the test in entirely new ways.

01:20
Chris Fischer: Thanks, Leah, and welcome.

01:28
Chris Fischer: Moving on. Morris Moore, or Mo, is the Manager of Software Services and IoT at INS. He has 25 years of experience in the SCADA automation and IoT fields in almost every vertical from oil & gas, food & bev, renewable energy, warehouse & transportation, and more. INS software services specializes in data integration and edge-to-cloud technologies, and they're a Premier Integrator for the Inductive Automation Ignition platform. Mo's team are early adopters of the MQTT Sparkplug standard and are certified in several data lake technologies, such as the Cirrus Link IoT Bridge and Snowflake. Mo, welcome.

02:09
Chris Fischer: Moving right along. We've got Anh-Tuan Tran from RoviSys. Anh-Tuan has more than 18 years of automation experience, tackling customer challenges ranging from DCS, PLC, and HMI/SCADA system layers to complex MES implementations. Since discovering Ignition in 2017, Anh-Tuan has been a continuous advocate for Ignition, enhancing data usability for manufacturers through both out-of-the-box and customized platform solutions. As a manager at RoviSys, he leads a team of specializing in information data systems and OEE configuration for CPG companies. Anh-Tuan focuses heavily on solving customer problems to increase efficiency, enhance visibility, reduce downtime...

03:23
Chris Fischer: And ensure his team follows the DxOps transformation standards for successful implementations and improvement of overall profitability. Anh-Tuan, thank you and welcome. Moving right along. We've got Remus Pop. Remus is a Partner and CEO of Concept Reply. Remus is a recognized industry expert in Industry 4.0 and Digital Transformation with a long background in manufacturing that spans several industries. Part of the Ignition community for a very long time. He's helped with enterprise manufacturing clients design strategies to deploy and scale smart factory initiatives across the globe.

03:39
Chris Fischer: In his current role as Partner and CEO, Remus is striving to build the integrator of the future by building a team of combined OT and IT professionals. Remus, welcome.

03:53
Mo Moore: Hey, Chris?

03:54
Chris Fischer: Yeah?

03:54
Mo Moore: I didn't know that Remus was such a San Francisco.

03:57
Remus Pop: Well, Mo, I'm actually not a San Francisco fan. I am a very big Detroit Lions fan, and last year I made a very unfortunate bet with [Inductive Automation Senior Account Executive] Lester Ares and [Opto 22 Vice President] Benson Hougland, and so now I have to wear this silly red shirt on stage in front of everybody.

04:12
Mo Moore: Sorry. I'm sorry, Remus.

04:14
Remus Pop: Hopefully Lester's here to collect on that bet.

04:16
Mo Moore: Sorry about that, Chris.

04:17
Remus Pop: Thanks, Mo.

04:17
Chris Fischer: Thanks for supporting the 49ers there, jersey, for us NorCal folk, Remus. All right, last but not least, we've got Brian McLaughlin. He's a System Architect with SL Controls/NNIT. He has over 12 years of experience in developing cutting-edge manufacturing automation systems across a wide range of industries. He's been in the forefront of designing and delivering advanced SCADA and MES solutions for top-tier clients in the medical and pharmaceutical sectors, driving innovation and efficiency in highly regulated environments. Brian, thanks so much for joining us. Okay, as I said, we're gonna do a little barrage of questions here, then we're gonna do some Q&A, so let's kick things off. Leah, we're gonna start right here with you. First question, what advice would you give to a new integrator entering the industry?

05:06
Leah Warren: So I kind of have two answers for this. Number one would be don't ignore cybersecurity. You don't want to be the reason you, like, we're an access point for a lot of these plans, and if you're the reason ransomware ends up somewhere, I mean, that can completely destroy a reputation. It can tank a company. So that's something to be taken very seriously. There's things like the NIST audits that you can do to kind of help with that. And then second would be to design a very cohesive UI, and that kind of starts with, I think, a lot of design up front and documentation of that, which all of us... It's the boring part, but it's the part that unifies the team, because engineer A and engineer B will design two things completely differently, and you want your operators to have a cohesive experience, especially if you're doing a large integration.

06:07
Chris Fischer: How about you, Mo?

06:10
Mo Moore: So I'll take a stab at that. I'm more of a... We do more enterprise-layer applications with the Ignition system, so when I get first introduced into the business.

06:21
Mo Moore: One of the things over the last 25 years I've noticed is that as a young engineer, I didn't listen well to problems, and I still slip into that today, but when I see integrators, I wanna say really listen to your customers' problems, because one of the fortunate things about using Ignition is that it has so many potentials to solve so many problems. So focusing on the customer and their problems, if you're solving a problem, you're usually A, making the customer happy, and B, it's financially, and gratifying as an integrator, 'cause we always wanna solve problems, right?

07:00
Anh-Tuan Tran: So my take is a little bit more philosophical. So if you're a new system integration company entering the industry, it's really important to establish that culture and that set of values that's going to take you building sort of like that culture where when you go into a project, you kind of understand what your goals are so that as you enter and do more projects and you grow as a company, you always have those values to look back in so that you don't lose sight of where you started.

07:40
Remus Pop: Yeah, awesome. Like Mo, I think, for me, in what we try to do at Reply is focus a little bit more on the IT professional, and by IT professional, I don't mean service desk and help desk and sysadmin-type role. I talk more about the idea of the cloud solution architect, the data scientist, the expert in understanding how systems play at a very large scale. When we work with manufacturing customers that have 150, 200, 300 facilities, understanding how to scale an application across all of those, while maintaining security, like Leah said, is incredibly important. So I think the trends of the industry are moving much towards that cloud environment, and so I would say to any new integrators or any integrators looking to expand, take advantage of the large market of available IT professionals and look at adding someone to your team that could bolster that side of the skill set.

08:23
Brian McLaughlin: Yeah, I completely agree with what Remus was saying. I think for any new integrators now, it's going to be essential for them to develop skills in different layers of the manufacturing pyramid. And I think within our Ignition portfolio in SL Controls, we may be, I'd say, half the hires we make have high-level programming skills like database and Python and SQL and stuff like that. I'd also say it's a growing trend with customers as well that they're looking for, as opposed to, say, years ago, they might have wanted, say, a number of different integrators to do different aspects of their projects, but now they're looking for one integrator to come in, do the PLCs, do the SCADA, do the MES, ERP, and project manage it and just deliver the solution and just execute it as a turnkey solution.

09:08
Chris Fischer: Thanks, Brian. Let's keep it with you for a minute there, Brian. Next question. How have customers' pain points changed since you became an integrator?

09:19
Brian McLaughlin: Yeah, so I think the main pain point across all our customers currently would be around essentially getting real-time data from their processes. So we'd work with a lot of customers that have, you might say, a machine that's producing the correct data, but that data's siloed. It's not getting to where it needs to be in the organization. It's not getting into, say, the managers or the decision-makers' hands. So we do a lot of projects around that and, I suppose, associated with that as well.

09:43
Brian McLaughlin: You've got the data integrity. So as you bring that data up through the manufacturing layers, it's ensuring that that data's correct and it's not getting manipulated or transformed as it makes its way to wherever it's needed to be. So Unified Namespaces is kind of a good way of doing that, and we're looking into that currently.

10:04
Remus Pop: Yeah, I think for me, I've always been, I think, on a little bit of the unique side of the Ignition integrator. In the 12 years I've been deploying Ignition projects, I've never once deployed it as a SCADA. So for me, it's always been a rapid deployment, a rapid data platform. And so our customers' changes typically have been coming around.

10:23
Remus Pop: What I was talking about earlier is, how do we scale this across a large enterprise? Or how do we gain more business value? Kind of like what Anh-Tuan was talking about. How do we gain efficiency? How do we gain more profitability within the company? How do we understand how technology can solve our problems? I think the challenges that we see today, I say a lot, like before COVID, we had to sell why companies needed to digitally transform. I think COVID solved that problem for us. And now it's more about selling how companies can digitally transform. Ignition becomes that platform for doing that.

11:00
Anh-Tuan Tran: For us, our customers, their biggest pain point is the IT group whenever they're trying to implement these Ignition projects. And that becomes our pain point when we're doing these projects. So we actually have to have a dedicated group that can speak the OT-IT talk. They know the jargon, they know the lingo. And then IT operates in a totally different timeline from the way we execute projects. So it becomes a major pain point for us to try to get them to spin up VMs or give us more resources when we need it.

11:22
Anh-Tuan Tran: Especially when we're trying to get a system to perform a certain way. So that's just the reality of things. And then their IT wants certain security settings and they wanna update systems on the controls layer automatically. And that breaks a lot of stuff. So there's a lot of planning that we have to do when we're working with customers now just to make sure that we make the IT gods not get too angry at us when we're implementing our solution.

11:54
Mo Moore: So I'd say INS has always been kind of a niche-y group in the integration space. Similar to Remus, we're more enterprise-layer application. But I think the challenges we've seen over the years was Remus made a really great point. Before COVID, Industry 4.0 was growing quickly. It was kind of doing its thing. But when COVID hit, it was very clear you had to be remote. You had to have remote data. INS kind of specializes in remote communications and things like that. So we were early adopters on MQTT because as these IoT gateways and stuff were getting into the industry, we needed low bandwidth capabilities, store and forward, report by exception.

12:35
Mo Moore: I feel like the Industry 4.0 has always really taken off over the years with the help of Inductive. But I think now the challenge points have escalated and grown and morphed into more of the cloud solutions and then how do you model data. Because the pain points have changed. We've got the data now. We've solved that problem. And everyone feels really good about the Industry 4.0 connectivity. But now it's how do we use the data and how do we model it right. And then we work with teams like Remus and them who really bring that together and stuff like that. And we work with teams like Leah and them who really execute at the plant-floor layer and then into the enterprise layer. So challenging stuff like that, but partnering with other integrators and then knowing that next level of how to get that communications working at the enterprise layer.

13:19
Leah Warren: Yep, I think Mo pretty much covered it. 10 years ago, our issue was, "Okay, how do we get the data?" And that's when we discovered Ignition 'cause you used to be limited on the number of historical tags you could have without paying a lot of extra money. And now it's really morphed into, "What do you do with that data? How do you use that data to make informed business decisions?" Which has really been a theme of this conference and we've seen a lot of the ways that people have done that and a lot of the new technologies that are coming out that will help us continue to do that.

13:50
Chris Fischer: Gotcha. Okay, here's an open question. Mo, I wanna start with you, though. When building an edge-to-cloud solution, what's a common misstep integrators make?

14:00
Mo Moore: Repeat it again.

14:03
Chris Fischer: When you're building an edge-to-cloud solution, what's a common misstep that integrators often make?

14:10
Mo Moore: I'm gonna go back to his point with the IT group, right? So, as integrators, especially in the SCADA space or the automation space, you find yourself in an IT-OT convergence. So, working really well with the IT teams. I mean, the cloud-hosted solutions bring their own networking challenges, virtual networking, virtual resources, using services instead of having VMs, necessarily.

14:32
Mo Moore: So, I think a common mistake is that we try and apply our traditional on-prem models to the same concepts and the IT teams will often say, "Well, why not this service?" or "Why not that service?" or they wanna go to containerization and that's a good model to have. So, sometimes an early mistake we made when we first started getting into cloud-hosted solutions was not working well with the IT teams to fully understand their management concerns and what they would have to do and then really researching and developing when to use a service for AWS or an Azure service versus your traditional VM localized server service or something like that. So, it was a growing pain for us, but it was a good challenge. It was something that helped us learn something to be unique with it and adopt, where the technology was going.

15:26
Chris Fischer: Gotcha. Anybody else have a...

15:30
Anh-Tuan Tran: Yeah, a common mistake that we're seeing is that edge devices are sitting at the plant floor and they need to be incredibly robust and a lot of times people, they see all these different vendors and they have all these fancy edge devices, but they're not tested enough. They're not tested in that environment. They didn't take the time to understand if this device is gonna work in a dusty environment that's really hot in a panel with no AC. So, a lot of times when you're putting in these edge devices, you really need to plan the location of where you're going to install it and then who's gonna manage it and then make sure you actually have spares if it does go down for data integrity purposes. So, when you're starting out and you're thinking about implementing edge, make sure that you use a product that has a lot of industry experience in terms of trust. So, that's my advice to you guys there.

16:19
Remus Pop: I'll build off what Anh-Tuan said. I think when you do that, when you do it well, also don't be afraid of failure. Sometimes the device you pick won't work for your application or just won't be good and then when you do fail, fail quickly, right? Be agile in your... One of the problems we see when people build this kind of strategy is they don't plan for the adaptability and understanding that every factory that we go to will be different than the last. Every machine that we talk to will be different than the last. Sometimes there is no PLC. Sometimes there is no network. So, be agile in the way you kind of look at these problems and be ready to adapt when something changes.

16:57
Chris Fischer: All right, very good. Okay, next question. This is an open question for anyone who wants to answer. What are the most relevant industry trends in your business today? Anybody.

17:11
Remus Pop: I'll start that one. I'll say, I haven't heard it yet, so I'll start the buzz with AI, right? I think nobody sat in any meeting over the last year where AI hasn't come up, and so I think that's definitely been the biggest buzz. I can tell you on my team, every one of my developers has a ChatGPT Pro license. We use it on a daily basis, multiple times a day. It can be really good at repetitive tasks, answering emails, even code scripting, sample scripts. Obviously, you have to check the work. It's not completely guaranteed that it's gonna be great, but it can rapidly accelerate the time to doing certain tasks within an organization, so I think, for us, I think the biggest trend is AI.

17:47
Remus Pop: I think there is substance to a lot of it. I think a lot of us in this community are pretty used to buzzwords, and we can sometimes scoff at the idea of AI 'cause everybody's talking about it so much, but there is absolutely some real-world applications, and some people are doing some really interesting things in that space. Vision AI comes to mind, right? Like, vision checking problems have always been a problem, right? Lighting changes a little bit now. Our vision system doesn't work anymore. AI gives us that adaptability in our vision systems to accommodate changes in the environment, changes in lighting, changes in product, because they're taught what the good part looks like, and they can accommodate different things much quicker than a traditional vision system would.

18:24
Leah Warren: And then kind of going off like the AI, predictive maintenance is definitely something that a lot of our customers are very interested in. We've done a few machine learning applications that have essentially allowed them to not buy more very expensive monitoring equipment, 'cause we can kind of infer what's going to happen from the sensors that we already have. So, that's definitely been a trend that I've seen going forward.

18:49
Mo Moore: And I'll piggyback off both of them 'cause I'd like to do that. But and I'm gonna use a buzzword because you have heard it a lot this week, UNS, like, so data modeling it used to be, it was, we would, we would shove a lot of data in there. And I think a lot of us always kept kind of a ISA 95 standard as we were putting the data in, but thinking more outside the box of like multiple systems using the data now. So, like now that MQTT has grown a popularity, you have a lot more systems that can consume the pub/sub model. And so when you're talking about machine learning and with the AI stuff, a lot of that is contingent around a good data model so that it can process that data rapidly and utilize it.

19:35
Anh-Tuan Tran: Yeah. For my industry, I'm in the consumer packaged goods industry and really any industry, but AI is really popular, right? But a lot of our customers aren't quite at the level of data collection to get some of the accuracy in the modeling. So we're starting more on what we call center lining projects, which is an even easier stepping point than like an OEE or downtime tracking project because center lining allows you to kind of capture all the parameters that allows them to produce a product well. And so they're really working towards getting the analysis of building that golden batch.

20:07
Anh-Tuan Tran: And so our starting point is really just trying to figure out how to capture the right data so that they can get predictive product quality. And we find that to be the biggest ROI in terms of AI usage because if you can predict the quality of your product, then you could potentially stop a process before you have all that scrap. So the use case in AI in that space is huge. And immediately, if you can prove to your customer that you can predict the quality of a product, whether it's gonna go bad or it's gonna be produced well, the value is incredible.

20:42
Brian McLaughlin: Yeah. I completely agree with the guys on the AI looking at, it definitely an increasing trend. I think for a lot of our customers, the focus so far has been to getting data into the right hands, and it's kind of, they're getting some value outta that now. But a lot of the customers coming back and they're going, okay, what's the next thing? What's in a lot of cases, AI is that. Another trend we're seeing a lot of is sustainability. I think a lot of customers these days have goals around say ESG and sustainability, that the targets that they need to meet. And if they're investing in the solution, they want to know how that solution's gonna help them achieve those targets. I guess there's a lot of ways you can do it. Some ways we do that in an SL would be paper to glass solutions.

21:24
Brian McLaughlin: So basically, digitizing the current paper-based process to just that company's reliance on paper. And then that's in those cases, it also has, knock-on benefits as well. Like, so if you're, if say you're closing out a batch at the end of the batch, you don't have to wait till to get the paperwork and review it. And then for quality to review it and then release the data, they can, get all the benefits and like as soon as you hit the batch close or complete batch, that data's available for quality to review. So it, it kind of increases the factory's throughput, which is a big benefit to them also.

21:56
Chris Fischer: Okay. I want to, I want to keep another open question here. We've been thinking about open, or excuse me, new technologies, emerging trends. What do you see becoming less important, whether it's for the industry overall or for your customers' needs? Anybody at all? What's less important? Anything?

22:18
Leah Warren: I guess, for us it'd be like, I know people get really excited about VR applications and I heard one really cool one yesterday actually. But I'm primarily in the dairy industry. And when I think about training an operator using VR, it's just not realistic for that industry. So, I guess it would really depend on your application, but for me, when I hear that and people getting excited about that in dairy, I'm like, that might be a little, a little past what you need. Yeah.

22:48
Chris Fischer: Yeah.

22:50
Remus Pop: I'll take a stab. I think, one of the things I've noticed is that people are more willing to accept, non-recognized brands. I think Ignition has been a big part of helping that out. But used to walk in a room and, and say, if you, what's the, the, the common saying, right? "Nobody ever got fired for recommending SAP." I think that is shifting quite a bit. It's less common for people to be reluctant to try and adapt to different technologies because technology startups have just ramped up so much recently. And I think, so people are more interested and more open to maybe piloting with a new startup or with a new capability that some companies trying to do. You know, probably 20-something years ago, it was the same, same with Ignition, right? It was probably really difficult to sell ignition in the customers that were down the road with a, with a Wonderware or something else. And I think this community and this company is a big part of.

23:43
Anh-Tuan Tran: The trend that I'm seeing is that a lot of our customers are not hiring that PLC manager for their facility, which is good for us as system integrators, but they see that automation guy is less important, you know? So as companies are building new facilities, it's becoming more automated, more autonomous, a lot of times it's kind of challenging for us to not have that point of contact when we're doing projects just because they don't have somebody. And then immediately on the IT side, they feel it's less important to have a large IT team. So they're outsourcing that service to another IT corporations to handle their IT service. And that creates challenges for us, because sometimes you don't get the right folks that really understand that customer. So we have challenges there, but at the same time, it also creates a lot of opportunities for us in terms of other project offerings that we can do. So that's, it's less important, but they're gravitating towards system integration anyway, so that's, that's okay for us...

24:42
Chris Fischer: Guys are making lemonade.

24:43
Anh-Tuan Tran: Yeah.

24:47
Brian McLaughlin: Yeah. I'd say what's becoming a low, like, say Unified Namespace and MQTT, they're, they're not, new technologies by any means. But a lot of our customers would be in, say, the regulated sectors like say pharma, medtech, and traditionally due to high levels of regulation, they're quite hard to, due to high levels of regulation, it's kind of, they're slower to adopt new technologies. But I definitely see a trend of that changing in the last, say, six to 12 months. And there's more and more customers asking about it. For regards to what will become less so in the future, I'd say maybe Windows-based communication like OPC, not maybe today or tomorrow, but maybe 10 years time like that.

25:26
Chris Fischer: Brian, let's hang with you for a minute. How do you manage the expectations of a customer who's stuck on a legacy brand?

25:34
Brian McLaughlin: Sorry, can you say the question again?

25:36
Chris Fischer: How do you manage the expectations of a customer who's stuck on a legacy brand?

25:43
Brian McLaughlin: Yeah. So I'd say... Sorry, you might just, kind of mind's going blank. You might skip over me.

25:51
Remus Pop: Yeah, I'll jump in. For us, we've developed this, this concept of a hackathon. And so in order to get customers over this reluctance to be able to adapt to new technologies, they wanna, there's a big idea of like, well, show me, right? So, we have this free offering that we do for our customers where we will show up in their factory, enabled with Ignition and sometimes some Opto 22 and some Snowflake capability, and we'll launch and build a pilot in real time in a matter of a couple of days.

26:16
Chris Fischer: Yeah.

26:17
Remus Pop: And so that, that's been a way that we've been able to kind of break through that reluctance of, "I don't wanna spend $200k on some new and system integration platform" or something, some project, before I know that it's gonna work, right? So everybody wants the comfort blanket of knowing that it's gonna work. So a hackathon is a good way to do that.

26:35
Leah Warren: Yeah, yeah. Demonstrations are extremely effective. I mean, we don't really have to sell much after we demo it, because the customers sometimes don't know what they don't have. So, when you show them like the potential and the opportunity, we've seen a lot less pushback.

26:54
Chris Fischer: Yeah.

26:54
Leah Warren: And then kind of going back to, I forgot who was saying it, but the adoption of technology that's maybe not as known or doesn't have the name brand. It used to be selling Ignition was hard 'cause they didn't trust the longevity, they didn't trust the support. It wasn't a name that they recognized. And we definitely have a lot less of that now. People aren't saying, you know, we're not having to convince people on Ignition, let's say they're telling us they want it, and we're saying, okay, this is what we can do with it.

27:27
Mo Moore: Yeah. Yeah. I mean, based off what Leah was saying, if you look at the cost factors and you look at the way like Inductive comes in and aren't charging by tags, the simplicity of selling it the simplicity of the support cost the wide range of integrators, right, that are out there now it really becomes a self selling solution. And you become more of a, "now how do I help you implement this?" less. We don't have to deal with a lot of legacy products at the application layer that we are in enterprise, but it really becomes much easier to sell it. And then I would say, like traditionally speaking, Inductive has kept up really well with security, with all of the IT convergence stuff that they need to, so it just becomes an easy adopter. Legacy products, just a lot of them just don't compete in that way.

28:16
Anh-Tuan Tran: Yeah. For us, we use a scorecard system. So, we're an independent integrator, we're technology agnostic. So what we do is we basically take the business drivers that they have, and then we have a scorecard, which is just a number of measurable criteria that they can look at. And so we can coach them through the pros and cons of each of the platforms that they can migrate to if they wanted to. But then we kind of give them a lot of clarity in terms of why they should select this, because it matches and it rates the highest based on what they're looking for. So, it's really based on their needs and then what technology makes the most sense for them.

28:51
Chris Fischer: Gotcha.

28:52
Brian McLaughlin: Yeah. I'd say also it's important to take a phased approach to the migration. Also, like, it's not very often you get a, an opportunity to go in with a big one big bang approach and replace everything. But if you just take small segments, kind of work through that and replace it with a system like say Ignition, then you can prove out the benefits. And I think from our experience, customers are more receptive to like an overall obsolescence plan than to replace their all their systems.

29:18
Chris Fischer: As a general reminder, if you have customers who are interested in switching over from a legacy brand, reach out to our Sales and our Sales Engineering department. We're happy to join those demos, help them get them on the right path with Ignition. Next question though. This one's sort of a two-parter. We often hear of integrators needing to turn down work because they're busy, they have too much going on. So how do you approach and vet business with a new customer in a competitive landscape? Anybody?

29:53
Anh-Tuan Tran: We don't turn down work.

29:56
Anh-Tuan Tran: Well, we rarely do. And if we do.

29:57
Remus Pop: Good answer.

30:00
Anh-Tuan Tran: Having a project that we feel we can't do it, we will actually collaborate with our other offices. We have 17 locations worldwide. So there have been a lot of instances where we've actually passed work over to another office so that they can handle that work. But it's really just collaboration. And then honestly, if the work doesn't make sense for our company as a business, we have a lot of partnerships that we'll leverage and then we'll give them that lead. And then if we can supplement in any way based on that project, we will collaborate with that team.

30:29
Mo Moore: Yeah. And I'll work with that one because I've worked with Leah before. I've worked with Remus before. There's a lot of things where INS doesn't play and recognizing that, and then you always want to promote the technology, right? So doing something you're not comfortable with or you're not skilled with doesn't mean it can't be done. It just means that you lean on good partnerships. You know, like we've worked with Tamaki multiple times in different solutions. I've been brought into different environments where I just didn't feel like INS had that.

30:58
Mo Moore: And so it wasn't as much as turning down the work, but recognizing what, like what you were saying, is that it may not be the right fit, but don't let them walk away with a bad taste for the technology, like they can't accomplish it. Partner with good integrators like you see here, that's what ICC is really about, right? So, get community to work with everybody and get, and make that happen for the customer.

31:17
Remus Pop: Yeah.

31:18
Leah Warren: Yeah. Partnership is a great way to handle that. For me, when I think of like 'cause a lot of what we do is the process control on the plant full floor. And Ignition is definitely our preferred platform, but one of the reasons for that is that we've built tools into Ignition that assist us in like the commissioning process. So we have the dynamic trending built in, we have plant replay on all our screens. And when I think about trying to commission a process without those tools, that I would prefer not to do that. So I guess if we're in the position, if we have the luxury of being too busy, then if a customer's insisting on using a platform that's not Ignition, I am probably going to reach out to another integrator that does installations on one of the other legacy platforms.

32:08
Remus Pop: Yeah. I think I'll just echo that right. Reply is a 20,000 person company. So we generally don't turn down work, but we know what we're good at and what we're not. And so I mentioned earlier that in the 12 years of working with Ignition, I've never deployed it as a SCADA. So if some, somehow somebody came to me to deploy Ignition as a SCADA, I'd recommend one of the many awesome integrators that we've worked with in the past. And I think just, I even, I think during COVID, right, during, during our watch party with Mo, we, we did a panel on what we called co-opetition. So it was three different integrators talking about this partnership idea and how we share even sometimes resources if the ability to work on a project that you wouldn't really wanna work on, but you don't have the team members available there, you can partner with another company to bring in some resources.

32:50
Remus Pop: So I think, just echoes the idea that the partnership is so strong in this, in this space that we're not worried about giving one of our competitors some opportunity to get to win some jobs.

33:04
Brian McLaughlin: Yeah, I'd say for us, I can't think of a time that we've actually had to turn down business or we couldn't, achieve a customer's what they wanted to achieve. What I would say is we kind of, we could try and be transparent from the start. So we have the initial engagement and we're scoping out the requirements of the project. We try and understand is it something they want to say very soon. Like, can I to say unlock a production backlog, or is it something that maybe it's like four or six months, like it's more of a long term. And then we, we try and work with them, tell them the resources that we have, and then maybe it's something we plan for six months down the line where we might have a resource cap. So we try and get that, that pipeline there that we can kind of try and everyone meets everyone's expectations and everyone's happy.

33:45
Remus Pop: Okay. There's probably a sales plug for a CRM system in there somewhere.

33:48
Chris Fischer: All right. Thank you, panel. Alright, well let's get into some Q&A here folks. So, we've got some runners circulating through the audience, they've got some microphones here for you. Anybody have any questions for these Ignition pros here? I think you're the first one.

34:07
Audience Member 1: Can you hear me? There we go. It's a question for Anh-Tuan. I was interested in your response about in the CPG industry, for using center lining for identification of golden batch, using AI for that. Can you speak to like what types of AI data, data analytics, that are you commonly use for that? And if there are certain sources of data that are most helpful for that?

34:28
Anh-Tuan Tran: Yeah. I can speak a little bit. I'll kind of give you a use case so that makes a little bit more sense. Say for example, you have a customer that's cooking a product and if the outside temperature humidity changes, it impacts their cooking settings, right? A lot of times you're relying on tribal knowledge of the folks who operates that equipment to get the right machine setting so that you can continue to cook the right product quality. And the duration in terms of how long it takes them to get that right machine setting, could be hours.

35:01
Anh-Tuan Tran: And so in that period, everything you cook, you scrap. So if we can take all the information that's coming in from the machine setting as well as the parameters of all of the process parameters, including the humidity data and model off of that information to figure out what the product quality output should be, you can operationalize that model in the production space, so that you can predict the product quality and what the right machine settings needs to be to give you the right outputs.

35:31
Anh-Tuan Tran: So a good example is you know, like, like a SaaS engine has a lot of the modeling tool that we will partner up with SaaS and give them the information cleanse, right? And then they can give us the model and then we can operationalize it and then pull in the live data and then it could feed us the machine setting predictions. And then when you implement it and you could actually see the product quality getting to the right state quicker, and then immediately you can see the value in having something like that. Especially if you're losing guys that have been there in 20 years and they know how to work those machines, you lose that knowledge, the newbies, it takes them a lot of time to actually get the equipment up to speed in terms of like the quality that they're looking for. So that's like an example of a use case where the data is important.

36:20
Remus Pop: Yeah. If I can add on, I think from a strictly tools perspective, I'd look a lot at like AWS SageMaker, AWS Bedrock, OpenAI has an open API that you can use to do ChatGPT-like functionality within an application. Obviously Microsoft Copilot. Copilot's doing a ton of stuff in this space. If you wanna go the Microsoft route, again, the OpenAI platform, but and even right outside in the hallway, Snowflake, right? Snowflake has a ton of AI and ML tools built into the platform. And because of the Cirrus Link and the connection between Ignition and Snowflake and think it, it'd be a really good place to start.

36:54
Chris Fischer: Alright. Yeah. It looks like we might have a wait now. Yep. There we go. Right there.

37:01
Audience Member 2: Alright. Remus, you mentioned how COVID opened up the remote access door for us and that is very true. But now they're cooperative to a point, but every IT company or every IT group wants a different VPN and I'm dying of VPN overload. Any thoughts on where we might get to some sort of cohesive approach?

37:24
Remus Pop: I think unfortunately we're gonna be stuck in the world of some sales guy that convinced some IT guy that this is the best VPN on the planet. I, unfortunately, don't see an end game unless somebody comes out with some kind of unifying API connector, for VPN connectivity, right? So everybody can kind of have their own and almost like a MuleSoft does with managing APIs. Some, there'll be somebody that makes a software that manages the thousand different VPNs you gotta deal with. But unfortunately, I live it daily in my life, right? Every single IT company that we work with has some sort of way they want you to connect to their systems.

38:00
Mo Moore: Yeah. I'll go with what Remus was saying, but I am starting to see a trend, 'cause all of my engineers are saying the same thing, "I don't want another VPN client." So, they have a thousand VMs spun up to handle each customer, right? But what I am starting to see a trend in, especially in the cloud technologies, is these bastions, right? So they're AWS and Azure offer these bastions, which is actually quite nice in the sense that you don't have to install anything and you don't have another virtual NIC on your machine.

38:27
Mo Moore: So that's becoming a lot more popular for the VPN solutions. And IT feels a lot better about the bastion solution 'cause they control the client. So as long as they have an open way to be able to add software to that bastion and things like that, it's been working better for me and our team anyway because, and we'll actually ask them, "Have you attempted this? Have you seen that?" And sometimes you can steer the customer to that solution. And then with the federated model and like identity providers, it makes it a lot easier to say, just add our group at our profile to your bastion setup so that we don't have to have a thousand accounts.

39:07
Audience Member 2: So it sounds like we have to do a little teaching, we have to teach them how to do this.

39:10
Mo Moore: Absolutely, that's a solid point. That's a good way to put it.

39:13
Chris Fischer: Okay, next. Thank you. Alright. Anybody else? We have to, we missing anybody?

39:26
Audience Member 3: Yeah. Yeah. I so given all of the, excuse me, IoT and digitalization efforts that everybody's referred to, it means more connections and more networking and then more vulnerabilities. And so I just wanted to, if the maybe each of the panelists could say what kind of cybersecurity best practices do you guys employ yourselves and with your clients? And then what advice would you have for others who are not as far along the learning curve?

39:55
Remus Pop: I'll start, I'd say, so I am by no means a cybersecurity expert and that's why I hired one. And so I call him on the phone and I say, "Hey, we're gonna build this platform. Can you be part of the architect team to make sure that everything we do is secure?" There's a lot of public documentation. You know, I think [Inductive Automation CTO] Carl [Gould] was up on stage talking the other day about some of the security things that they go through. Leverage the understanding that most of the companies are doing that on their own and try to leverage companies that are already taking advantage of that on their end.

40:25
Anh-Tuan Tran: Biggest one, oh, sorry. Go ahead.

40:26
Anh-Tuan Tran: The biggest one for us is just buy managed switches. Stop buying unmanaged switches guys.

40:32
Mo Moore: Thank you. That's a great. That's... Thank you.

40:35
Anh-Tuan Tran: Yeah. And you're installing it in panels, but they, they're a smaller form factor managed switches and it just makes our lives so much easier, especially from being able to lock certain things down, having more control. So really, I mean, that's a best practice going forward is like, if you're still buying unmanaged switches, you guys should stop, just stop.

40:53
Mo Moore: Yeah. I'll say that, we get approached with this a lot, because our company does a lot of industrial networks, and so the first thing we start with is the concept of the zero trust, of course. Right? So you need to, it's really hard on the plant floor to enforce operators to have logins. It's, it's not common because it's too, it adds a lot of complexity, right? So, we usually start with a layer of putting in network management tools and security monitoring tools into the industrial network so that it can look for changes in things like PLC code change or this device was never on the network before and it has remote access. Why was this here? By working with the IT groups and putting that layer of that network monitoring in there and having built-in security that's looking for like you know, changes in packet styles and things like that that adds that layer.

41:45
Mo Moore: And then it allows the IT department to feel like that DMZ layer into the OT layer is more secure and that you're watching it. And that you're not gonna have intrusions coming in from that angle. And then the second part of that, of course, is doing the right thing to have the zero trust model, multi-factor authentication. Those are things that just have to be enforced these days because it's not an if it's when, and if you go and look the minute you put something out on the internet, it's immediately hit by bots and other things from different places looking for vulnerabilities. So, you just have to have that authentication model in place.

42:22
Chris Fischer: Good. There we go.

42:28
Audience Member 4: Just curious if you have customers, potentially some of the more price-sensitive ones, that are having multiple applications in one Ignition server, multiple vendors working in one Ignition server, and what, what your experiences have been in that environment, and if you're coaching, guiding those customers on any better practices to have vendors play together or not have one knockout a server of some way, shape or form?

42:54
Mo Moore: Yeah. I mean, I think Remus you've seen this too, like, containerizations become a good part, big part of that, because then you can layer in your resources on the containerization layer. And because you can have things like Kubernetes and, and really orchestrate your containerization deployments and monitor it, it allows you to have them play in the same spaces fairly nicely as services on server level like an ESXi host or something like that. You get the same principle, right? You gotta make sure that everyone gets their slice of resources and how they're gonna work together on that. On the IoT gateways, the containerization is kind of really important too, because then you can set the resources and not go over the over bounds and then you also set the security level of what the operating system can do and access the containers and what they can do and not do that. So that's kind of...

43:40
Remus Pop: Yeah. I think what the release of [Ignition] 8.3, the majority of that problem will go away.

43:43
Mo Moore: Yeah. Yeah.

43:44
Remus Pop: Right? Now with everything in the file system, you can leverage GitHub or any flavor of version control that you like. With the deployment modes, I think the majority of that problem is likely gonna go away in the next little bit, right? Just pull a branch, do what you need to do, submit it back and away we go.

43:57
Anh-Tuan Tran: So now it's just a waiting game. Yeah. January, I think is what you said.

44:02
Mo Moore: We need April...

44:05
Anh-Tuan Tran: December beta.

44:06
Remus Pop: Yeah, December beta. I definitely just wait until 8.3 and you're, you're good.

44:09
Leah Warren: That'll play a big role. And maybe on like a lower level, kind of what I hit on earlier, is just documentation and having a site-documented standard that any integrator that is in that project is utilizing. So we've helped a lot of sites that we've worked at define a standard document, the standard, and then enforce a standard that all integrators are, are using when it comes to working on their project.

44:33
Mo Moore: Yeah, it helps a lot.

44:36
Leah Warren: Yeah.

44:36
Brian McLaughlin: Yeah. We work across say the dev, QA, and prod environment, which it can't help say if you have multiple developers on dev looking, if they can, if they have an adverse effect on something, there's less risk of it, having an adverse effect on production then. And also we use a lot of containerization as well, so that definitely helps our life.

44:57
Chris Fischer: All right. Well that pretty much puts us at time, folks. Please do give a big hand for our panelists here. We've got Leah, Mo, Anh-Tuan, Remus, and Brian. Thanks everyone for coming. Enjoy your lunch.

There’s so much going into 8.3 that we need a few sessions to talk about it all! Join us in this first of two sessions where we look closer at a few exciting changes happening at the platform level, and what it means for deployments in the future. In this session, we’ll focus on changes to the platform, such as the file system, API access, and secret management.

Transcript: 

00:07
Carl Gould: Hello, again, everybody. In case you forgot from half an hour ago, I'm still Carl Gould, Chief Technology Officer at Inductive Automation.

00:15
Drew Miller: And my name is Drew Miller, Product Manager for Ignition Applications.

00:20
Carl Gould: So we covered a lot in the keynote about these new features of 8.3, but at a pretty high level. So in this session, what we're going to be doing is digging a bit deeper specifically into some of the updates to the platform, hopefully explaining in some more depth and detail about how these things work. And then, in this session, we're gonna be able to open it up for an open Q&A after we're done, so you can all ask any questions you might have.

00:46
Drew Miller: That's right. With Ignition 8.3, it's a major release that we feel has something for everybody. From small, single gateway implementations to enterprise-wide, multi-gateway, deployment and coordination, there are just so many features that we've packed into this release to help you take Ignition further.

01:05
Carl Gould: Yeah, so many different features that we sort of struggled with how to structure these talks without it seeming like we were just going through this giant basket of features. So, a literal basket of features to go through. Because, you know, we are not above a cheesy prop-driven joke.

01:28
Carl Gould: Whatever, we're just going to roll with it here. So we are thrilled to share with you today this bushel basket of features that will be available with Ignition 8.3. Alright. Let's see what's up first.

01:38
Drew Miller: I got something here.

01:40
Carl Gould: A painting. What could that be symbolic of?

01:44
Drew Miller: Yes.

01:48
Drew Miller: So the first thing we're excited to share today is the brand-new Ignition 8.3 gateway UI. And what a beautiful sight it is. I thought it resembled more of a Van Gogh than a Picasso, but I think this one was cheaper on Amazon, so we'll stick with this one.

02:03
Carl Gould: So we started with a blank canvas, and we have painted an entirely new user interface for the gateway web UI. This fresh new UI was also designed primarily to just help you get things done more quickly. We rebuilt it from the ground up, as I've said, using new, modern web development technologies, which really makes the UI much snappier and more responsive. This was a pretty massive modernization overhaul, which has also allowed us to introduce some pretty key updates to the overall experience.

02:35
Drew Miller: So let's cover some of those updates. The first one to highlight here is that we've completely reinvented the gateway navigation. The entire architecture of the gateway has been renovated and reorganized to be more intuitive. We've introduced well-thought-out sections and categories so that every page within the gateway has a fitting home. Device connections, navigate to connections, devices. Need to update security settings? Try Platform Security. But if you really can't remember where something is at on the gateway, you can now search for it.

03:08
Carl Gould: Yeah, we've really worked to significantly improve the global search functionality and put it front and center in this UI. It allows you to search through everything on your gateway. So it'll search through all the pages in the navigation structure, but it'll also search through all the items that you have configured so that once you've found what you're looking for, click on it, and it'll just navigate you right to the section of the gateway for that item.

03:32
Drew Miller: Another new element to make the gateway more efficient is this merger of status and configuration. Now, when you navigate to a page, you'll be presented with both aggregated and itemized metrics while also having the capability to create, edit, delete, or diagnose related items, all without leaving the page. No more toggling back and forth between the status and configuration sections as they exist in 8.1. Complete all your related tasks in one spot.

04:00
Carl Gould: We really understand that so many of you deploy Ignition at really impressively massive scale. So, a huge part of this was to design a UI that just works gracefully as your Ignition systems grow. So all of the items in the tables are presented in a paged manner so that the UI's responsiveness doesn't degrade as the number of items increases. All the tables are filterable and searchable and sortable, and they allow for multi-selection with bulk editing so you can quickly take actions on many items at once.

04:35
Drew Miller: And then, lastly, with the new gateway, you see we have Ignition, but now we have launch. So like the gateway itself, we've once again reimagined how users can launch software directly from the web UI. With the new deep link launchers, users can open the Designer, launch Vision clients, and Perspective sessions or Workstations, all with the click of a button. So this saves time by skipping the step of opening the appropriate launcher and then finding the application that you're trying to run.

05:05
Carl Gould: Those of you like me who mourned the loss of Web Start, it's finally back. Yay. Okay, so we're just sort of scratching the surface here. There's really a lot to see in this redesign. It's packed with a bunch of clever features that support a lot of the advanced features of 8.3. It's better looking, it's more intuitive, easier to use, and should really help you just do things quicker, diagnose issues more efficiently.

05:31
Drew Miller: But there is more than what meets the eye with the new interface, and that's because Ignition 8.3 comes built in with a complete RESTful web API to configure the gateway. But we're gonna touch more on that later.

05:43
Carl Gould: Yeah, but on the topic of APIs, I'm dying to know what else is in this basket.

05:47
Drew Miller: I have something. Oh, let's see. Oh, we got a little history book here. Ooh.