Modern manufacturing generates vast amounts of data from diverse sources, creating challenges in data integration and utilization. Traditionally, data silos have hindered the scalability of analytics across manufacturing and supply chains. The Snowflake AI Data Cloud breaks down these barriers by seamlessly converging IT and OT data, accelerating smart manufacturing initiatives. Join us to explore how Snowflake empowers manufacturers to harness the full potential of their data, driving innovation and operational excellence in the era of AI and Industry 4.0.

Transcript:

00:05
Greg Sloyer: Well, thank you for coming. Sort of during lunch, before one of the keynotes, I'd like to thank Inductive Automation for having us present again. This is our second year presenting at the conference. My name is Greg Sloyer. I'm from Snowflake. I am the Manufacturing Industry Principal, so I look at the business side of things from Snowflake. All the usual, do not buy or sell stocks based on what I'm talking about. Don't plan your 401(k)s and retirement. I've been doing data and analytics for manufacturing, supply chain, operations, logistics, all that for abo ut 17 years now, not all of which was Snowflake. Prior to that, I had 20 years in the chemical industry, DuPont, BASF, and I ran global supply chains and logistics and all sorts of things like that in the chemical industry. So, why is Snowflake at the Inductive Automation ICC conference? I will set this up by saying, Snowflake, how many people are familiar with Snowflake today? Okay, so about half. So, Snowflake started out as a data warehouse, data lake kind of thing in the cloud.

01:17
Greg Sloyer: It's been about 12 years now, and in 2014, the big thing here is we operate across AWS, Azure, and GCP, so all across all the major three clouds. Our big thing, especially in the 2018 timeframe, when you see this disrupt collaboration and this cool-looking thing in the middle, which is maybe a little hard to see, but there's a lot of starbursts and fireworks-looking things, that is data sharing in Snowflake. This is between customers and suppliers, between partners and OEMs, between logistics groups and manufacturers, between what we call our marketplace providers, so data providers in Snowflake, providing things like weather data, commodity pricing, freight rates, logistics, things like that. There's about 2,600 data sets or so in Snowflake that are available. Really cool thing is we do this all without moving data. We're not moving data in Snowflake. It is pointers. We've gotten rid of the ETLs and FTPs and emails, and heaven forbid you put stuff in CSV files and ship them over to a friend of yours. This is all essentially permissions.

02:39
Greg Sloyer: You give permission for somebody to see a table or set of data, or they give you permission to see a table or a set of data or a set of tables. Once that permission is granted, that data shows up in your database like it's one of your tables. So now you are extending your, to incorporate that data in analytics and reporting; you extend your SQL with a join statement. That's what it comes down to. That was in 2018. We've been exploiting that, and more so we have been now building applications. So you're seeing major applications like Blue Yonder for supply chain and others replatforming to Snowflake. And this has really been the progression, and we continue to add on to this. A lot of AI, Gen AI, ML types of capabilities, I'm gonna talk about a couple of them today, being brought to the data. So what we didn't want you to do is spend a lot of time bringing all the data and talk about IT data and OT data today, bringing all that to Snowflake just to then pull it out and have to do something else with it somewhere else.

03:45
Greg Sloyer: The idea is let the data there; let's bring all those capabilities to the data so you can operate all within Snowflake. We launched what's called a manufacturing data cloud at Hannover Messe about a year and a half ago, April of last year. And we looked at what was needed in the industry, manufacturing in general, and what were a lot of these opportunities people are struggling with, things like that. Hopefully, a number of these resonate. So one was IT and OT convergence. Okay. This has been a big topic now for a number of years, and Snowflake had been great at bringing in typical ERP, especially like SAP data, into Snowflake. We've been doing that for a number of years. Lots of big customers who are doing that today with not just one SAP or ERP system but 10s, 20s, 30s. And all of this is published when I provide a name, but Carrier, for example, has 140 ERPs that they consolidate their data into Snowflake on. What we weren't as strong was on the OT side. So bringing in the shop floor data.

05:15
Greg Sloyer: This is where we really pivoted about 18 months, two years ago, working very closely with Inductive Automation, Cirrus Link, and a number of other partners to provide different architectural ways to bring the shop floor data into Snowflake and take advantage of the time series capabilities and a number of those other capabilities we'll talk about in terms of AI, ML, Gen AI, things like that, to the data, which is sort of that third point, which is bringing and really deploying advanced analytics to the data. The middle one is taking advantage of that data sharing. So this is broadening the visibility outside of IT, outside of OT, so the enterprise, and really extending that to that partner network, broadening the view of the supply chain, incorporating that visibility into the decision and analytics process. Really taking advantage of a lot of these different Snowflake capabilities. The difficulties, and I'm sure many of you have experienced this, is that for years, decades, the shop floor manufacturing sites have generally been an island. Different organizations, different functional reporting roles from that systems sort of standpoint.

06:18
Greg Sloyer: OT sometimes reported into the CIO, but generally not. It reported into VP manufacturing. This created a lot of separations from a systems standpoint, made it not technically difficult but more organizationally difficult to sort of integrate and bring that data in, integrate it with sort of the rest of the data. There's some architectural discussions that happen, things like that. So different opportunities. And for those of you who have multiple plants, what I always say is if you have 50 plants, you probably have 48 different MES, MRO, LIMS, or QM, and all those systems because a lot of those plants came up from acquisition. As I said, it's an island. Investments weren't made, or if it wasn't broken, we're not gonna fix it. That kind of thing. So a lot of that is changing, but also the architectural patterns that you have to utilize that data, especially to bring it to the cloud, need to account for the fact that all these plants are different. They may have different protocols, different configurations, all that kind of stuff. So the solutions have to be adaptable.

0:07:38.7
Greg Sloyer: And that's really where, in partnering with Inductive Automation, all that, we've helped simplify the environment of bringing that data into the cloud, into Snowflake. So let's first take a very broad view as we look at the supply chain. So as I mentioned, we have everywhere from marketplace providers with commodity data, pricing, availability, geopolitical kinds of things that impact supply, the logistics areas, really bringing that sort of view to the plant, as well as then when you look outside from the customer standpoint, especially if you're building connected products, so products out in the field that are generating their own data after they've left manufacturing. How do I incorporate and create that visibility up and through the supply chain, through the ecosystem, to be able to make decisions more holistically to not just help manufacturing but to help that whole enterprise environment? And then this is the thing we were really putting in 18 months or so, two years ago, which is that ability to get much more fine-grained, granular data at speed.

09:04
Greg Sloyer: I won't call it real-time. Let's call it near real-time into the cloud. This is not replacing shop floor systems. If you have a safety system, your cloud is not your best spot to put those. That's gonna be edge-driven kinds of stuff. But as we look at how do I take advantage of that data, how do I bring and broaden access to it, how do I look across those 50 plants, how do I run much more advanced mathematics on that data to do root cause, cycle time, predictive quality, all those kinds of things? That's really why we're pulling that data into the cloud and combining it with a number of other components of the data. For example, let's say you are great at doing quality control and things like that, even looking at that from the shop floor, the isolated plant level. What we wanna do is show that vision extending that supply chain to say, okay, that's not the only variables going into your manufacturing facility. Your supplier quality, that delivery variability, all of those things come into play when you start looking at quality or predictive maintenance, those aspects. And then how do returns, how does warranty quality, for those of you more on the discreet side, how does that impact and how can I utilize that information from customer service, from field maintenance, things of that nature to see what that potential root causes were that started in manufacturing and started in supply?

10:37
Greg Sloyer: So again, being able to broaden that view for those organizations that have started moving beyond doing really cool and fancy analytics on their shop floor data, how do I paint that vision of the future? And this is where we really see the extending of that data and incorporating more of the IT types of data into those decision processes. So Snowflake has many, many more partners than this. These were the partners as part of our manufacturing cloud launch. Marketplace partners, there's 2,600, 2,700 different data sets in the marketplace, but there's everywhere, as I mentioned, financial data, there's ESG data. If you type in ESG into Snowflake marketplace in the search, you're gonna come up with 40 or 50 different data sets that are available, freight rates for kites and dart, things of that nature. From that perspective, again, to help provide that greater visibility. As I mentioned, Snowflake has really been doubling down in terms of applications and the capabilities there, building those on Snowflake.

12:00
Greg Sloyer: So Blue Yonder and a number of others are replatforming. In a lot of cases, there's ones that were built specifically by companies on top of Snowflake, taking advantage of that power of the cloud and cross-cloud. So as they build something, it's not just in AWS or in Azure; it goes across all three. And then system integrators, the SIs there. And again, many, many more are partners. But these were ones that stood up and said, I have built in Snowflake a supply chain or manufacturing or operations type of solution with a customer. And they're raising their hand and going, "Yep, they did a great job. We did it all in Snowflake. And that's how they were on this list." And this continues to expand as we work through. The main areas I mentioned so supply chain optimization, smart manufacturing, and connected products are the three areas where we start utilizing the manufacturing data, the supply chain data, and that sensor data, whether it's coming from the shop floor or from connected devices out in the field, to be able to really provide that visibility, take advantage of the cloud infrastructure.

13:23
Greg Sloyer: And depending on which booths you go to behind you here, you'll see slightly different versions of this. This is my extended version. And sometimes today if I get surprised by a slide, it's because somebody's legal, they're legal, our legal, somebody's marketing department got a hold of them. So I always enjoy this 'cause then the slides are as much a surprise to me as they are to you. So with Ignition, and we've had this now in place with them a little over a year, I wanna say closer to 18 months that we've been working with Ignition or Inductive Automation and Cirrus Link. But this is the easy button for getting data into Snowflake. This is zero code. When the part of the secret sauce is that IoT bridge for Snowflake that is available via Cirrus Link. And this drops the data in from Ignition. So not just the tag data, but the metadata all around that, that structured data. So all of that lands in Snowflake. And if you have a chance to see a demo, Arlen Nipper, I don't know if Arlen's in the audience today. Arlen and others have done this many, many times. I'm probably on many, many calls per month with him with different customers and prospects.

14:55
Greg Sloyer: And within that demo, Snowflake goes from knowing nothing about your shop floor to knowing everything about it that's coming through Ignition. So very, very fast, very, very easy method for getting the data into Snowflake. And these are some of the reasons why we're one of the partners of this versus some of the other ways you can land that data within the cloud is we really looked at this with them in the process engineer. So the plant is driving the configuration in Snowflake. Snowflake is not defining a structure that you've got to be so many levels deep and it has to have certain kinds of attributes and all that. It is driven from the edge. So the plant defines how you look in Snowflake. Snowflake does not define that. That's one of the keys. And then some of these other nuances, for those of you who get into the much more excruciating detail about data types and things like that and what can you land. But we're landing this all with MQTT. The cool part of the demo for me in terms of the processes within Snowflake is that MQTT is great for transmitting data and for storing data.

16:22
Greg Sloyer: Really, really small footprints for both. Allows you to go very quick, allows you to get the data up because of that event sort of driven change control that they have. Not so great for BI and for analytics. It has lots of nulls. Mathematics tends not to like nulls, and BI tends to not like a lot of zeros with a spike and a lot of zeros with a spike. Snowflake's got a, we use views in Snowflake, so you're not gonna repopulate and have to store all that data. But from the view perspective, it's hydrating those nulls with the previously good value. So now you have an analytic data set that your data scientists tend to like without having to code anything. This is out of the box. It's driven the moment you've set up this connection. And your BI tools like it because it's not that flatline spike, flatline spike. So, great. You got the data in Snowflake. Now what can I do with it? This is where the past year or two, Snowflake has been bringing in a lot of AI, ML, Gen AI capabilities into Snowflake. We continue to release new stuff. This happens to be one of our, I'll call it an easy button.

18:01
Greg Sloyer: 'Cause different levels, different organizations have different capabilities around data science, around analytics use, things like that. And we have for the data scientists in the room, Python, Java, Scala, all that can be done in Snowflake. It's not just a SQL house. So you can be writing all the cool data science stuff. I don't think I have it on here, but we're in the booth right across the hall. For those of you into optimization, you can be running optimization, mathematical optimization in Snowflake through the Python libraries. It's really cool. I've been, in the '90s, I watched optimization fail. And I'll talk a little bit on why I think it failed. But the ways we're getting and the capabilities that now are being brought to this data are really, to me, driving a lot of really cool stuff happening in manufacturing. But this two lines of code here with anomaly detection, this is using an ML function. I think of this as the trend function in Excel. So for all of you who are familiar with Excel and you use the trend function, all you had to know to generate a forecast or see the trend of data was trend parameters, and what are those two, three, four parameters I had to put in the trend function.

19:21
Greg Sloyer: You did not have to know the mathematics behind it was least squares at the time. You didn't have to care. You could just write a trend function. This anomaly detection, and there's about a dozen of these, what we call Cortex ML functions, that are available is something similar. You have to know the parameters, just like I had to know with the trend function. But now I can run an ML-based, I think it's gradient boost, anomaly detection on the data as it lands. I don't have to be a data scientist to apply that mathematics to the data. So there are functions like forecasting, and there's a couple of others that are out there that are more manufacturing-based. Like I said, there's about a dozen overall. But the ones I tend to see for manufacturing, supply chain, or anomaly detection, forecasting, and there's some contribution factors, things like that, that really get exciting, 'cause you're applying ML techniques without having to be a data scientist. So simplifying this approach.

20:22
Greg Sloyer: The screens here that I'm showing are actually built in what we call Streamlit. This is a Python-based graphics package that is in Snowflake. So the data does not have to go out. It will not compete with a Tableau or a Power BI. We can also go to there. So if you wanna do really cool and fancy dashboards, super. We operate with those. But for folks, data scientists especially, who wanna just show quick, easy visualizations of the data, of the results of their very cool mathematics, this is available for them as well. So why do I think optimization failed? But why do I get nervous about being able to use advanced analytics broadly across your organization? And I'll point to this and go, there's different reasons. But the biggest one, and why I think in the 90s optimization failed, for example, and what I don't wanna see with things like Gen AI and AI and ML, which are really cool tools, is that we had organizations wanting to go from here to here without doing the groundwork in between. There was too much change management.

21:33
Greg Sloyer: There was too much. There was not enough data governance, data quality in those processes. Optimization is great if you've got really good data quality, especially pricing, timing, things like that. The mathematical models rely on that. That is no different for Gen AI, AI, and ML. The square root of a bad number is still a bad number. It doesn't get better because I threw cooler mathematics at it. So this is where we, working with the partners, working with you folks, it's not that we're gonna say, "No, don't ever do this." What I'm saying is, as a warning, keep in mind that those structures in place, where there's governance, and this is really where the IT and the OT coming back together to help, through this process, really help then create the environments where AI and ML are gonna be a lot more successful. Make sense so far? All right.

22:45
Greg Sloyer: So data foundation is necessary. We build these out. We work with the customers and the partners to deploy these things. Like I said, we've been great at IT data, really excited about all the partnerships we have to bring in the OT data, take advantage of our time series, geospatial capabilities, things of that nature. So you can do all sorts of cool math with that. And then extending those with the partner data or sharing that data with your partners, customers, suppliers, logistics, for example. So what's that mean? So from the Unified Namespace, this is what we are continuing to develop: bringing IT, OT, connected products, getting all that within Snowflake, improving that visibility, and allowing you then to run greater AI, ML models, Gen AI, at the data, not, again, separating it out. So that you can take advantage of not just the ingestion of that kind of data, but what do I do with it after I've got it somewhere? So with that, any questions before I send you across the hall to the 1:00 o'clock keynote?

24:15
Audience Member 1: For a lot of us, the issue is not just the data. It's also the application. So you saw, basically, a lot of the applications there. What's the result look like if you wanna get the data out of Snowflake and give it to an individual in order for someone on the shop floor to be able to use it? Does it have to live alongside each other? And should we not think about it like it's a replacement for a data broker? It's just something that lets you do higher-level data?

24:37
Greg Sloyer: Generally, the question is, is there a path to go from Snowflake, let's say, back to Ignition as well? There are organizations that have gone down that route. I would say that the Ignition group, Inductive Automation, is the best ones to talk to. There's always the security and protocols and things like that that you have to work through on that. Technically, I do not believe it's an issue. But generally, it's been a one-way path to go up into Snowflake, because then you're looking, like I said, if you have 50 sites, you may have 50 Ignition brokers or whatever, and they're coming up into Snowflake. So you're looking more holistically at that data. I've not seen SAP data go down to Ignition or anything like that. That's usually staying up within Snowflake. Sure.

25:25
Audience Member 1: Oh, somebody else. So at the beginning of the presentation, you talked about how it's kind of a big permission space, rather than storage space. But then later on.

25:32
Greg Sloyer: For the, for data sharing.

25:41
Audience Member 1: Okay, 'cause when we saw the architecture diagram, if you define it in the namespace for Cirrus Link, it moves up. Where is the storage part in that situation?

25:50
Greg Sloyer: So it's in Snowflake. The data is coming into Snowflake. It's stored there. You have chosen, as a customer organization, AWS or Azure or both, let's say, for different reasons. And Snowflake sits on top of that. So physically, they can talk to you about where it makes most sense. But generally, it's in Snowflake. One last question real quick. Yes.

26:11
Audience Member 2: No. Yeah, that was it.

26:14
Greg Sloyer: No. Oh, okay. All right. Super. So I've already been shown the hook kind of thing 'cause they want you to get across the hall for the 1:00 o'clock. But thank you. Appreciate your time. And we are across the hall for any more detailed questions.

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.

SiteSync leverages the LoRaWAN sensor connectivity technology to allow industrial users to bring stranded assets and manual measurements into a central source of truth for data visualization, alarming, and advanced AI analysis all powered by the Ignition Platform. SiteSync enables field users to deploy IIoT sensors with the same ease of commercial IoT systems via preconfigured devices and QR codes so that these Digital Transformation initiatives can be implemented at scale. In addition to LoRaWAN sensors, SiteSync recognizes that many end users have thousands of HART compatible sensors and the additional HART data is another stranded asset that can be used for Digital Transformation. SiteSync will introduce a new asset management tool focused on HART sensors all powered through the Ignition platform.

Transcript:

00:00
Sarah Sonnier: Hi everyone. My name is Sarah. I'm here with SiteSync, and today we're gonna be talking about bringing stranded data into Ignition. Gimme a sec; my clicker's not working. There we go. Wrong way. So I'm Sarah; I'm a data scientist. I am also the lead developer of SiteSync. SiteSync is an Ignition... An easy way to get IIoT data into Ignition. And I don't meet a lot of data scientists in this field, so I'm gonna tell you a little bit about what I do.

00:36
Sarah Sonnier: Data scientists bring data in from different sources. They bring it together; they model it so that it is clean and usable to make insights out of. So I can create reports, dashboards, do machine learning, and send it off to my end user, who is gonna make actionable decisions off of it. But you can see from this donut chart, a lot of the time that I'm spending is not doing the fun stuff of data science. It's not doing that modeling; it's not... Or predictive modeling. It's not doing machine learning or making those reports. A lot of the time I'm spending is collecting data and cleaning it, which is less than glamorous, especially in the IIoT field. I specifically work with IIoT in industrial data. This data is very disparate. It is everywhere. It can come from multiple different systems. It can come in many different formats. So a lot of my time is spent wrangling this data so that my end users can get value out of it.

01:34
Sarah Sonnier: And so this is a data science hierarchy of needs. If you're familiar with Maslow's Hierarchy of Needs, you can't reach self-actualization or be your best self unless you have a strong foundation. Same thing applies in data. If you don't have a strong foundation of where this data's coming from, is it contextible? Am I reliably getting it? Is it the same measurement every time? If you don't have secure pipelines or trusted ways where you're getting that data from one platform to another, and if it's not easy to model clean, normalize, you're gonna have a hard time doing machine learning, doing reporting, and getting the value out of your data.

02:16
Sarah Sonnier: The whole reason we collect data is to be able to tell what's going on in a process and to be able to make our processes better. So if you don't have a really nice and strong base of your platform collecting that data, the value is diminished. This is what I look like often as I'm struggling with the bottom of my pyramid because I am having to go out there and actually go out to do that collection process. As someone who is in a predictive field, I would never have been able to guess how many times I would've had to wire a terminal block, mount something on a DIN rail, assemble a edge computer to be able to get the data that I need to be able to do this analysis for my end users. It's shocking to me because this data can be tricky to get, especially stuff on the edge.

03:02
Sarah Sonnier: So, you need somewhere that this data is easy to process. Ignition is my favorite data platform of choice. Whenever I have a request, I have someone come in, and they say, Hey, I have a problem. How do we tackle it? My answer is always, Can we do it in Ignition? And usually the answer is yes. The reason I like to do my data projects in Ignition specifically is because it helps me deal with the tough pieces of this pyramid. So the collection, modeling what will go down it, but it helps me take care of a lot of it so that I can handle the stuff at the top. So Ignition Perspective is the top layer. That is where we can do reporting, visualization really flexibly, where you come in and show my end user, Hey, this is going on in your process right now. This is what it was looking like three weeks ago. It's a really easy way for me to quickly take the data from the source and show it to my end user.

04:04
Sarah Sonnier: Then we have modeling. In the data science world, you make models or objects of what you're trying to show, report on, and do machine learning on. Same thing comes natively in Ignition through UDTs. UDTs let you model the process, the instrument, the asset that you are tracking. The fact that it is built in here and I can do transforms, I can do many different things at that level, where that data's coming from is huge. I can context that data, where it comes from, and as it gets sent off to other systems, that context is priceless.

04:35
Sarah Sonnier: Ignition is flexible. I'm able to do it in a bunch of different ways. By it, I mean go through and host it and move different ways. I can pull in data different ways. Flexibility is priceless to me when I have a bunch of different requests from different end users, and they're trying to all do different things, but the end goal that they're trying to get is to get that value out of their data. And finally, Ignition is open, meaning I can pull data in from anywhere really. I can pull it in from a SQL server database. I can pull it on OPC UA, MQTT, IoT devices. The fact that I can have one place where I can pull all my data into, I can flexibly deal with it, I can model it and visualize and export it for my end user. It's huge. And that makes my job as a data scientist so much easier. So when my job as a data scientist is easier, that makes me a happy data scientist. I can spend less time down here trying to figure out how am I getting my data in, when is it being measured, and spend more time doing analysis and delivering value for my end users.

05:39
Sarah Sonnier: So we're in Industry 4.0; we're moving into Industry 4.0, and the promise of Industry 4.0 is you can bring a bunch of... Capture more data. We can capture more data than ever. We can store it cheaply, but, and we can do that analysis, but we need to have the tools in place to be able to capture that. Something that is driving Industry 4.0 is we can measure more things than ever for cheaper than ever, which is really cool. Ignition is a great platform for Industry 4.0. You can come in; you can do your analysis. Countermeasure would be alarming and alerting. You can do responses in Ignition, and because it is so open and flexible, you're able to capture as many events as possible. It's scalable and structurable. SiteSync comes in, and it helps you capture more events and more insights than ever through IIoT and gathering stranded assets in Ignition. So we're bringing that data in and we expose it to you in your Ignition platform. Once it's in Ignition, you can do whatever you like with it, which is a beautiful thing. The speed that this is increasing at is crazy. The amount of data that's being generated is... It's hard to fathom.

06:53
Sarah Sonnier: So who is SiteSync? SiteSync is an IIoT Ignition module that helps bring stranded data into Ignition. We got our start, as many good Inductive Automation stories do, through Arlen Nipper. Arlen brought us a yoga gala, sushi sensor, and he was asking for help, how to deploy it at an end site. As we were helping Arlen, we went through and we realized this really wasn't gonna be scalable. It was really tough to get these data into a platform, and one of the things that we found was there were a bunch of different platforms and a bunch of different places this data could go. So, for example, some vendors have clouds that they wanna do the analysis on. That's fine and good if you're doing residential IoT or commercial IoT. But if you're dealing with data at the control layer, cloud is kind of a no-go.

07:47
Sarah Sonnier: And if you're gonna send data up to the cloud, it's probably not gonna come back down to the person at the cloud that actually needs that data. It's gonna come to people like me doing analysis, but it's not gonna be actionable for that person in the field. The other thing is this data would traditionally go to a traditional system like a DCS. But this data, this IIoT data, the insights, it doesn't behave like traditional instruments. You've got a lot of data. It comes up in a JSON format. There's a lot of attributes, and it doesn't check in at the rate that a traditional instrument would. It's not a continuous readings. So storing it in a DCS, it doesn't always make sense or rarely makes sense because it's not the same kind of data. This data is stuff about your process where the stuff in the DCS is the process. We're telling that this temperature is what's happening. But you could do supplemental measurements, and that's where you can get that value out of IoT. So this data needed a home. Where are you gonna put this data, especially in the industrial side?

08:51
Sarah Sonnier: So, SiteSync and Ignition is the home for your industrial data. It comes in; it's a good place where you can bring it in, marry it in with other parts of your process. Ignition is a great end platform for your data to come through. So we wanna create a nice landing space for the stranded data, the dark data, to have a nice place where it can be modeled. It's flexible, it's open, we can pull in anything we want, and be able to realize that value if that's through sending it to another platform through Sparkplug. If that is doing visualizations and dashboards, Ignition is a great place for this third kind of data.

09:30
Sarah Sonnier: I'm gonna talk a little bit about IoT, the trends; as you can see, it is steadily going up. There are 18 billion IoT devices installed today. It's a crazy number, and the number's crazy because it's really cheap, and it's really easy to get these measurements. These are way easier to install than a traditional instrument. A traditional instrument's probably gonna be around a hundred thousand dollars from specking it out to the actual install to bring it to your historian, where this is probably 1% of that cost to be able to install at one point and bring it somewhere, which is attractive. But as this velocity increases, you need to have a place where you can capture this data and get the value of the data. If we're just going into a data lake, that's nice, but how can we marry that data into other things about your process? Get that context to be able to deliver the value. We can see here that cellular is one of the biggest players in this. We're seeing a lot of cellular-enabled sensors. Another one is this LPWAN group of sensors that's NBIoT and LoRaWAN, both Grade 4 industrial applications.

10:44
Sarah Sonnier: Because we have all this data and we're getting all this processes... Because we're measuring so much data about these processes, we need a good place to hold it, store it, and analyze it. Otherwise, what's the point of gathering it? Data is valuable, and we're able to measure things we were never able to measure before. It's just doing that learning curve of how do we bring it all together. As a data scientist, this is very exciting to me that I can get more data about my process, and I can deliver more insights. I can say, Hey, something's going wrong here. Where previously it was kind of a black box.

11:21
Sarah Sonnier: So I wanna go over four different use cases from end users who are deploying LoRaWAN and IOT devices and how Ignition is helping them with their use cases. So back to our pyramid, we're gonna start at the bottom. The core thing is Ignition is open, meaning I can pull any kind of data that I want into my Ignition environment. What we're looking at right here is a corrosion monitoring sensor. This corrosion monitoring sensor takes a measurement once, maybe twice, a day, and it just measures the thickness of a pipe. It's pretty cool. Traditionally, you would measure corrosion by going around and doing operator rounds, taking a measurement to go off to a system. We had a customer install these on their pipes, and they were able to consistently get trendable data, meaning they were able to take a sample at the same time every day at the same exact location.

12:15
Sarah Sonnier: Which is huge in the world of data science because if I don't know exactly how that measurement was taken, can I trust it? If I see one is significantly different than another, was it a different operator? Was it a different day? Like, is it a different time of day? Like, how can I tell? By being able to standardize those measurements that are being taken, you're able to trend it, and being able to trend it is huge. This customer found that they had an erosion problem happening. It was slight, but they were able to see that after a cleaning happened on the pipe, the pipe got thinner. So they were able to come in and see, Hey, something happened between Monday and Tuesday. What happened? They brought in data from their other processes into Ignition, and they were able to easily see that, hey, I know exactly what happened between Monday and Tuesday. We had a pipe cleaning. They would never have been able to put all of that together without something like this, an IoT sensor. We have so many use cases like this where just starting to do monitoring, even if just a little bit of monitoring, is so much more consistent than doing traditionally polling it and being able to consistently take those measurements means that we can take better insights off of it.

13:33
Sarah Sonnier: Ignition is flexible, so really flexible, which is awesome. We had an end user here, and he was trying to monitor the power usage of different buildings in his campus. So he came to us and he is like, Hey, can we do this? Sure, absolutely. Working with an internal team with him to get this deployed, he wanted to do all on-prem, all on the edge. He said, "Okay, great." So we started building his application to be able to do an analysis to say, "Hey, how much power am I using every 15 minutes with a delta doing this calculation on it?" And he comes to us later he says, "Hey, actually the team that I was working with, they've lost. They've been reallocated to another process. I don't think I'm gonna do the project anymore." And we were able to flex, take all of the project, the logic, everything that we had built for him, and put it into a cloud application, which let him continue to gather his data. It's a little bit different 'cause this is not industrial data, but the flexibility of Ignition is huge for me because I don't like doing double work. I was able to just bring that data straight into another platform, another Ignition one, and he was ready to go within than 30 minutes, which was awesome.

14:42
Sarah Sonnier: Because he's now able to get his data, he was able to see as they closed a building on his campus, the power usage goes significantly down, which was really cool. He was able to see it in real time. He was also able to see, like as people came into a building, their power usage throughout the day; you could see it drop off exactly at 4:30. It was crazy. The flexibility lets me deliver to my end users the request and what they're trying to do. So they just wanna know what's going on in my process, and I can say yes with Ignition, which is awesome.

15:18
Sarah Sonnier: The next one is modeling. So in data science, modeling is very important. It means that I have a repeatable object that I can always use every single time. I can also make changes to my object and apply to everybody. This its object-oriented; as a programmer, I love this. So this is an MCC cabinet, and I'm able to pull in data from multiple different sources. Let me back up. This is the MCC cabinet over here, and there's a little sensor inside of it that it's able to measure the temperature, humidity, and light within that, which is great. But what happens if the room gets hotter? We could say, "Oh, we can alarm when it gets hot inside, but if the AC goes out in the building, we're gonna get a lot of alerts." So what we ended up doing for this customer was being able to do a temperature delta. We were able to measure the ambient temperature within the room and do a calculation to say, Hey, is my cabinet significantly hot, or is my room significantly hot? Being able to use UDTs to model what this cabinet looks like, being able to alert an alarm right there, and apply it to hundreds of MCCs is huge. It's a great time saver, but it also gives me a consistent format that I can do my analysis on. I can do automation on and I'm a huge fan of UDTs.

0:16:35.4
Sarah Sonnier: Modeling makes data science possible. This one's a fun one. So SiteSync has a Perspective project that you can do. You can look at your asset health on, you can deploy devices on, you can get a little diagnostics, and I had a customer that was deploying these. These are manual valve position sensors, and you have to calibrate them. There's a couple different ways to do it, and all of them are a little bit tricky. It's not an easy... It's not like installing a Ring doorbell. It's a little bit more complicated. So I had a customer, and they were deploying 300 of these at a site, and they called me up, and they said, "Hey, kind of having a hard time with this calibration process. Do you think that we could add this to where we're doing this onboarding?" So in SiteSync, you can onboard these devices into your Ignition environment.

17:28
Sarah Sonnier: And I said, thought about for a second, and I was like, "Sure, I think we could do that." They said, "Okay, well, we're gonna go to lunch. Like, let me know how's it going after lunch." And I was able to pull it together pretty quickly, and I was able to allow these users to calibrate in the field as they were going. And so I tested it out on my side;it all looked good. And then I get a call; I sit in the cube, and I get a call from the front desk, and they're like, "Someone from the field is calling." And I was like, "Okay." And it was an instrument tech, and they said, "Hey, I see a new button on the interface of Perspective; can I click it?" I was like, "Sure." And so we together were able to calibrate this valve within like an hour or so of that request coming in, which is crazy.

18:11
Sarah Sonnier: And the valve, the instrument tech was so excited. He said, this makes my life so much easier. I don't have to fuss with another app. I don't have to do this calibration process. You're able to just push this right to my Ignition project, right to my app. No crazy update process, just ready to go. He's like, "That is huge." This end user was able to install all 300 of these by themselves without hiring a third-party contractor. Saved them something like $30,000 and gave them the confidence to go out and deploy their own IoT sensors to monitor their processes. To be able to flex and quickly apply changes to my interfaces to give updates. And they wanna say, Hey, can I see the calibration status on the same page? Absolutely. So this is what we ended up building.

19:02
Sarah Sonnier: They're able to come in and see, Hey, what's my current configuration? and very easily configure these in the field. Being able to flex with my customer and being able to meet their needs makes me a happy data scientist because I can help them, and that makes me happy.

19:20
Sarah Sonnier: So we're talking a little bit about LoRaWAN and the Perspective side. I wanna show you... And we talked about how many devices are out there; something of like 40 billion IoT devices are projected to be installed by 2030. To be able to get to a scale like that, to be able to capture your data, you need to be able to easily onboard in a normalized fashion so you can know exactly this is what my device is, this is what it's measuring, here's how it's modeled. If you're gonna deploy a large fleet of these, anything, it needs to be standardized. I don't know if you've ever impaired at a project where someone started Modbus mapping one way and then started Modbus mapping another way. We don't want that at the IoT scale because there's so many devices, there's so much data. We need a strong foundation to be able to capture that. So this is... Oh. This is a video. I'm gonna get it.

20:28
Sarah Sonnier: This is a video of someone provisioning a device in SiteSync. So this is a Perspective-based project. It's using the native Perspective app. I'm able to quickly get in all of these device keys through scanning a QR code. We can talk about how complicated this is at the booth. It's very complicated, but I'm able to quickly onboard a sensor into your Ignition system, context it by giving information about where it goes, where it's installed, and over here, it flashed, and it showed that that device was instantly added to your tag provider as a UDT. It's that fast to bring a sensor on, have it contexted in its correct format, and then we can quickly see data come in through. It's about a minute from launching this to getting data in, and that's how fast you can add devices and add measurements to your Ignition system.

21:21
Sarah Sonnier: There we go. We've done a lot of different LoRaWAN projects. We've worked with a lot of different companies that had different configurations. Because Ignition is so flexible, we're able to do it at any scale. Whatever you're looking for, if it is at an all-in-one edge gateway where you can come in and jam everything on one machine, if it's a traditional Ignition server, if it's something like an enterprise deployment, we are able to help you bring value to your customers by bringing that IIoT data into Ignition. Once it's in Ignition, that's where it becomes fun. So I've been talking about IIoT data; I've been talking about LoRaWAN data. I'm gonna shift gears for a second.

22:11
Sarah Sonnier: I'm gonna talk about another kind of data. It's a stranded data more or less, but it's not IIoT; it's actually kind of older but has a lot of value. Data is data. So I wanna talk about HART. HART is an Highway Addressable Remote Transducer, which doesn't mean a whole lot to me, but what I do know about this is it is... Runs on a four to 20 current loop. It is the largest industrial protocol period. It is huge. It has an install base of 40 million devices. Devices are critical instruments in the field.

22:54
Sarah Sonnier: That 40 million is significantly smaller than the 18 billion or 40 billion IIoT devices. There's a reason for that. These are critical measurements that exist already in your process. IIoT, it's easy to pop a couple of temperature sensors out there and figure what's going on. This is the temperature transmitter; this is the valve position sensor. Something about HART, though, is these are smart instruments, meaning you're pulling a measurement out of it. A primary variable, if you will. This measuring how open or closed my valve is. But these devices have up to 240 variables within them that are able to tell you about your process, what's going on, maintenance, when was it calibrated and it's all out there in the field. But because of existing data infrastructure, the data's not really being polled. It's kind of in the same scenario of IIoT. Like, where does this data go? It doesn't really go into a DCS; it's not a primary variable, but it is interesting information about your process, and it really isn't pulled into a layer that can be analyzed easily. Well, in legacy systems. I'm sure that there are newer systems that are much easier to pull this out of.

24:12
Sarah Sonnier: So we had an end user come to us. The end user was using our LoRaWAN Ignition module, and he asked, he said, "Hey, like, I can see what the value is in this. I have a problem. Could we take a look and see if we could eliminate this process?" This process was he had to go into an asset management system, or his team did, poll a CSV of every single valve. When you have hundreds of valves, that is a huge, monotonous, tedious task to be able to poll to get the status of everything in your process. And he said, "There's gotta be a better way to do it." And I agree. If your process is tedious, if it means a human has to go out and do that download, it's likely something will get missed or it could get pushed off for a more pressing task. He asked, "Could we bring this data into Ignition so we could do that alerting and alarming? We can pull it easily; we can send it off to other systems easily." And I said, "Sure," because Ignition is flexible, it is open, it's easily modelable. We can absolutely do it.

25:19
Sarah Sonnier: So currently, as I mentioned earlier, you're typically bringing in one or two variables into your control system. That's just because you don't wanna clog up your DCS. You don't have the resources to pull it in. And honestly, PV, or the primary variable, is what you're trying to bring in. This is, in my case, a valve position sensor. And that is PV is how open or closed it is. But because there are 240 HART variables, you're leaving 90% of the data of your process in the field.

25:54
Sarah Sonnier: This is data that is huge for preventative maintenance. This is data that you already have; you're generating it; it's in assets that you already own. We're just not pulling it into a system that's easy to do predictive maintenance. As a data scientist, being able to get values like this and being able to quickly alert an alarm and say, "Hey, I think this might need attention; we might need to order something." Being able to give that insight to my end user is huge. I can quickly... Like this is a gold mine for me, being able to deliver those insights. IIoT is like that for me because I can quickly get new measurements. These are measurements that already exist that I just can't get.

26:37
Sarah Sonnier: So we ended up building a HartSync. This is something in beta. We're in active development, and it's a way to easily get that data stranded out in the field into your Ignition system. We're modeling; get it into UDTs based on what kind of device it is. So we're able to speak HART. We're able to come in and see exactly what's happening in your loop. If you're interested, we would love to talk to you about the beta group or what features you would like to see happening within this. The other thing is I would love to talk about different hardware architectures, 'cause I'm seeing a lot of different end users have different hardware architectures. So what does that look like for you today? If you're not pulling in hard data or I would love to also talk about what would that look like. Would you be interested in something like that? So please come see me. I'm in a booth out there. We could talk about this. This is huge for me because you're able to come in, you can get status, you can do requests, and you can talk to assets you already have.

27:40
Sarah Sonnier: And it's like that old commercial: it's like, It's my money; I need it now. This is your data; let's go get it. So bringing it into that home where you can do your predictive maintenance and everything, like that, is the value. It could be amazing.

28:00
Sarah Sonnier: In summary, Ignition and SiteSync equals your data has a home. We are able to bring in stranded assets, data about your process, data that doesn't belong anywhere else but can be easily and effectively married to other pieces in your process. And you can easily make insightful reports. You can make decisions off of it. If we go back down that pyramid, I'm able to collect it. I'm able to flexibly collect it so multiple different places. I'm able to model it, and I'm able to visualize it easily. When all of those are taken care of in Ignition for me, I'm able to do the fun stuff of machine learning, doing reporting, and whatever crazy dashboard request my boss comes up with because he's always got one. But yeah, this is super impactful. This is gonna take your end user from having to do all of that to being able to just get that value out of the data. And yeah. Thank you so much, and if we have any questions, I'll just take them.

29:09
Audience Member 1: I guess we'll just bark out the questions.

29:09
Sarah Sonnier: Sure.

29:10
Audience Member 1: Do you look at an IO-Link master or anything with, yeah, basically I/O or... Yeah, with... Yeah.

29:21
Sarah Sonnier: So I'm a data scientist. I am accidentally in this hardware space. Please do come talk to me about the booth with someone who can answer that question. But unfortunately I can answer your data questions and your data accessory questions. I can hear you.

29:39
Audience Member 1: Well, yeah. I'm sure everyone else can hear me, probably.

29:48
Audience Member 2: I have a question.

29:49
Sarah Sonnier: Yeah.

29:54
Sarah Sonnier: The Things Network?

29:54
Audience Member 2: Yeah. With your product? Sorry.

29:55
Sarah Sonnier: Yes, absolutely.

29:57
Audience Member 2: And how does that work?

30:00
Sarah Sonnier: We have API integrations into all of the major LoRaWAN network servers. So we're able to quickly sync devices both to Ignition and your LoRaWAN network server.

30:07
Audience Member 2: Thanks.

30:10
Sarah Sonnier: Yeah.

30:23
Audience Member 3: Is it being ready to use the HartSync?

30:32
Sarah Sonnier: So HartSync is a new product. We are in beta with it. We're active development. So it's still being worked on. Do you have any, like, questions, comments, concerns?

30:39
Audience Member 3: Is it related to Y HARTs for pH?

30:44
Sarah Sonnier: It could be. We are getting requests for Y HART, and I would love to talk more about those use cases. Right now it is for traditional loops. So we're going through a mux, maybe a modem on the control loop, and being able to forward that data off.

31:00
Audience Member 3: Okay.

31:00
Sarah Sonnier: And primarily what I'm offering is a way to pull that into Ignition. I don't really understand... I don't... Not that I don't understand, but I don't know all the configurations that could happen to get that data there.

31:08
Audience Member 3: Ah, okay. Cool. Thank you.

31:12
Sarah Sonnier: Thanks.

31:18
Audience Member 4: To follow up on the HART stuff, so is that a... It's in beta right now, but this is a separate module similar to SiteSync functionally.

31:26
Sarah Sonnier: Yes. Functionally, very similar, where the goal is to get that stranded data into Ignition as modeled. It's different in that it's a totally different protocol, but yes, same idea. It's a module you can install wherever you wanna do it. Edge, standard, wherever you wanna do it.

31:42
Audience Member 5: Thank you.

31:46
Sarah Sonnier: One more question.

31:48
Audience Member 6: How are you bridging the hardware gap on the analog interface that's going to the HART device to capture multiple devices, because a lot of controllers will be able to integrate in that and then provide it up to whatever DCS or SCADA system you have? How are you guys bridging that hardware gap?

32:08
Sarah Sonnier: I'm using a mux at this point, but I do wanna talk about what that looks like for other pieces. Essentially, if I can get access to that HART data, that's what I care about: getting that data to me, that's another person.

32:22
Audience Member 7: So, I guess good job on the HART module. This is Karthik here, so, but...

32:31
Sarah Sonnier: Hi Karthik.

32:32
Audience Member 7: Hello. So wanted to ask you, I know we are gonna capture the data here, but have you thought about how you're gonna integrate the data like you do for your lower network data, right?

32:47
Sarah Sonnier: Integrate, meaning sending it off to other places? Yeah, that's a built-in function of Ignition, which is awesome. So Ignition has a... As a open... And I really focused on the open bringing data in, but it's really open to bringing data out. So you can use Cirrus Link Sparkplug transmission to send data out. You could do API integrations out, you could sync it to a historian, your own database. The possibilities are pretty much limitless, which is what makes Ignition a great data platform. I'm really flexible and able to meet my client's request 'cause they're always changing. Thank you.

Ericsson’s 5G-focused solutions turn connectivity into productivity by delivering intelligent communications at the edge that are more secure, versatile, and easier to manage than WiFi. See real-world business-critical use cases that exemplify how private 5G solutions accelerate operations, improve reliability, and enhance working conditions, all while reducing cost and latency.

Transcript:

00:00
Michael Dickens: My name's Michael Dickens. I'm with Ericsson Enterprise Solutions. Formally, you might have known us from Cradlepoint. We build everything 5G-focused. Our solutions are very much focused on from edge to core, and RAN. You might know us from the cell phones back in the day as Ericsson, but oftentimes many of you on your 5G phones today we'll be connecting to our public networks on Verizon, AT&T, things like that. Today, we're much more focused on radio solutions for private 5G, the edge devices, which I'll go into that for the hardware, but everything around 4G, 5G, networking; those communications, we really focus on building a managed network for communicating often in OT environments. I'll have a whole bunch of examples I'll go through to get your minds thinking about all the solutions you may be doing. But of course, how does that work with Inductive? I'll get into that as well.

00:51
Michael Dickens: First off, we focus on making sure all these items are completely managed from one location, NetCloud manager. You'll find this up in our cloud. We automatically register the devices for any private radios, core networking routers, and they're all 5G-enabled, focusing on those SIMs and getting connectivity for those. You'll see that we actually have a lot of layers and stacks on here. Every time I talk to someone from Inductive, they're like, "Okay, we need to talk MQTT, or we need an API, and we need to be able to run STKs." All these items are ran in the cloud and distributed automatically, organizationally, to each of the devices or the core RANs that we're running. You'll see on the bottom that one of the partnerships mainly we have in the networking world. We're talking about security and communications. We include all those pieces. But our focus on the 5G side is that intelligence for communication on those so that you can know your network is secure and running for your applications that you're running at the edge.

01:50
Michael Dickens: Some of the devices that we have, we'll start from the bottom and then we'll start moving up into the private 5G world. But the classic Cradlepoint point side, we have come out with a couple new products, one, R2100. This is an IoT/OT device that has included antennas. It has Bluetooth, it has Ethernet, it has Wi-Fi, but of course 5G communications; you can just drop a SIM in to it. The nice thing about this product, it includes all the antennas and everything into one IP67 device so that you can drop it in anywhere. We find this; we're running it outdoors. We're on lift trucks, we're on vehicles, things like that, that are mobile. Then the devices below, you'll see that are devices that can run Ignition. Anything that supports Docker containers will support Ignition. I'll show you how we actually distribute those here in a little bit. The 920 and S700, and IBR200: basically, you're going down the road, and you're getting different throughput for each of these devices. And it's important that you can run these on public networks, again, like Verizon, rest of the world, British Telecom, Vodafone, things like that, depending on where you're deploying these. Or you can put a private SIM into them. So, you can get communications to your devices at a local area, whether it's a manufacturer, a stadium, depending on where you're using those to get communications.

03:05
Michael Dickens: Some of the other devices that we have, we also find ourselves often into retail or quick-serve restaurants. For example, if you went over to a Starbucks this morning to get your coffee, you can have a Cradlepoint running there. Oftentimes we find we're doing not just communications for the internet for that, but we're running applications like Inductive Automation, Ignition, at the edge to manage door controls, interfaces for the fire alarm control panels, things like that. They like to run that application on a separate air-gapped network. They may use us for backup internet in the DMZ, but this is a nice place to be able to build those applications depending on where you're deploying in the world, whether it's a vehicle, a retail store, or if it's the closet for the MDF for where you're running your control systems for a building, etc.

03:50 
Michael Dickens: How do we deploy Ignition, for example? So, I have a few examples I want to talk to you about up here. First off are edge apps. What this is from our NetCloud manager, you're able to deploy Python code natively to any of our boxes at the edge. This makes it really easy for you to create an app, manage it, do what you need, very lightweight per code. Oftentimes we are running, for example, like MQTT Mosquitto at the edge, and you'll integrate with that. So you can talk MQTT to your standard things. This is a really easy way for any of our devices if you have an application running. Now, edge containers, we orchestrate this also from the cloud as well. Ignition actually keeps up to date all their devices and their software in their cloud so that we can just automate the point to one or thousands of devices at a time.

04:36 
Michael Dickens: This makes it really easy because we just do standard Docker Compose to be able to bring that out to the edge and be able to deploy your application. Then you can manage Ignition as you want from all the different devices. Now, HMI always comes up, and so through NetCloud manager, if you ever need like a VPN or just things like that to be built, you can do that or natively from NetCloud. You can pop in and do like VNC or RDP or SSH, whatever you need from the cloud to easily get to your applications or even to the container itself, running Ignition so you can manage that remotely. Whereas oftentimes we're not always on the plant for going and walking to every machine, we wanna be able to do it from our desk. This makes it really, really easy. We also have connectors into like AWS, Azure, all the standard platforms that we build those, so we can automate that connection into there for the connectivity.

05:23 
Michael Dickens: I know Ignition can do that as well. So it's just a basis of what applications you're running where. But what my biggest point is here, all the different interfaces and communications that we have built into these boxes to be able to do communication, those are available to the container. Now, that being said, great, networking's wonderful, but we do build security atop all this where you all hear about Zero Trust Network Access and things like that. Oftentimes, where the vendors coming in and we need that remote access, well, they can create that access for a very specifically... For example, I work with 7-Eleven, and they need access directly to the gas stations to update the firmware on the pumps themselves. Just that management piece. Well, we have a Cradlepoint there. They can create that access for you to get directly to that application only and make it really, really easy.

06:11 
Michael Dickens: Now, I wanted to introduce, this is a little bit newer concept for some people, but the same internet that you're using from your phone today, we create networks for that. There's a couple of different components that come into that. First off, there's a radio. Right? Oftentimes we think about Wi-Fi and radio. Everyone walks up to my table over there and be like, "Oh, we got a bunch of Wi-Fi here?" No, it's very focused on 4G/5G networking. That's where the Ericsson piece comes into play. We actually deploy networks from small to very, very large statewide networks for private networking. Private, when I say "private," I wanna be specific. This is for your applications. It's not like you're going to Verizon saying, "Hey, can I buy SIM and connect a bunch of devices?" This is for your specific applications controlled by you, just like you're deploying Wi-Fi in a location, but you can do a lot more with it and more security.

06:57 
Michael Dickens: A couple of the pieces that come with it. One, management. That's always important. We can do on-prem management or in the cloud; cloud makes it always easier. You'll need your radios; we have a very wide selection of different radios for different spectrums. When you go around the world, you'll see that... I have a little example later on where we're deploying, but you need Spectrum to be able to talk on. 5 GHz, 2.4 standard for Wi-Fi, we're looking from all the way down to 600 MHz up to millimeter wave for when we're deploying these. So, we have a whole bunch of different radios for these. Some are built to be outdoors, like when you're driving down the road, you see the tower, the three antennas. That's some of the things we do for outdoors deployment. But then we also have with something called "red dots." They're the indoor radios so that you can deploy into a factory floor, a warehouse, wherever you may be using it. We're able to deploy and broadcast 5G into those locations as well, depending on the Spectrum.

07:50 
Michael Dickens: If you're North-American-based, US, CBRS comes up quite a bit. It's a nice Spectrum FCC opened up for us to be able to use for these environments that you can use for your deployments as well. Last but not least, you need a core. I always talked about this is like the Wi-Fi controller, but it's the core for the 5G network: The brains, the communication, the control, where does my SIM get authenticated? This is all controlled here, so we include this as well. We also include SIMs with the devices so that you can pop them in there, or you can do eSIM to deliver to your devices as well, like using Intune or an MDM to Apple devices, Zebra scanners, things like that. We know there's a lot of communication. We do build routers and edge OT router devices. We know there's gonna be a whole bunch of other devices on our network as well, so we work with all of them as well. Very common.

08:42 
Michael Dickens: Now, some of the reasons that we're doing this is really often one specific application. When we walk into a customer, they need to have the communication up and running. Sometimes that's voice. We find that they need voice communication in a remote site. LMR is very common, but we'll start getting other communication. Time-critical, I mean, you can be driving 500 kilometers an hour and still be connected and jumping from RAN to RAN. So, it's really powerful, very fast. You're able to have that secure communication always. All the time I talk to someone, we're running our AGV; it's on Wi-Fi, it drops, we have to stop for safety reasons. We need that coverage and ubiquitous communication. That's where 5G really is able to answer that need.

09:24 
Michael Dickens: Also, low, low latency. Right? All our applications now are needed to be able to communicate in a very fast and quick manner for things to happen. Door controls, whatever it may be. Safety reasons: We're running into a lot of safety applications where these need to be very cool fast. We are down to like five, two milliseconds sometimes for these networks. And that's 5G terms. 4G, 40 milliseconds, 30 milliseconds. But it's really important for these to be able to talk quickly and things to be able to happen.

09:52 
Michael Dickens: Also, the local management and serviceability. A lot of our partners, I know some of you are partners, are deploying it here, and they are able to manage these devices, but we also have services to help manage 5G. 'Cause we know, 3GPP, that's the IEEE of the world for networking for us. It's very complex. We try to make it easy for you to deploy these. Now, some of the developers in the room, I know you're like, "Hey, the IT guys just bring my network. I don't have to worry about that," but we're here to help your IT guys. If you're just doing the developing part, no problem.

10:24 
Michael Dickens: Something new and interesting we've been doing on these 5G systems is indoor positioning. We can get down to one meter. So, let's say you have a 2 million-square-feet plant. Where is George? George is carrying an iPhone or a scanner from Zebra or a Google Android device. I need to know where George is right now because there's something going on. Boom. We can able to pull that up and have triangulation of knowing exactly where anything is. We're also running into some of our manufacturers for automobiles. They have actually smart torque wrenches. They're very expensive. They need them. They need a monitor. They're doing exact torquing that they need because it's for our safety's driving the vehicles that it's done correctly. Well, they're connecting that via 5G. Where is that wrench? We don't know. Someone moved it over here, somewhere. Well, we can track exactly where those things are as well. So, interesting to be able to start doing this tracking systems.

11:20 
Michael Dickens: Another interesting thing that we started seeing is that coverage for AT&T, Verizon, T-Mobile. You go into this big metal behemoth oil and gas or a factory. RF is just not working. My cell phone, I can't make a call, right? E911. I need to be able to put that out, or I need to be able to have information on what's going on. Well, at the exact same time as we're deploying the coverage for the... Sorry, the private 5G network, we can deploy coverage extension. So, you can take basically pump 5G network from Verizon into your entire plant floor so that you can make sure you have communications on both sides of the world. Now, we do some QoS and make sure your applications are working and everything like that. But this is kind of an add-on feature that you can make sure that you have coverage for the standard users that you have coming into your network.

12:09 
Michael Dickens: This has been really useful for some systems to be able to replace their DaaS, which is quite expensive, and be able to have communication. Now, we're doing this mostly on the indoor stuff because the macro networks, it's the carrier's job to cover the outdoors. But we do run into worlds where, for example, a mine. They're out in the middle of nowhere. They're going deep into the tunnels. They still want to have their cell phones. If it's just AT&T, for example, though the carrier's not gonna be able to connect you down that mine, but we can. We can run that signal down in there, and it's great for safety and communications. Sometimes I'm the middle of nowhere, I just wanna call my wife, and, well, I need service. Here we go. This is a good solution to be able to get that done.

12:54
Michael Dickens: So, I want to go through some use cases, kinda get your minds thinking here, and then in about 10 minutes we'll talk about that. So, from the list here, I won't read them all off. Some of the main ones I've been seeing for this where we could be deploying and doing communications for Inductive is oil and gas, mining, ports, utilities, warehouse logistics, and, of course, a lot, a lot of manufacturing. So, these are all really rough environments sometimes. You don't want to be taking a cable and moving it again. Power may be there, maybe not. This makes it easy. So, if someone walked up to me and the engineering manager said, "Hey, we need to move that development system that's manufacturing this 20 feet," they're like, "Well, all right, we gotta get the CAT6 guys over here, the fiber guys over here; it's gonna be a month; it's gonna cost this X amount of dollars operationally, blah, blah, blah." Well, I just put a 5G gateway there, put a SIM in it, boom, move it to 20 feet. I don't care. No problem, anytime.

13:48
Michael Dickens: I also find there's a lot of third-party applications. One of them being kiosks where they get hard hats. You forgot your gear today. They have to go to the kiosk. Well, they don't want them on their network; they just give them a 5G SIM, segment it off, and say, "There you go. You can drop in to your kiosk anywhere;" you may be able to go. These are common use cases across all these type of segments. But we actually go down to the nitty-gritty specific applications as well. But the network is the network, comms or comms. Nothing's gonna work without communication and be able to make that work.

14:21
Michael Dickens: We are seeing this, like I said, globally start to deploy. This might be a little small for you guys to see up there, but there is a whole bunch of examples up here of what solutions that we can talk about. You can take a look online that you can get case studies on there and see why they deployed it and what's going on for each of these. I have a few examples I'm gonna go through. I just want you guys to know that this is a technology that's ubiquitous across the whole earth. Right? We were deploying in all kinds of different locations. It can be tough to deploy in those locations, but Spectrum and RF, 3GPP, 5G networking is a great solution to be able to do this. I do run into scenarios where we're doing both, right? We have 5G doing the deployment, then you gotta go farther to the next site. Okay, you do point-to-point microwave; that's great.

15:08
Michael Dickens: And then from the edge devices, we redistribute again, like say LoRaWAN, for example. So, you start seeing how these networks start stacking and then give you your application to have communications as needed. Right? Often I do cover miles in They were like, "Oh, can we put a 4K camera right there?" and LoRaWAN could do that, but the throughput is not there, right? They were like, "Oh, can we put a 4K camera right there?" I'm like, "Sure, no problem." 5G, we absolutely can do that. LoRa, mm, I'm not sure how you're gonna get all that video across there. But that couple sensors around it, absolutely; we could totally do that. And the solution come all together across from our gateways to the RAN to the network, to the core, to the whole communication and the data center.

15:48
Michael Dickens: First example I wanna talk about is Toyota Material Handling. So, they were actually having a lot of issues with Wi-Fi, simple as that. They were going outdoors, getting pallets, deploying this stuff, getting parts, and they're using it for their own solutions. And they build these actual lifting machines themselves, actually. And they were having a lot of issues operationally for it. Just be able to go out there, and what pallet am I supposed to be grabbing? I can't scan it; it's not working. And so issues would start backing up, and we all know how manufacturing works in that world. Time is money. Their ROI was within, I think it was a month or two months that they got their ROI on this because their operational efficiency went through the roof for this. So, really interesting solutions for this, and it really helps...

16:34
Michael Dickens: One of our partners actually helped deploy this, and their productivity went really well. They're very, very happy. Now, the cool part is, though, now that they have this network, they're starting to look at other things that can move to this. I always, every time someone comes to me, they're like, "We want a 5G network." Well, "Is Wi-Fi not cutting it for you?" And they're like, "No." This is why, why, why. And so there's that one application that gets them into the door that makes them happy, but then you can start deploying other things and then just network. 'Cause there's space; there's bandwidth for you to be able to use.

17:08
Michael Dickens: Another one in manufacturing. They were actually looking at doing different radios, and they really just needed coverage. They have a whole bunch of different users on cell phone. They pay the carrier for their service. And of course, through all the metal in this building, they were not able to get connectivity. So, we're able to expand this using our coverage extension. They actually just deployed mainly the coverage extension. Then they moved to the Ericsson private 5G side because they saw the value of it, and they'd be able to have communications for those applications. But just walking into a building and not having service is just, doesn't work well for getting anything done. And so, we really solved this solution. It's just, I look at it as a complete bonus add, but I'm starting to discover that I thought private 5G is what everyone's gonna want. No, they just want coverage. They just want their cell phone to work. And so we're running into this quite a bit. It's really interesting for their communications. And then they started looking at doing AGVs, things like that for the communication on each of those things that are moving around so they can do new solutions 'cause they have the network to be able to get that done.

18:16
Michael Dickens: Another one, a logistics solution. More AGVs and AMRs. We're starting to see that. AI, communication automation, we're seeing that grow. You're not able to get that done without having the communication to be able to have those vehicles moving. The biggest piece I see until most of these are safety. They have these devices, pallet movers, what's going on, and they wanna make sure they have the communication to make sure what's going on. I was actually talking to one that was doing... Let's see. It was the largest retailer, if you will, the big W. They had their big, big things where they had pallets on multiple layers, moving these boxes automated so they could start doing... They were running that on Wi-Fi as well. They would stop. They're going 40 miles an hour, they lost connectivity, they were not able to run anymore. So, they would just stop. But you know where they stopped? Where there's no signal. So, they had to walk over to the machine, put it in neutral, move it over to the system to where they had communications, and get it started again. Private 5G fixed that for them because they were able to get communication across all of it and get all the other systems that are delivering and automating for all these pieces. It's really interesting to be able to have comms to be able to make it work.

19:31
Michael Dickens: Another manufacturer, this one's very focused in the EV charging space. So, they need to be able to have comms for the chargers themselves. And so sometimes you walk in these places, and they have 30 chargers in a lot. But are they gonna run fiber underneath the concrete for each of those solutions for those there? No, it gets very costly. And so they're able to get Cradlepoint routers connected into those machines and have all the chargers working and communicating and having that. I even have some that are doing it out in the parking lot for electric vehicles getting... They're all sending and manufactured, waiting to be shipped out, but then they have updates. And so we drop in a tower in the middle of the parking lot that starts sending all the updates to the cars for the communication. So, we're starting to see EV start to grow in that type of world for just the cars' communication, but the manufacturing process, but then also for anything else that they may have ancillary for in the field out in the middle of nowhere. You know, I'm driving to Texas from here. Well, I need to stop at the EV place. Well, they need to have all of that communicating. And so private 5G. Honestly, mostly private 4G in those scenarios, but both work in those solutions.

20:44
Michael Dickens: This one may be a little more common for you guys, but we're starting to see Newmont, for example, mining solutions that they're in these really tough locations. This one's more big earth movers digging down into the ground and getting materials. If you build solutions for this, you'll know that it's not a great location. It's dusty; it's dirty. It has to be very tough. We were able to deploy this tower, for example. It looks very similar to the ones if you see them outside. We do exact same thing as a macro radios to connect all the devices in these giant, giant, large areas. We're able to get the coverage communication working for all these things and even run 4K cameras getting machine vision from all the different things that they're doing.

21:25
Michael Dickens: I have another one I didn't put on here, but it's a gold mine that they're running that they had the big earth movers. They make about 300K an hour for those earth movers for the giant dump trucks, like big as this room, driving. They actually installed our routers, four of them, while it's moving because the cost of having downtime. And their goal was to move to a full autonomous vehicle so that the drivers, they don't have to jump on and off while it's running; they'll just run by themselves. That's the goal. And so they'll be able to have a network that can do those comms. And people remotely come in, for example, tough turns, whatever may be going on, they can do that over the network, which is a really interesting solution, and start optimizing for those things and having communication.

22:14
Michael Dickens: Now, oil and gas. We're starting to see this grow quite a bit as well. Now, oil and gas can mean a lot of different things. I see the stations out in the middle of the ocean. We're starting to deploy for those communications. A lot of times it's satellite backhaul or point-to-point if it's close enough to shore. But then we redistribute that with 5G for all the comms on the oil rig itself for communicating. 'Cause it's pure metal. So, we have to turn up the power a bit on these to be able to get the communication going in for the RF. But having that versus having just Wi-Fi, and the amount of APs, and where would they put them, this makes it very simple 'cause we can deploy four radios on each of the side, bring it in, or define if it's really tall or down. We can point those radios as we need via antennas. Just to put Wi-Fi APs across this whole entire thing, I don't know how I would even design it because you have to be doing it for years to know every single area, what you need to communicate with, how it's gonna work. We make it very simple 'cause we did it with four radios. Makes it super easy.

23:13
Michael Dickens: Now, then when we talk about oil and gas on land, it's usually very, very distributed. And so that's another good point. So, I do, in my designs, I'll do point-to-point and then redistribute via 5G for those different areas for those communication. If you're able to get fiber, wonderful, that's great. But most of the time those environments we're not able to have the communication. But of course if you guys know, all the applications there locally that you want to have that access to, no one wants to drive the three hours out to that one rig to be able to make sure that it's working correctly or you lost connectivity. This makes it a lot easier to have that comms up and running.

23:51
Michael Dickens: Now, those are my slides. I wanted to leave five minutes for any questions that may be out there. Yeah, it's our own SIMs. It's your SIM; it's your network. You do have to pay for the radio, the core network, the services that get it out there. But no, you're not paying the carriers for that. That's your own network. Now, the only other thing may be Spectrum. I would recommend CBRS here, or you may have to go through a third party; even maybe Verizon might lease you use in Spectrum, depending on your needs.

24:19
Michael Dickens: If it's private 5G, for example, with CBRS, you don't have to pay anything. There are paid-for licenses to get priority access on that Spectrum. But if you're in the middle of nowhere, probably no one's using it. Your land, it's free.

24:35
Michael Dickens: Yes and no. It does cost quite a bit more than Wi-Fi 'cause the radio is more expensive, but I can cover a lot more space. So, it comes down to your applications, right? Then, of course, your devices need to have 5G or 4G radios in them too.

24:52
Michael Dickens: I always look at it as a hybrid solution. If you're using Wi-Fi today and then your apps are running okay on it, I'm not gonna push you to go to 5G. But if you have applications we're not working that well on it, I'll say, "Okay, let's start implementing it and do a hybrid solution," absolutely. Now, if you were talking, I only had a thousand devices, and it's this large area I had to deploy a thousand APs 'cause it's such a large area, we may be able to make that a lot easier for a transition to 5G. It really depends.

25:18
Audience Member 5: You mentioned IP67, but do you also have, like, C1D1 hazardous parts?

25:24
Michael Dickens: We do on some of the routers. It depends. There's a lot of different specs out there on the devices we do. The radios as well. It depends on what type of environment you're going into. We do have that on all our spec sheets, stuff like that. But for the hazardous or electrical areas, things like that, we do have some of those specs, yes.

25:45
Michael Dickens: Wonderful. If you have any more... Wanna talk more about this, we'll be right there at the booth. If you have any questions, please come out to us. Thank you.

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:

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.

Gain valuable insights into writing clean and maintainable Python code, whether you're a Python beginner or a seasoned developer. In this session, you’ll get practical knowledge of PEP 8, explore best practices for code formatting and style, and discover tools to streamline your workflow.

Transcript:

00:50
Chris Andersen: Ready. All right, everyone, we're gonna go ahead and get started. My name is Chris Andersen. I am a technical sales rep here at Inductive Automation. And welcome to today's session. It's called "Level Up Your Python Best Practices For Clean And Consistent Code," and I'll be your moderator today. To start things off, I'm gonna introduce César over here. I've had the pleasure of working with him for the last year. But a little bit of background on him leveraging his strong foundation of computer science and proficiency in C++, Java, and C#. César joined PyroTech in 2012 as a senior software engineer. A year later, he did a five-day course with RO and Bobby McKinsey, and that kind of sparked his passion for Ignition. Ignition's ease of use the flexibility perfectly aligned with César's interests and also led him into Python, which became his preferred programming language. This ignited, pun intended, his journey to become PyroTech's first skated developer, and he's a Vision veteran today. Today César leads PyroTech's information systems manufacturing team, overseeing all of Ignition's deployments globally. So please help me welcome César to the stage.

01:19
César: Thank you. Thank you, sir. All right. Hello. Hey, hi, everybody. Well, I wasn't expecting this large of a crowd with an appetite for Python, but yeah, welcome everybody. So as first Chris introduced me, yes, I've been with PyroTech, and as a software engineer, I started my career with C#. I jumped into Python as soon as I started working on Ignition. So the experience that I've had with Python so far led me into publishing these packages. I don't know; I'm just gonna have to do this. Show of hands, who's installed Ignition API? All right, none. All right, there. So the point of Ignition API in this case is to allow you to get code completion. If you're working on your scripting projects from an IDE like Visual Studio Code or PyCharm, you get the system library code completion there. Another one of the projects that I used to have on the Ignition Exchange is Incendium, which is a library that sits on top of Ignition API as well and enhances or makes some things easier, like working with stored procedures, databases, and also with Vision components like alerting and messages.

02:53
César: Another thing that eventually happened: I'm also interested in CI and CD, and recently... Well, not recently, a couple of years ago, GitHub, which is also the backend that Azure DevOps uses for running CI/CD on their images or runners, dropped support for Python 2.7. So that's when I created this Docker image called Six. Well, naming is always interesting. So I took some inspiration from another package called Six from the Python library that gives support for both 2 and 3. So this is what I've done. And these projects have given me the opportunity and experience to use all these coding standards and things that I'm gonna be touching upon. Where you can find me? These are the links. So yeah, let's get started. This is the agenda for this session. We have coding standards, style guides, and the tool set. Well, I don't know if you were expecting that. This is not gonna be specifically a hands-on presentation. I will give you the theory behind it, the tools that you might be able to apply eventually. But yeah, of course, if you have any questions, not just here in this session, please feel free to reach out.

04:27
César: So yeah, let's get started with coding standards. In this case, what are coding standards? As it says right here, coding standards, also known as coding guidelines or style guides, are a set of rules or of conventions that developers use when writing code. These coding standards are important because they provide consistency. In this case, they ensure consistency by improving reliability, maintainability, and improving collaboration within a code base. So when you set these guidelines, Me I started as a sole developer. So setting standards for myself was extremely easy. But as soon as my team started growing, I felt the need to create those guides internally so we can follow them. So these guidelines, for consistency purposes, do you establish or they establish a uniform standard for writing code and ensure that your projects adhere to a consistent format and style? They improve readability because they promote code that is easy to read and understand. By following the specific conventions for formatting, developers can improve the overall readability of their code.

06:00
César: They also improve on maintainability because your code is consistent, not just in only one single application, but across all of your applications or all of your portfolio. You can achieve that maintainability because your code is following a standard style. They also improve us as well, collaboration, because onboarding a new member, just giving or sharing with them the guidelines that you use, the style that you have chosen, makes it fairly easy for them to understand and follow the guide. So in this case, it will reduce misunderstandings, potentially, and ensure that code is written in a consistent manner. And by that as well, a secondary effect to that is efficiency. So if you follow the same style for every application that you create, all the code that you write, it improves the consistency because it might reduce errors and improve development speed. Finally, quality. One of the things as well, well-structured code, often will lead to higher-quality software, which will also be a testament to your customers in this case. If they get to see that your code is well-structured, it not only works good but it also looks good. It also improves on that.

07:29
César: So one of the key components, among others, but these are some that I'm gonna be touching upon on this session, is naming conventions, indentation, sorry, and spacing. And lastly, commenting and documentation. So in this case, naming conventions it means that you should use a consistent naming for variables, functions, classes, and it goes in this case for Ignition into components on your UI, whether Perspective or Vision. In indentation, you have a consistent pattern. The eternal battle, I would say, that between tabs versus spaces, so we will touch upon that as well. And commenting, well-documented or code that is commented in a good way it is easier to understand. Instead of just the code sitting there, having a docstring there will let other developers, not only you to fully understand what's the function's purpose. In this case, while naming conventions, some of the guidelines that you may run into, or you may see online, touch upon these styles. So just to go through a few of them, you will see words thrown out as Camel Case, Pascal Case, Snake Case, uppercase, and Hungarian notation.

09:05 César: So in this Camel Case, as you can see, it's just, oh yeah, you see that this is like the hump of the camel; you start with the lowercase and then the next word is with uppercase. Pascal Case starts with an uppercase, Snake Case all lowercase, and each word is separated by an underscore. This is the same thing, or this is also Snake Uppercase. And lastly, Hungarian notation. So we will touch upon this in a moment. And this would be an example, for example, well, an example for Camel Case and Pascal Case. So you would see this in Java code, or this is some code that is from using the Java standard, so you will see like classes using Pascal Case, variables in here, and methods also using Camel Case, and it is fairly easy to read if you were to have or if you were to follow something else or lowercase and no spaces between them, it would be a little bit harder to understand. Some cases, for example, this might be something that you would run into if you look at Python code online, is following the Snake Case standard. So you would see this method or function following that convention, also variables in here, the ones that they receive and internal.

10:38
César: And also, it's fairly easy to understand. Some other naming convention, as you can see here, Hungarian notation. Back in the past, it was used for saying that if it starts with an I, because it's an integer. So it was being used like that. In my case, in particular, I used it for GUI components. So for example, all my buttons start with BTN, all my checkboxes with CHK. Not just, so it is also easy to see on the tree view on the side in case, well, referring to the Ignition designer, it's just very easy to know what component we're looking at. So up next, style guides. Also some key guidelines of style, well, sorry, style guides they enhance reliability. So you're gonna see that some of these concepts we have already touched upon in coding standards. In this case, style guides are the ones that provide a better description of the coding standards. It not just only touches on code, because, as you could see, coding standards was just naming, for example, and indentation.

12:02
César: In this case, these style guides touch on other things like importing, but yeah, we'll touch upon that in a couple of slides. So again, they enhance readability. That's their purpose, making code easier to read and understand. Also, facilitate maintenance, as we already have covered, because code that is easy to understand and easy to read it should be very easy to maintain. So, yes, again, we touch on collaboration. Teams or large teams, or all of the members, if they adhere to the style guide, the coding standards, and the conventions that have been set, will make collaboration a little bit easier. People have their own thoughts; people have their ideas on how code should be written. They have their own styles. But if we all adhere to one single style, that makes it easier.

13:08
César: They also promote best practices because they encourage, well, they lead to more efficient, reliable, and secure code. And finally, they streamline code reviews. You'll see this if, for example, you have your code on a repository, whether Git, not specifically just GitHub or Azure DevOps, any other. If you go through a process, like a pull request, going through the code will make it very easy if everything is following the same style. Some of the most well, popular, not all of them, of course, but for Python, for example, we have PEP 8. We have also the Google Python Style Guide for Java. For those who are also Java developers, Google also offers a Java style guide.

14:05
César: And for C#, well, of course, Microsoft has its own coding conventions. So these style guides establish, again as we touched, is, they establish a set of rules and conventions for writing code and as well promoting consistency, readability, and maintainability, and all the topics that we have already touched upon. So these style guides, I'm not gonna ask you to read through all of this. This is just one of the, let's say, Easter eggs of Python is the, just a poem of some sorts that sets some of the main philosophies or the main philosophy of behind Python. One of the things, beauty, data, it touches upon beauty and elegance. So that means that there's a value in quite beautiful and elegant code with an emphasis on doing things the right way.

15:08
César: It also touches on explicitness. So being explicit is better than implicit, and clear code is preferable even if it's longer. Another one of the key topics here from the Zen of Python is simplicity and clarity. So simple is better than complex, and readability counts. Code should be easy to understand. Practicality beats purity. And while ideals are important, practicality takes precedence. Another thing, errors as learning. So errors should never pass silently unless explicitly silence. This emphasizes on learning from mistakes and also one way to do things. So there should be one, and preferably only one, obvious way to do something. So this will encourage consistency in coding practices.

16:15
César: So this guide PEP 8, well, just a little bit of background here. A PEP it's a Python Enhancement Proposal. So these are proposals that are submitted to the Python Council and are voted and approved or rejected. And PEP 8 is the style guide for Python code. It was written in 2001 by Guido van Rossum, the creator of the Python language. And the primary focus of PEP 8 is to improve the readability and consistency of Python code. One of the things that you should keep in mind is that PEP 8 is a guideline, not a strict rule set. So it's flexible. Some things can be broken. You can also just ignore all of them or most of them. But yeah, it is a guideline, not a strict rule set. Well, I'm just gonna go back. So yeah, we have some key guidelines. In this case, it's spaces over tabs, keeping your code to a maximum of 79 characters or 80. It also gives you some thoughts or suggestions on how to name your variables, how to group your imports, and touches upon docstrings, which we'll cover in a couple of slides. The other one is the Google Style Guide. I touch upon this one because one of the things that it's being used for in Ignition is for the docstrings. So one of the main the way that they, well, yeah, they suggest you to write your docstrings. It's one that is supported in Ignition.

18:10
César: So in the designer, if you add the docstring to your functions using the Google style, you will get code completion. That was introduced in, but I don't remember the version exactly, but I do have it here. Well, it adheres mostly to PEP 8, but it has its own exceptions. But yeah, again, it emphasizes on code clarity and maintainability. Another one that it's also one of the guides or guidelines that was created here by Inductive Automation. They do have their own guideline. If you haven't seen it, I do have a link to that that will take you to the PDF document. So it was, yeah, created here by Inductive Automation. Again, its purpose is to improve readability, consistency, compatibility. So, the same topics or same key guidelines that we have discussed.

19:11
César: Also, it has some differences between the things that they suggest with PEP 8. And, yeah, again, we see indentation, in this case, tabs over spaces. So, naming conventions also differ from PEP 8. Instead of Snake Case, they suggest the use of Camel Case. Pascal Case is the same also for Python. And Docstrings, as I had mentioned, they conform or they adopt the Google style. So, in this case, you will just see some of the key features and where's the difference between all of them. Alright, well, just a few, another addition here. Yeah, you will see also this mention of PEP 8s, or sorry, PEPs, or Python Enhancement Proposals. We have touched upon docstrings. Python also has its own style. But, yeah, there are also many others that are supported by, for example, PyCharm. PyCharm suggests the use of NumPy. NumPy has its own docstring standard. There's another one, yeah, but the PEP 8 and Google style. Might be missing another one, but, yeah, the one that matters the most is Google in this case because it is supported by Ignition.

20:39
César: So, in this case, I'm using the same code example from a couple of slides ago. This is the same Python code, but using the Ignition Exchange Style Guide. So, you will see that this code, instead of using a Snake Case, it's using their convention, so Camel Case. Still, it remains readable and easy to understand. In this case, for docstrings, this is the Google style. So, this is something, again, that is supported by Ignition. So, not only do you get code completion on system libraries, and, yeah, this feature was introduced starting with version 8.1.32. So, when you see some code like this, you will get on your designer, or even in the scripting console, you will get code completion on your function, even though it's not part of the system library.

0:21:46.2
César: Now, bringing all of these together, it's the toolset. Which tools you will be using, or which tools I recommend for enforcing or for implementing the style that you have chosen? The ones that I recommend using an IDE, Ignition Designer, I consider it as an IDE because it's your graphical interface for developing your applications. If you're only working on code, PyCharm and Visual Studio Code are also great tools. Using Python, and lastly, but not less important, Git. As we have seen the shift in Ignition, moving some of the scripting or the components of the projects into the file system has made it easier for us to store that information into a Git-Repo. And we have version control, we have the history, we have other tools that can look into those changes and verify them. But, yeah, I don't know if all of you are extremely or very familiar with Python, but just to set the stage, what is Python? We have Python, CPython, Jython; you would see these terms being mentioned on the internet or on the forums as well. So in this case, Python, as we can see here, is the language specification.

23:27
César: So if you learn the Python programming language and you write some Python code, you then need something to run your Python code. In this case, it's this. CPython, let's say, is the correct or actual name of Python that you download from Python.org. And when you run Python on your command line, this is what you're running most of the time, almost every time. It's based on the C language. That's why it is prefixed with the C. But, yeah, the term is interchangeable. You will see Python being called, or CPython being just called Python. And Jython, it is Python, but for the Java platform. And Ignition uses Jython. Back in the day, when I was working on 7.7 projects, it was using Jython 2.5 as its coding or back end. Nowadays, the latest version comes bundled with Jython 2.7.13. And in this case, Jython 2.7, it's almost a one-to-one to the CPython standard library. And it supports most of the language standards for language settings. It conforms to Python up to 2.7.13, according to their documentation. And for this, which versions do I use?

25:08
César: For Python, well, we see Python 2.7. I don't know if you've heard of it. It's been discussed in other ICCs. 2.7 has reached end-of-life. It's been dropped, as I mentioned, from the runner images on GitHub, which are also used by Azure DevOps. It is no longer maintained. It is no longer, you don't have any versions starting from April. Well, the last version was released on April 2020. But we see Jython in this case. Jython is still being actively developed. The last version, I think, they have already moved to 2.7.14. And I think it's 15 on the worst by now. Yeah, it's using the, it's all, well, it sits between two worlds. So you can use Python code, although not most of the libraries or some of the libraries that are purely CPython. But you have, and you can tap into the power of Java or Java libraries. And you can also import JAR files from third parties that, well, are compatible with Java 8.11 and up to Java 17. And for Python 3, which can be used for installing some of the tools that I'll be describing next, the last version right now it's 3.12. Well, a couple of weeks ago, it was 3.12.6. 3.13 is in the works is in the release candidate version, so it will be released. But why do I touch on Python 3? Python 3, it's the version that I use for installing all of these tools that check into my code, which will be discussed here.

27:06
César: So also part of the toolset, you would have some things like code formatters. In this case, they're also known as autoformatters. These are programs that refactor your code, and most of the time some of these adhere or conform with PEP 8. And for example, black, it autoformats your code using its own style. It says that you can choose any color as long as it's black. I think that's their motto. But yeah, as I was mentioning, PEP 8 is a style guide. It's a guideline, not something to be enforced. So in this case, also black just drifts a little bit from the length of the code. But yeah, we won't get into too much detail on that. But yeah, you have also tools like Autopep8, YAPF, which is a tool developed by Google. And most recently, you see some things like Ruff. This is an application in this case, because you can run on a CLI, that is written in Rust. It's very fast, and it bundles some of these other libraries that we see here on the bottom. That's why you see it pop up here, here, and here, and here. So Ruff, it's, let's say, a combined tool from all of these. Import sorters, as we saw for PEP 8, it has its own standard. It has its recommendation for sorting your imports. Like the standard library should be at this level. The imports from your local library and from third party should be next or on the bottom line. And we also have, again, as I mentioned, Ruff, which can also sort your imports.

29:04
César: For static analysis, we have tools like Flake8. This is also a combination of other tools, like McCabe, PyFlakes. But these tools, what they do is they analyze your code for flag errors. So they will check your code and see that it conforms to a certain style. So in this case, Flake8 will look at if you're missing an import or if you imported something and you're not using it, and so on. Another set of tools are linters. In this case, there might be many more, but in this case, I'm highlighting Pylint and Ruff. In this case, linters are programs that analyze your code, as I mentioned, for flag errors. So they provide suggestions on how to fix each error. So they will give you a code for each error, and that will give you an idea of where the problem lies. So these are particularly useful when you install them as extensions to your text editor or as part of your toolset. And in this case, these popular linters, in this case, they will show you that exactly. They will flag these errors and will tell you even the line where it lies.

30:36
César: Also, finally, I'm not gonna touch upon, because this is a more advanced topic, but type checkers. You have all of these below, Mypy, Pytype, Pyright. In this case, type checkers, so these are tools that help you ensure that your code adheres to a specified type annotations. So, for example, in one of your functions, you say that this first argument must be an integer. And if you, on your call to that method, you're passing a string, that would get caught and marked as a probable error. So, yeah, as I mentioned, Ruff, you see it on many of these categories. Again, this is a tool that has been recently published and released to the community, well, to the Python community, and it's gaining some traction.

31:36
César: So, another tool, it's called pre-commit. In this case, it relies on git hooks. It suggests that you should have your code stored as a Git. Repo. And Git has its own hooks. This is also an advanced topic, but pre-commit is a tool that has been created. As soon as you're committing your changes to the repo, it runs a set of tools. Those are configurable in a file. I will have an example here on a few slides. Yeah, one of the recommendations is that order matters. So, that's why we're touching upon linters, style checkers, and all of that. So, you should have, at least on this order, you should first run your code formatter. Like black, Ruff, YAPF, then sort your imports, run your checks, and any other tool that you might want to add on its configuration.

32:40
César: So, you might be wondering now how to get started. Because starting might be daunting, especially on a code base that has been sitting there and might not be conforming to these styles. So, the recommendation is to start small. You can start on a single file. You can start on a whole project if you wish. But yeah, start small. You should pick your own tools. In this case, select from all of the list of all of the available tools that are out there, choose the ones that will talk to you or the ones that you want to implement. And finally, set your own standards. As we have seen, these style guides, like PEP 8, the Ignition Exchange Style Guide, and the Google Style, they share some similarities. They do have, all of them, the same goal, but they do have their own differences. And so can you. You can set your own standards and follow them, and apply them to your projects. And how can you start?

33:51
César: Well, all of these tools can be configured. They're highly configurable. For example, Ruff has its ruff.toml file. I've just added some of one of the key things that I want to highlight. For example, these would adhere to the Ignition Exchange Style Guide. So, we would be using tabs instead of spaces. And also, these tools are very well documented. So, if you want to learn more about them, and most of them are just sitting on GitHub and have the links for their documentation. PyLink, for example, has also its own file that you can use for configuring it. It could be either sitting at the project level, it could be sitting at the computer level for all of your projects, and also highlighting some of the things that you can configure in this. So, you can say that your arguments should be Camel Case. The default, as well, again, for PEP 8 is Snake Case.

34:56
César: But you can configure all of these and also indent instead of spaces. We see that you can configure it to accept tabs. Flake8, same thing. You have your own file to configure it. Most of these tools, you can also write exceptions inline. This means that you can add to your code something like this. Again, each tool has its own specific error codes and has its own way of us adding these exceptions. In this case, this is for Flake8 in particular. You can also have your file that this would be applied globally. But, yeah, if you want to exclude some things in some files and not just a blanket on top of your whole project, you can do it like that. Pydocstyle, I mentioned this tool as well, because I use it internally. And, again, you can check if your code is conforming to a certain style. More are supported, of course, but in this case, this is how you would configure the Google style. And it will check that your docstring is conforming to this style. And how to put all of these together? You would have, well, preferably all of these files sitting at the root of your project.

36:29
César: And using pre-commit on a Git. Repo, every time you run commit, it will run these tools in the order... Oh, sorry, in the order they're presented. So, for example, for Ruff, they have their own hook, which is Ruff pre-commit. You have a version that you're running and what you're doing. Ruff, in this case, what I'm using it for is for formatting, because the rules that they run, they're using the latest Flake8, which is another thing that I can spend many hours talking about this. But, for example, the last version of Flake8 that supports Python 2 style code or Python 2 code is 5.0.4. I think now it's on version 7. But you will see this as a recurring theme because Python 2 has reached end-of-life. And some of these libraries are just moving forward and just dropping support for Python 2. But I'm keeping it alive. One of the things that I created, as I mentioned in the first slide, is six, the Docker image, that I run on my CI/CD pipelines on Azure DevOps and on GitHub that comes with Python 2. So that's the workaround that I found.

37:51
César: And running pre-commit, here's just a simple example of running pre-commit on your command line that will run all of these checks on your code, and it will flag any potential error. If everything goes well, you'll see all green, and that's what we're expecting. So, yeah, these are some links where you can check my sources. And I think we're doing fine. All right, so that's my presentation now. We can go into Q&A.

38:33
Chris Andersen: Thank you. Just kind of opening up for the Q&A session. Going right here in the middle.

38:48
Audience Member 1: What would be a reason for using four spaces over a tab?

38:53
César: I'm sorry?

38:54
Audience Member 1: What would be the reasoning for using four spaces instead of tab for your indentation?

39:00 César: Okay. Well, yeah, as I was mentioning, PEP 8, for example, the guide created by Guido van Rossum et al., or other people, they desired or they chose spaces over tabs. Why exactly? That's up to them. But if you open Python code on any IDE, for example, Visual Studio Code or PyCharm, by default, they're gonna be using that standard. If you press Tab on your keyboard, it will add four spaces immediately. Why settle on that? Because most of the tools that I have mentioned, like Black and Flake8, and all of them, are using PEP 8 as their base. So that's why you would have to tweak them or to configure them into using tabs instead of spaces. But the PEP 8 standard says that you should be using spaces. Ignition Exchange Style Guide says tabs. Again, if you go into the Ignition Designer and you start writing your code, if you click tab, you get a tab character, not four spaces. So it's either whatever you choose is good, but as long as you adhere to that. Because if you have code, for example, that is mixing tabs and spaces, you will get errors. And you will see that on the Ignition Designer. You will see that on your IDE. So yeah, choose one and stay with that as long as you like. As long as it makes sense to you, you can choose any. But not both.

40:34
Audience Member 2: In cases where you're trying to or you need to call Python 3 code, do you have a preferred way to use, call it a Python 3 service from Ignition, like Flask or Bottle, one of those?

40:49
César: We do have some instances for that where we use the Web Dev Module to run some Python code and be in running some REST API services. But, well, that goes beyond this conversation. In this case, what I use Python 3 for specifically to this topic is just installing all of these tools and running code checks. But yeah, it's definitely something that I believe Kevin McClusky has a very well opposed, probably in the forums or on the knowledge base on Ignition, on the Inductive Automation side. Yeah, he touches upon also the differences between Jython, Python and how you can run Python 3 for some cases like that.

41:38
Chris Andersen: Or waiting for other people to formulate questions. Maybe you wanna elaborate a little bit on your GitHub library you were talking about earlier.

41:44
César: Sure. Okay. Well, as I was mentioning, my experience with Python started when I started working with Ignition. And I was coming from a Java and C# background. Python, I liked it. It's very easy, very simple. You don't have to mess with colon, semicolons. If I missed one here, if you have a C, C++, or other background, you would relate to that. But in this case, it's that Python relies on just white space and indentation for four loops or for just structuring your code. So yeah, I started creating; I created the Ignition API library back in, I don't know, like 2018, 2017, internally for the company that I worked for. Then I decided to just publish it on GitHub. It has switched organizations, but I think it's found its final resting place. It's still being active. So as soon as Ignition comes up with a new version, I also make the changes on the code base so you can have that code completion. One of the, well, a few members here from the community, like Keith Gamble from the Design Group, has contributed to a poll request to that repository.

43:12
César: So also if you click on one of the links, it's sitting now under the Ignition-Devs GitHub Work, where I also have other projects where you can use that, or there's a dev container base. Well, also dev containers is another topic, but copier Ignition templates. So I have a readme for that, where you can just easily install with Python 3 the copier tool, and you can choose which type of project you're gonna be working on, and it will be using the tools and standards that I use. The Ignition API library, well, I think it's quite popular. I thought I was gonna be seeing a little bit more hands raised. But yeah, it's something that I use, and I found it very useful for me and my team that I just posted there. And yeah, anytime you have questions, feel free to reach out through any of the channels that I have.

44:19
Chris Andersen: I have just one question. So there's a lot of pre-built tools with Ignition. So how do you decide when you're doing pre-built versus gonna scripting using both? What's kind of your approach to that? It just depends on the project, I guess?

44:33
César: Yeah, well, most of the things that we do, well, I'm mainly focused on the scripting side of things because we have our own structure. We have our own internal modules that we use. But yeah, usually our everyday tool is either PyCharm or Visual Studio Code, because we can use and import other libraries to make it easier on ourselves to work on other projects.

45:04
Chris Andersen: All right. Well, we'll end the session a little bit early. If you do have any questions, feel free to reach out. That concludes the session for today. So thank you very much. Let's give it up for César.

45:14
César: Thank you.

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.

05:56
Drew Miller: A history on the history API.

06:00
Drew Miller: That sounds really boring. Do you have the Cliff Notes for us here?

06:01
Carl Gould: Yeah, you got it.

06:02
Drew Miller: Okay.

06:02
Carl Gould: Let's talk about that Tag Historian API. So the Tag Historian API is the interface in Ignition that all history must conform to, all history and implementations. And it was introduced in the very first version of Ignition, version 7.0, nearly 15 years ago. And at the time it was introduced, the tag system was relatively new. And at the time, all history was being stored to databases using transaction groups. And little did we know how transformative and successful this API would really be. So today, the vast majority of historical storage and querying in Ignition goes through this original Tag Historian API.

06:43
Drew Miller: Now, with 15 years of experience under our belt, we took this opportunity with 8.3 to make some important and fundamental improvements to the design of the API to support today's ecosystem of time-series technology. Let's name a few highlights. So before 8.3, aggregations and calculations were performed in the platform using raw data from the historian engine. Now, historians can implement custom aggregations and can handle the processing of the aggregations themselves. This means that the calculations can be done within the engine itself, saving massive amounts of data transfer into the gateway, saving CPU, and most importantly, memory and time.

07:27
Carl Gould: In the previous API, all the historical data was packaged up at the source like a tag and then put through the store-and-forward system and then given to the historian engine on the other side of store-and-forward. And this made it difficult for historians to be able to capture important context about where the data came from, like modeling information or state transitions about that data. So, this new API corrects this issue by allowing historians to plug directly into the source of the data and not have to have the data be transferred through the store-and-forward system, which will allow historians to understand more context about the tags and the tag model. And that context can then be used to interpret state transitions correctly, as well as to store modeling information and context with the data, which should allow us to develop a richer contextual query model.

08:29
Drew Miller: And lastly, the historian uses a path model to identify data sources. Of course, when we think about history, we think mostly about tags. But there are actually lots of kinds of data in Ignition that could be historized, alarm data and model definition data, to name a few. The new API allows for many kinds of data to participate. And as an added bonus, engines can now handle when the path to a data source changes. So, if you rename your tag, your history can be mapped to the new name.

09:07
Drew Miller: Well, that's good. I thought we were going to lose them on the history lesson here, but let's pluck another item out of the basket.

09:12
Carl Gould: Let's do it.

09:13
Drew Miller: What's next? Oh, check this out. Sound the alarms, everybody. And this one's not a nuisance either.

09:22
Carl Gould: We don't have much prop budget.

09:27
Carl Gould: Alright. So, we want to share an important update with you about alarm management and alarm notification. So, in 8.3, we introduced an important new concept in the alarm model called alarm aggregations. And what this does is allows you to get at a first-class solution for aggregating alarm statistics at the tag folder level and at the UDT instance level.

09:53
Drew Miller: That's right. So now, you can quickly count the number of alarms in a critical state, display the highest active priority within a group, or sum the number of unacknowledged alarms for a specific area. With alarm aggregation, you no longer need scripting to derive or calculate these numbers. Instead, they're now properties exposed at the folder level that can be directly subscribed to.

10:16
Drew Miller: Yeah.

10:19
Carl Gould: Yeah. That's going to be real nice. Alright. And so staying on the topic of alarms, we want to share some features that will make notification seem as outdated as sending them through carrier pigeon.

10:32
Drew Miller: Fly out of here, little buddy. There you go.

10:36
Drew Miller: Alright. In Ignition 8.3, we've introduced Twilio voice notification and WhatsApp messaging. Expanding Twilio capabilities within Ignition is a great example of how we at Inductive Automation like to first make it simple and then make it easy. Or make it possible, then easy.

10:52
Carl Gould: Simple and easy. Yeah, same thing.

10:55
Drew Miller: By leveraging more of the Twilio platform, you no longer need to procure your own SIP server to implement voice notifications from Ignition. So now you can create custom call scripts, text-to-speech, broadcast calls, and implement pin authentication alarm acknowledgement, all while Twilio Voice does the heavy lifting.

11:12
Carl Gould: And you can also reach a wider audience because we've also integrated the use of WhatsApp into the Twilio Module. So WhatsApp is probably the world's most popular messaging platform and now we can utilize it for alarm notification. So, these additional alarm notification channels using the Twilio Module should make it a lot easier to build sophisticated notification systems because it eliminates the need to deal with physical cellular modems or manage your own telephony infrastructure, which can be kind of burdensome.

11:43
Drew Miller: Speaking of sending messages, I think our next feature might be somewhat related here. Oh, boy. A box of cereal. Tell me this isn't a cheesy serialization pun.

11:55
Carl Gould: You know it is.

12:00
Carl Gould: I literally pulled this out of my pantry this morning.

12:05
Carl Gould: There's a lot of places in Ignition where we have to send messages across the network, right? So, for example, between Ignition gateways, we have the gateway network. And here we send dozens of different kinds of messages to support all the various things the gateway network is used for, remote services and the EAM. And when we have to send these messages, they have to be serialized, right? We have message objects and they need to be serialized, put on the wire, and sent across.

12:32
Drew Miller: Similarly, between the Designer or Vision client and the gateway, there is tons of active communication to support both of those applications. Since the beginning of Ignition all the way up until 8.3, the messages sent on both of those channels were encoded for transport using a technique called Java serialization.

12:51
Carl Gould: Yeah, unfortunately, this is a technology choice which didn't age very well. You know, I talked a little bit in the keynote about technical debt. This is a good example of what technical debt is, right? Any software that lasts long enough will have some kind of technical debt. You make some sort of technology choice. It doesn't age all that well. This would be one of those. Because it has been shown that this Java serialization technique is susceptible to a certain class of security vulnerability. Now, I wanna make it clear that there are no known vulnerabilities of this category in Ignition. We do protect against this type of vulnerability using secure channels and using a mitigation technique called object whitelists.

13:33
Drew Miller: But in 8.3, we decided to do the work required to rid the platform entirely of Java serialization just as a precautionary measure. In 8.3, all messages are encoded using protobufs instead. This technique is fundamentally secure and it actually happens to be more efficient too.

13:51
Carl Gould: So, while we were doing this work in the network channels of Ignition, we also added an important upgrade to the Vision Module. The Vision Module now communicates... Phil's happy. The Vision Module now communicates using persistent web socket connection, which means that you don't have to pull for tag changes anymore. They can just be delivered unsolicited from the gateway when a tag changes, resulting in a lot less network traffic and faster update rates as well for the Vision Module.

14:22
Drew Miller: Okay, let's take another peek at what's in the basket here. I've got some manila envelopes. Take a guess at what could be in there. Configuration, of course.

14:33
Carl Gould: File folders. In 8.3, all the configuration of the gateway is stored in a logical file structure in human-readable JSON files. So, as we said in the tech keynote, 100% of the configuration top to bottom is now compatible with Git.

14:51
Drew Miller: Which these files are designed to be easy to interpret and encoded so that they are friendly to these diff tools. Source control systems like Git unlock the capability to develop, branch, merge, track changes, and strategically deploy using a centralized configuration repository. So, what we're going to do is we're going to break things down and take a look at how this configuration is stored on disk.

15:14
Carl Gould: Okay. So, we're going to get into some detail here. So, the configuration is stored in a structure that is going to look really familiar to any of you who've peeked into our project storage system that we introduced in 8.0. So, let's take a look at an example of just a single configured resource, in this example, it's a device connection. So, the resource is stored as a folder with configuration files in it. Most configuration resources store their settings in a JSON text file called config.json, but resources have the opportunity to store other configuration files in addition if it's appropriate for that resource type. So, for example, a Modbus device might also store your address mapping in a CSV file, for example.

16:02
Drew Miller: Above the resource layer, resources are grouped by resource type. So, all of your devices will be together, all of your database connections, etc. And above that layer, the grouping separates the configuration of different modules and the platform. And then, lastly, above that is what we call the resource collection layer.

16:23
Carl Gould: There are multiple collections of resources, and this is where things get kind of interesting. So, your configuration is organized into different collections that have different specific purposes. So, we're gonna go through each collection so you can understand how they all fit together and how you might make the most use out of them. So, most of your configuration is going to live in a collection called Core. This is where if you just go through the web interface and make a new resource, it shows up in Core. Above Core is a collection called External. External is where you can mount configuration from an external source like an orchestration operator. So, if you wanted to inject configuration into a gateway by mounting shared files from somewhere else, you would put them inside of External.

17:13
Drew Miller: And above that is a collection called System. And this is where module authors have a chance to inject configuration. This can be useful for providing configuration that is always present or for using the module system to encapsulate an entire application so that it isn't editable once it's been deployed.

17:31
Carl Gould: Now, below Core, we have a system called Deployment Modes, which we're going to get into in some detail in just a few minutes, so we'll skip that one for now. And below that, we have a collection called Local. And Local is a place where you can put configuration that is specific to your host machine. So, there's some kinds of configuration that basically you don't want synchronized to a backup node in a redundant pair. And that's really what Local is for. So, if you imagine something like a certificate that has the host name embedded in it, you don't want that. You want different certificates in your primary and your backup node. Local gives you a place to put configuration that won't be replicated.

18:15
Drew Miller: This stack of configuration collections all inherit from one another, combining to create a cohesive set of configuration for your gateway. So, now we're gonna look at these various collections and how you might use them together.

18:28
Carl Gould: Okay, let's look at some examples of what might go where. So, you might get your JDBC Driver configuration from our new JDBC Driver Modules. In 8.3, we're able to now package up the JDBC Drivers we ship with Ignition as modules, which makes it easier for us to keep them up to date. You could have, as I explained before, some centrally managed configuration that got mounted into external by mapping a volume in a container orchestrator, your normal configuration that you configured through the web interface shows up in Core. And then again, you might have certificates inside of Local.

19:06
Drew Miller: The gateway then automatically combines the configuration from these collections into one set of configuration. This combination is what your gateway actually runs. Because of the way that the collections inherit from one another, you can also override configuration provided by another layer.

19:22
Carl Gould: So for example, say you don't like the version of the JDBC Driver that we shipped with Ignition, no problem. Just define your own configuration for JDBC Drivers in Core and it will override the version from System. And this works for any kind of resource. You can override any reconfigured resource in a lower level. So, hopefully, you're starting to see how this design offers a really incredible amount of flexibility and power for fine-tuning and really specifically managing how the configuration of your gateway works and is organized, and can be packaged and deployed across various gateways and between redundant pairs. So some of you might be thinking though, with all of this configuration in nice human-readable files on the file system, aren't there things in my configuration that might be a little bit sensitive that I don't want everybody looking at?

20:21
Drew Miller: That's right. We have something for that.

20:22
Carl Gould: Yeah, I think we do.

20:23
Drew Miller: I'll just take another look in the basket here. Well, check this out, a cryptex.

20:28
Carl Gould: What is that? It's so small.

20:31
Drew Miller: It's a clever little device that holds a secret message inside. Oh, I can open it here. And what does it say? It says, "Don't store your passwords in plain text, silly."

20:42
Carl Gould: Sage advice. So, yes, your configuration is often full of secrets. What's a secret? Things like an encryption key or a private certificate or a password. Those are all secrets. And with your configuration being so readily exposed to so many people who, you know, the various engineers working on your system or people managing the source control repository that you may be checking configuration into, or even if you package up configuration and send it to our support team, you start really having to think about not exposing the secrets that are inside of your configuration.

21:22
Drew Miller: Of course, this isn't just a problem facing Ignition. All software shares this challenge, and that's why there's an entire ecosystem of IT solutions to help manage this problem. The most popular solution is a product from HashiCorp called Vault. Secrets managers like Vault can send your secrets securely and only provide them on demand to systems such as Ignition through secure validated connections.

21:47
Carl Gould: So, in 8.3, secret managers are now an extension point of the platform. So we have two implementations and one of them is an internal implementation that right out of the box makes sure that the secrets that are embedded in your configuration are encrypted securely. The encryption uses a key that you can provide to the gateway and it's encoded in such a way that it supports a graceful key rotation mechanism. Or of course, the other implementation is the HashiCorp Vault implementation, where your secrets are not stored in your configuration at all. They're just references to a name secret stored inside a vault. This way when Ignition is running, it's able to grab the secret from HashiCorp Vault and use it and then throw it away when it's not needed anymore. So it's not persistent at all.

22:38
Drew Miller: This way you could share your configuration and put it in source control with a lot less worry about this sensitive information being leaked. But what if you need to configure different credentials in different environments? For example, what if you want your development server to connect to your database using a less privileged user than your production gateway, so that your development server only has read access, for example. I think we have something for that as well, right?

23:04
Carl Gould: Oh my. A giant chameleon.

23:06
Carl Gould: A creature that can change its colors to adapt to any environment. Here, the pigeon needs a friend.

23:12
Carl Gould: There you go, buddy. There we go. That's nice. They can be buddies. Alright. So yeah, in 8.3 we have this fun new concept called deployment modes. And that is gonna really help you solve this challenge of dealing with multiple deployment environments.

23:28
Drew Miller: Many of you are building sophisticated deployment pipelines for your Ignition applications where development, testing, and production are all done on separate systems. Managing the deployment transition between these environments can be tricky because there are often subtle differences between each one.

23:45
Carl Gould: Okay. So, the idea always sounds simple enough, right? Make development changes in isolation and then test them and then push the changes to production. Sounds great on a whiteboard. In practice, this is pretty tricky to pull off gracefully. So, one of the big complications is that each of these environments might have different configuration from the other one, and then you're in trouble when you need to deploy from one environment to the other. So, in production, you've got production assets, but you don't wanna connect to those production assets in the other environments, maybe you wanna have different security settings in your dev environment than your production environment, because of the rapid change of innovation happening in dev, maybe the security's getting in the way. There's all kinds of reasons why these different environments have different configuration and then it makes deployment really challenging.

24:43
Drew Miller: Deployment modes helps to solve all of these challenges. So let's explore how it works. You remember the diagram from earlier. This is where deployment modes fits into the configuration system. With deployment modes, you can define any number of modes. To keep things simple though, we're gonna define two: development and production. Now, you have the opportunity to define alternate settings for any configured resource within these modes. You could have a device defined with different settings for each mode. For example, in development, this device could be a simulator, but in production, that device would actually be a Modbus device, a production asset.

25:21
Carl Gould: The thing to really understand here is that these are alternate configurations for the same resource, and the gateway will then automatically load the different settings based on whichever production mode, I'm sorry, deployment mode that it's in. So if you're running in dev, it'll be a simulator. If you're running in production, it'll be an actual connection to the Modbus device. But to the rest of the system, like the tags that may be referencing that device, it's the same device, same device name, etc. It looks like one logical entity that just behaves differently in different environments. And devices are just one example. But this is a fundamental platform-level feature of the entire configuration management system. So, it works with any kind of resource that you want it to. So if you wanted those different security settings, no problem. Security settings are just another kind of resource, so you can define different security settings for the different deployment modes. You wanna use different certificates in different environments. Now again, that's just a resource. So you can define different settings for different modes. So everything works really gracefully with the system.

26:27
Drew Miller: The beauty of this design is that all of the configuration, both the settings for development and the settings for production, they're all contained within one cohesive configuration set, which means one gateway backup. In development, you can review and change the settings for production even though those settings aren't active. This way, the deployment from one environment to the next can be an atomic migration of all the configuration, instead of surgically moving specific resources between servers, which is a very risky maneuver.

26:58
Carl Gould: And of course, the idea is fully integrated into the new web UI, since we were rebuilding it from scratch anyways, which means that even though that might have sounded kind of complicated, in the UI it's really pretty simple, right? You go into a resource and you just have the opportunity to define overrides that are active in different modes. It's really pretty straightforward. So, speaking of migrating configuration from one environment to the next, how might you actually pull that off? Let's see what is next in the basket of goodies?

27:32
Drew Miller: Oh, I have something for you here.

27:33
Carl Gould: Oh my, a conductor's wand, I can finally fulfill my musical ambitions. No, of course, we're talking about orchestrating the gateway, not an orchestra.

27:49
Drew Miller: Let's circle back to that topic of APIs. I mentioned Ignition 8.3 comes with a built-in RESTful web API to configure the gateway itself. This API can be accessed through secure API tokens that you can generate. And best of all, it's fully documented using a standard OpenAPI-compliant specification file. This spec is fully embedded within the gateway and it's dynamic based on which modules are installed. So, it's always accurate. One of the great things about OpenAPI is the ecosystem of tooling and support that exists for it as well. So if you're trying to interact with this API in an external system, chances are you'll be able to generate a client API library in that system's language using this OpenAPI specification file. And it also comes with a UI so that you can browse and search through all the endpoints and see exactly how to use them with detailed information about the schema and the payload.

28:44
Carl Gould: Yep, APIs are way better when they're documented.

28:50
Carl Gould: Far more useful. And yeah, this API is really going to enable external actors like those container orchestration systems, CI/CD systems, even just a simple scripting setup to be able to view, diagnose, and manipulate the configuration of a gateway from across the network. So, taken all together, all of these new features, the file-based configuration, the distributed source control compatibility, secrets management, deployment modes, and this RESTful web API. Taken together, they really create this compelling set of features that makes sure that Ignition is really poised to be able to be natively and gracefully integrated with the kinds of modern orchestrated IT-managed enterprise architectures that many of you are working with today.

29:41
Drew Miller: That's right. And what these technologies promise is really truly revolutionary compared to traditional systems management. Technologies like Kubernetes with Helm charts make our classic approach of first running the installer and then configuring look archaic. So, containerization not only allows you to install quickly, but rapidly stand up complex architectures, easily keep them patched, and keep your systems running smoothly with well-orchestrated deployment strategies.

30:11
Carl Gould: Yeah. We're really looking forward to building and releasing a lot of additional resources over the next year as we explore the promise of putting all of these technologies into action. We're working on deliverables like Helm charts, which are really amazingly compelling way to bring all these technologies together, as well as additional educational materials, new IU videos, etc., to make sure that we're all clear on what the best practices are as we put these systems into production.

30:42
Drew Miller: And more importantly, we cannot wait to get this release of Ignition into your hands. With 8.3, we feel that our platform has been modernized to the point it is now poised to deliver another wave of innovation really in any industry. And we know the community in this room is going to be the group that makes it happen. So, this will conclude the updates to the Ignition platform. Join us in the next session. You can still see we have some features left in the basket here that Matt Raybourne and Reese Tyson are gonna cover. But at this time we'll turn it over to questions.

31:14
Carl Gould: Yeah, questions. And I believe there's mic runners.

31:17
Drew Miller: Very eager question.

31:18
Carl Gould: Phil's very excited to ask a question.

31:22
Carl Gould: Who's gonna get to Phil fastest?

31:27
Drew Miller: He's also really excited about Vision updates.

31:32
Audience Member 1: So, you've not left me very many things to pick at here.

31:41
Audience Member 1: But I did notice the Historian API appears to be replacing the Tag Actor API, is that going away or being deprecated?

31:55
Carl Gould: I wouldn't say it's replacing it. I would say we just made the Tag Actor API better.

32:00
Audience Member 1: Okay.

32:01
Carl Gould: Does that make sense?

32:02
Audience Member 1: So, if I develop against it, it's relatively safe?

32:07
Carl Gould: Yeah. You may have some migration to do on your modules. Any module authors in the room, you got some work to do.

32:16
Carl Gould: The backwards compatibility promise does not apply to APIs over major versions. Right. But yeah, the capabilities absolutely still supported.

32:24
Audience Member 1: Okay. I got nothing else.

32:26
Carl Gould: Oh my God.

32:27
Carl Gould: We did it.

32:41
Audience Member 2: I started coming to the ICC about three years ago and what I found out is ICC is code word for hold my beer to the rest of the industry.

32:52
Audience Member 2: But are there any plans to expose, let's say you talk about event streams and whatnot, but events within the tag database, to expose them publicly such that you wouldn't need modules?

33:06
Carl Gould: Exposing tag events publicly. In what way? Like you wanna be able to subscribe to tag events?

33:14
Audience Member 2: Yeah. Think of the things like, you know, when somebody adds a tag or deletes a tag instead of having a full...

33:18
Carl Gould: Oh, oh, I see what you're saying.

33:20
Audience Member 2: Yeah.

33:21
Carl Gould: Like you want to be able to subscribe to changes natively through like a RESTful API or something?

33:28
Audience Member 2: Something like that. Like tag data, change that...

33:32
Carl Gould: Right. Tag configuration changes. Are there any plans for that? No. Concepts of plans.

33:42
Carl Gould: That was Drew's joke. I stole it from him. It's an interesting idea. I don't think it would be... What I would like to do for that, so one of the neat things is that tags are just configuration also. And so, what I would prefer to see for that idea is it not to be specific to tags, but I don't know exactly how we would pull it off, but it's an interesting idea that we'll think about. Yeah.

34:09
Audience Member 1: You can do the tag through module.

34:11
Carl Gould: Well, yeah, but he doesn't want to do it through a module, he wants to... Right?

34:15
Carl Gould: 'Cause you could do that as a module today, but...

34:26
Audience Member 2: Sorry. Like, what Sepasoft does with the MES events. When you create a new MES object, you can trigger an event and sit there and hook into things or whatever. Same sort of idea, like with tag creation, right?

34:39
Carl Gould: Yeah. No, I get it. It's a fun idea. And the system is really well suited now to be able to do that in a consistent way across any type of resource. Because you're interested in tag configuration changes, but someone else might be really interested in certificate changes. I know they are. So it would be, I think, best to do it at the resource layer, which is now nicely consistent across all kinds of resources. So, it's a fun idea. Thank you.

35:08
Audience Member 3: Hi. So, I saw an Ansible logo in the keynote, but in the deep dive, we didn't mention Ansible. So I get with the API, it's easy to do, but it's still a lot more work. Are you actually planning to do like a community module for Ansible to make configuring a gateway kind of first class for Ansible specifically?

35:27
Carl Gould: That's a good question that I don't have a great answer to off the top of my head. I don't think it would be an Ansible module. We're playing with all kinds of things in this space. Helm charts is one of the most interesting. We're also looking at publishing a Kubernetes operator. Oh, I got a thumbs up on that one. I'm gonna take it and let that be the end of that answer before I get into trouble.

36:00
Audience Member 4: Yeah. I noticed in the beginning in the screens that at the bottom, it said "gateway restart required." Could you go into what triggers that and the effects of it? And the other question is you said the tag historian does the tag, sends the tag model, does that include like the engineering units, the last time the tag changed, the quality, all of that stuff at that time when it sends it?

36:37
Carl Gould: Okay. Two good questions. Do you wanna take the restart one?

36:40
Drew Miller: So the first is the, the module lifecycle itself has been refactored for 8.3. So what would trigger that restart event? Module installations would be a big one. There are a few, I think, settings throughout the gateway. Just a very small.

36:56
Carl Gould: Deployment modes would be one. You can't change deployment modes without restarting.

37:00
Drew Miller: Right. So those, those types of configuration changes would require a gateway restart.

37:05
Carl Gould: Yeah. That probably showed up in that screenshot because we're testing the notification bar API, while we're taking the screenshots. But the second question is about, okay, we have, again, here we're talking about the Historian API. In the next deep dive session, Matt and Reese are actually gonna be talking a little bit more about the historian implementation we're adding, the Power Historian. Because what's important to differentiate is, the Historian API creates the opportunities or capabilities for a bunch of interesting things to be true. As in, if you were writing a historian implementation, you would now theoretically be able to do a bunch of interesting things, but we aren't at the place right now where we have that plurality of interesting and compelling historian implementations that take full advantage of all the APIs as capabilities. And I realize that is, probably sounds a little weaselly. But, so the answer is an optimistic yes that is now possible, with an asterisk of the Power Historian today, I don't believe is storing the full UDT definition or tag definition. But that is the idea that we're trying to get toward.

38:38
Audience Member 5: New gateway interface. Are we able to export the tags without having to go into the Designer?

38:51
Carl Gould: I think so, but I'm not a hundred percent sure. But if not, it would be trivial to add. I will say that in the... On the topic of exporting, so there's... What's in 8.3.0, and then there's what might not make the .0 release and what might be added in the next few point releases. Right? And one of the things I'm really excited about, but probably won't make the .0 release, is so we have gateway imports and exports right now with the GWBK file, which has like everything about your gateway. Cool. I also wanna add a new import/export format, which would be really similar to how in the Designer you can import and export projects and just pick and choose the resources. And then, when you import them, they just like zipper into the project you already have open. Now, we can do the exact same thing in the gateway, which will be really nice.

39:42
Carl Gould: So, there's two things here. One is like exporting the tags as like a tag JSON file. If it's not in there right now, it could be added trivially. So, the answer should just be an unequivocal yes. But then, also there should be a platform-level import/export function so that you can more easily export a set of configuration. And that could include tags, but it could be say, you know, I need the tags and I need the devices. And then, those would all be able to be exported as one file and then imported into a gateway without causing a restart requirement.

40:25
Audience Member 6: Yep. So, another question on the Power Historian. So since the host is gonna actually be storing the historian data by default, I'm curious like what does that look like under the hood? You kind of danced around it that it was a more modern like time-series based. So, that's one, like what is it under the hood, is that gonna be externally accessible or accessible through the platform without having to stand up something like that, external?

40:58
Carl Gould: You're talking specifically about the Power Historian?

41:00
Audience Member 6: Yeah. Specifically with the Power Historian.

41:02
Carl Gould: Okay. So yeah, the platform is one piece, the Power Historian is contained within the Tag Historian Module. And the answer of what it is under the hood is it's a time-series database technology called QuestDB. And QuestDB is an open-source project. You can use existing tooling for QuestDB and open the file. We're not trying to keep it secret or anything. So, I think that's the answer to that question.

41:33
Audience Member 6: Yeah. Thanks.

41:34
Carl Gould: Cool.

41:35
DM: One more.

41:37
Carl Gould: Oh, that made a lot of people have more questions.

41:39
Audience Member 7: So quick question with now we're gonna be able to use external repositories pretty easy. So what is that gonna do for audit trail? And along those lines, when I do push something from external repository, am I gonna be able to see it in the audit trail that something was pushed and what those changes were?

41:57
Carl Gould: Okay. So, an audit trail for configuration changes is in some sense what Git is. Right? And I wanna make it clear that we haven't like embedded a Git client into the platform. There's some ideas, and so the the point being there that any integration with Git is sort of on you to do, as in you've gotta create the repo and send it up to, you know, whatever, if you can use GitHub or GitLab or whatever you want to use, those details are left to you. And we're doing that. I don't know how many of you have a lot of familiarity with Git? I use Git every single day. I don't really want the support department having to walk you through your own merges.

42:54
Carl Gould: Git's great, but you kind of need to know how it works. So, I guess the answer to the question is just Git just does that out of the box. It becomes that audit trail for configuration. Now, I do think that we need to add better hooks, so that when configuration changes are made through the web UI, you have a chance to do something like an auto commit into the repo. But that's still a little bit TBD about exactly how that works.

43:32
Audience Member 8: Can I ask about the Event Stream and Kafka Module? Are those gonna make their way down into the Edge version of Ignition product? And I think traditionally, like document-type tags have not been historizable. Is that going to change basically with the Power Historian or are we gonna be able to like buffer events offline to go into like the Event Stream?

43:58
Carl Gould: Okay. So Event Streams are not gonna be on Edge. And then, the question about document tags becoming historizable, I want to just say yes, but I would need to phone a friend to be a hundred percent confident about that answer. Do you have a confident answer to that one?

44:16
Drew Miller: I do not.

44:18
Carl Gould: That fun game of stump the chump, I almost made it. We only got 15 seconds left for that.

44:23
Drew Miller: You pulled me outta applications for a platform. That's great.

44:28
Carl Gould: Good questions.

44:33
Drew Miller: Probably time for the last one.

44:34
Audience Member 9: So with Historian API and also the Power Historian coming up, are there any plans for migrating all historian data that is currently in the SQL database into the new historian?

44:44
Carl Gould: Yes. Plans but not for dot zero. We won't have it ready. But that I think is gonna be a big piece of kind of how we move forward. On top of this new historian infrastructure is building better tools to migrate data in a number of different contexts. So, between those layers that I was talking about in the keynote, as well as between different historian storage implementations themselves, exactly when that's gonna get delivered, I couldn't say right now.

45:17
Audience Member 9: So, there will be going to the Power Historian but also the Historian API will be able to migrate to...

45:25
Audience Member 9: For instance, a cloud solution?

45:27
Carl Gould: What I'm saying is that in order to migrate data from one engine to another, we're gonna have to add some sort of data migration tooling that we don't currently have in there. So that's not really the... There's nothing about the API that would preclude us from doing that. We just haven't built that piece of it yet on top of the API.

45:45
Audience Member 9: So in the beginning, that would be custom made by ourselves for instance?

45:49
Carl Gould: That's right.

45:50
Audience Member 9: Alright. Thanks.

45:54
Carl Gould: Okay. It's gotta be the last one. I see I'm getting waved at by a light up there. That works 'cause it's blinding up there. So, last one, unfortunately. After that, you can just find me when I'm wandering out in the halls.

46:05
Audience Member 10: So you talked about alarm aggregation briefly there. Are you giving us totals and counts within like a particular folder? What does that look like? Can you talk about that a little bit? And then, how does like suppressing lower priority alarms work with the higher priorities?

46:24
Carl Gould: You wanna take that one?

46:25
Drew Miller: This is what happens when we pull the product manager outta the application and into the core. Wait, the data model should look the same as the existing alarm underneath that...

46:35
Carl Gould: Yeah. Yeah. It does counts by priorities and things like that. It's basically just a set of new bindable properties that is exposed at the folder and instance level. The question about filter, specific filtering, I'm afraid I don't know the answer to it off the top of my head, but it's an interesting question. Oh man, ending it on a low note. That's a bummer.

46:57
Carl Gould: Good thing I've got my furry friends here to keep me company. Okay. So, we're gonna have to end it there, unfortunately, but I'm around all week, so grab any of us and continue to ask hard questions. We love this part of it. It's super fun for us. Thank you so much, and stay tuned for the next one.

Project Summary: 

Creature Technology Company developed and implemented the C-Tech 2 system with support from ESM Automation Systems (AKA ESM Australia) and Inductive Automation. The system provides theatrical technicians and operators with simple visual tools to modify or create interaction and motion of complex animatronics figures without needing to access or be experts in PLC, motion, or SCADA programming.

The drag-and-drop interface offers a friendly and familiar way to pull dynamic functions from a palette to a workspace and draw links between them to create complex relationships. For this project, the data structures, functions, variables, relationships, and even screen layouts and tabbed views are linked to a PostgreSQL database.

Beckhoff industrial controllers, connected to the same database, interpret configurations in the database into logic and motion control settings. The logic and motion control settings are used in conjunction with motion profiles generated by studio animation tools to create fluid, lifelike movements, and interaction of animatronic creatures. 

Problem:

The timeline was very tight for this project, with an internal release required in 13 days and an MVP release in 31 days. This included using 26 views of the Vision-to-Perspective upgrade and the drag-and-drop view with detailed CSS styling. The drag-and-drop view needed to have six core functions:

• Tabbed Workspace
• File Operations
• Element Palette
• Blocks
• Connectors
• Parameter Edit Window

The drag-and-drop interface needed to be self-contained within Ignition; therefore no other external applications such as a React server could host the environment with Ignition just containing an inline frame. The scripting, which required use of an Ignition component such as a view canvas, would have taken too long and would potentially have functional limitations.

Solution:

After surveying potential solutions, Creature Technology Company determined that a custom Ignition module using a React library to create a custom Perspective component would yield the best results. With the help of Inductive Automation’s Travis Cox, a custom module was built using the React Library’s React Flow Chart. The module contains two components: the draggable node and the chart. Both components utilize Perspective's embedded views for visualization on the chart. This enables full integration and use of Ignition’s features, e.g., pop-ups, tag bindings, etc.

The element palette is a database-driven flex repeater that contains all available elements as draggable nodes which can be dragged onto the chart. There are three categories of nodes: inputs, functions, and outputs. Inputs and outputs are linked to static elements, while the functions contain dynamic elements such as adders or setpoint select nodes. Each node is uniquely identified and has dynamically created tags. Once a node is removed its tags are also removed. 

Nodes are displayed using a dynamic block template. Based on the database, a defined number of input and output ports, as well as custom local parameters, can either be exposed as an input or statically defined. Local parameters can be edited in a setting pop-up for each node. Ports can be linked using connectors to other nodes. Once a flow is completed from an input to an output element through any number of functions, a map is created to identify the order of execution for the Beckhoff controller. Lastly, for an improved user experience, tabbed workspaces and file operations were added to ensure operators can manage large animation programs more easily.

Results:

The C-Tech 2 control system builds on the flexibility and functionality of Creature Technology’s original C-Tech control system, resulting in a secure, modern, expandable, and commercially available hardware platform. By leveraging tried-and-tested industrial off-the-shelf components, the new system increases availability, boosts reliability, and improves product and component lifetime management.

The improved user experience has been lauded by end users, who express overwhelming appreciation for the new drag-and-drop view’s ease of use. Assessing the UI mockups next to the delivered system demonstrates that Perspective is the ideal environment to connect industrial hardware quickly into a web-based environment which can be accessed anywhere at any time.

The created module was designed for maximum flexibility — it can be adapted as a visual frontend or configuration tool within Perspective for a wide array of subsystems, such as Inductive Automation’s SFC Module  or external orchestration platforms.  

Creating custom components was never really on ESM’s radar prior to working on this project; however, this project demonstrates that the possibilities of Ignition as a platform are truly unlimited.

Deploy Date: March 2023

Project Scope:

Tags: 83,500 + dynamic elements from drag-and-drop

Screens: 26

Clients: 5

Alarms: 2,400 + dynamic in session creation

Devices used: Beckhoff industrial controllers

Architectures used: Standard

Databases used: PostgreSQL

Historical data logged: 55,110

At ICC 2019, we discussed the limitless possibilities of Ignition. Last year we envisioned the bright future of innovation in store for the Ignition community. Now, at ICC 2021, as the industrial world changes, the community continues to evolve to create smarter, faster, and stronger solutions than ever before. Join the leaders of Inductive Automation as they discuss the growth of the company and the community over the last year. In this year’s keynote, we’ll celebrate the community’s innovation by looking at the fantastic success they are achieving using the Ignition platform to evolve the industry for the better.

Du lager enkelt fullverdige, industrielle applikasjoner i HTML5 for overvåking og kontroll av prosesser på mobilenheten, PC-en og berøringspanelet. Enten de er for SCADA, HMI eller et annet formål, vil programmene du bygger i Perspektiv bli profesjonelle, og kunne brukes på enhver enhet og nettleser.

During this panel discussion, you'll hear the leaders of some of the Ignition community's most successful integration companies discuss new technologies and innovations that are evolving the industry. Ideas and terms like IIoT and the cloud once seemed foreign but are now increasingly commonplace within the industrial sphere. What new trends and innovations will prove to be more than just buzzwords, but actual mainstays key to a company’s future success? How are automation professionals responding to these technologies? Hear our expert integrator panel answer these and other questions as they discuss what actually adds value within the industry and what's just hype in this fascinating panel discussion.