4IR Solutions Exhibitor Demo: 4IR Solutions’ FactoryStackTM – OT, As-a-Service

4IR Solutions will demonstrate how their platforms can deliver OT, As-a-Service in the cloud or on premises making it easier, faster and cheaper to build and manage your Ignition infrastructure.

Transcript: 

00:01
James Burnand: And we'll get some late streamers in here, from what I understand, so all of them will be pointed out and embarrassed as they come and sit down late. I'd like to be the first to welcome you to ICC 2024. I didn't realize I was gonna get that honor when we signed up for this time slot, but it just worked out that way, so I hope you guys had safe travels in. Looking forward to walking you through a little bit about what 4IR does and sharing with you some of what we think is some pretty cool stuff. So to get started, why do we exist?

00:29
James Burnand: While OT systems can be a little bit of a challenge to manage, so when you don't manage your OT systems, the risks that you face are unexpected downtime, security issues and risks to your data fidelity. These are problems that are fairly common across our industry, things that we run into on a fairly regular basis, and something that unfortunately is somewhat ignored in some cases inside of the manufacturing and industrial marketplaces. So to understand maybe a little bit about how does that happen? I'd first like to do a little classification exercise and all your lights turned yellow, which is kinda cool.

01:05
James Burnand: So first of all, how many, show of hands... How many folks in here are end users? Okay, we got about maybe a half. And integrators? We got a lot of integrators. Cool. And everybody else? There we go. Perfect. So what I've done is taken the opportunity to classify what we see is the different types of end users. Hopefully this doesn't offend anyone, rings may be true, but what we do is we're gonna lay out who we think are the folks that are out there that we run into.

01:33
James Burnand: So the first kind of end user we run into are what we call Yodas. Yoda is an exceedingly rare species. There are very few of Yoda species in the universe, and they are masters in their trade. They are considered so totally in control and capable of everything that is necessary for them. Jedi Master. We find these folks to be exceedingly rare, but they do exist and users that have totally figured out how to manage and operate and handle all of the different pulls and pushes of OT as well as all of the rest of the responsibilities that they have.

02:06
James Burnand: The next type of end user we run into, and this is very, very common, is what we call super heroes. So these end users wear a cape, they often have many responsibilities of which managing OT and doing things like updates and patching and security is just one of many, many things that they have as their responsibilities. We find that these folks have a strong desire to be better at managing their OT environments, but often face the issue that it's an important but not urgent issue until it becomes an urgent issue. I'd say these are the most common folks that we run across.

02:41
James Burnand: And the final type of end user we have are what we call Bon Jovis. These folks live on a prayer, and they don't realize the risk that they run until they unfortunately have something that happens. We tend to meet these Bon Jovis after they've had a security incident or they've lost a computer, or they've lost an application for a long period of time and dealt with a significant downtime or cost issue, that's when we usually meet the Bon Jovis.

03:08
James Burnand: So what we have done is we have created a solution that hopefully appeals to all of the folks, although I will say that the Yodas are far less likely to be interested. We offer OT as a service. So we call that FactoryStack and PharmaStack. We'll talk a little bit about what the difference is in a second, but what that means is that we offer as a service, a delivered platform that provides you all of the best practices from Inductive Automation, security hardening guide from database management, as well as the best practices from the IT provider, so folks like AWS and Azure, and we put that and we manage that in a very straightforward way, so that you can focus on applications, you can focus on process, you can focus on the things that matter towards the end goal of improving manufacturing, and someone else is taking care of your OT systems for you.

04:03
James Burnand: So I did mention PharmaStack briefly. PharmaStack is essentially an extension of FactoryStack, and really what it does is it adds in some additional capabilities around data retention, around data integrity, and around 21 CFR Part 11 compliance, so that for companies that are in the pharmaceutical space, they can use PharmaStack to be able to make things like change control and operation of their and validation of their systems faster and easier. Fundamentally, they do the same thing. I'm going to talk about them interchangeably, so if I say FactoryStack and you're thinking PharmaStack, don't worry, they do fundamentally the same things under the hood with again, the additions to PharmaStack being specific for that industry.

04:47
James Burnand: So what are we actually trying to do? We're trying to make it simple to deploy OT infrastructure. We're trying to make it easier, faster, cheaper, and more secure for you to be able to have these architectures and these capabilities deployed both in the Cloud and on-premise for you to be able to take advantage of those. And that sounds very wide and that sounds very kind of vaporous, so if you think about it from a... What is our mission is we're trying to simplify and give you access to these transformative technologies without you necessarily needing to learn them, so you can focus on what's most important for you, which is solving problems for end users or solving problems as end users.

05:27
James Burnand: So how does that work in the ecosystem? Is really an interesting thing. So what we've done is we've laid out a little bit about what is the Ignition ecosystem, so you start off with Ignition itself, there is the Ignition standard, Ignition Edge, and Ignition Cloud addition platforms. They're all somewhat similar in that they share a lot of commonality between them, if you've used them, if you've noticed that, and that they provide a basis for a lot of other things to happen.

05:42
James Burnand: On top of that, there's the modules, so we're showing the partner modules here from Cirrus Link and Sepasoft, who are strategic and solution partners for Inductive Automation, similar to us as solutions partners. These extend the capability of Ignition, so you can do things like communication to MQTT and to the Cloud, and MES capabilities and Sepasoft got some, neat stuff this week.

06:19
James Burnand: That extends the capability beyond, but it still doesn't solve any problems for end users. That's where the integration community comes in. The applications are truly the thing that solves the problems for the end user. This is where you build out a back system or a EBR system or whatever may be the end application that ends up providing that value to the end customer. And if the stack was this simple, it would be very easy to do. It's never the simple. What ends up happening is at least you need a database, you probably need time series data, you probably need source control authentication, MQTT brokers, external applications. All of these complexities are things that are part of these systems that are deployed, whether they're directly a part of it or whether they're integrated into it, they're important pieces, and our goal is to deliver that as a service.

07:10
James Burnand: A different view on what that looks like is this next diagram, and I apologize about the glare moving around on there. What you'll see is we have a couple of things shown on here where... Down at the bottom, we're showing a couple of different deployment locations, so on the left, this is essentially if we offer this as a SaaS, so that's where we deploy it inside of our Tenant, and it becomes a service that you just use.

07:42
James Burnand: The next is inside of your Tenant, so this is for bigger enterprise customers, typically where they already have a big, strong relationship with an AWS or an Azure or some big Cloud company, and they have a basis where they would like to control their data inside of their environment, we are capable of deploying and operating those workloads inside of that space for them really as a platform as a service or PaaS.

07:58
James Burnand: And the final option is on premise. And we'll talk about a couple of options that we offer there, but the ability to have the advantages of operating something in Cloud while it happens to live on-prem, so you can still have that low latency localized capability, but somebody else is taking care of it for you. In the middle, this is really what 4IR does. So managing, supporting, monitoring, providing all of the capabilities for disaster recovery, updates, and ensuring that there's 24x7 support in place for all of these systems is a key component of us ensuring that this is an available and operational system for you at all times.

08:42
James Burnand: And this layer of glue in the middle is really what we are best at. When it comes to the applications, that's your choice. If you want one Ignition Gateway or 12 Ignition Gateways are 200 Ignition Gateways. If you want an Azure SQL database or you want a Postgres database, for us, we're able to flex and provide what makes sense for your use case. So we work a lot with system integrators and end users to help them decide what goes in that application space, but fundamentally, it's up to you as to what it is you need to solve your problems.

09:15
James Burnand: The way that works is we essentially sell by instances. So there's an Edge version of Ignition and an Edge version of FactoryStack and a Cloud version of FactoryStack. They come with the core services that you can see on the top of those boxes, and on the right, you can pick from our application catalog is to what you want available inside of those different locations. And then from then on, it's operated to manage as a service.

09:43
James Burnand: So I think it's important to talk about how are people actually using this. So the very first use case that we'll talk about is, Hey, I've got a couple of plants, or I've got a plant and my executives really wanna see a report or a visualization or some information from that, and it's hard for them to look at on their cell phone, or it's hard for them to be able to get access to that information. So in this scenario, which is a fairly common use case is you have existing Ignition gateways and you simply publish data from those gateways up to an instance in the Cloud of choice, again, whether it's our Cloud or your Cloud, and you build applications up there that take advantage of security principles like multi-factor authentication and DNS attack protection, and the use of a modern suite of security tools so that you can provide a secure way for those end users to be able to access that information that used to be trapped inside of the facility.

10:42
James Burnand: The next use case is around enterprise application, so this is often... And we have a talk on this tomorrow. This is really where there's a single application where I want to go and provide this capability to a fleet of facilities or a fleet of assets. And OEE is a great example of that where, hey, I really wanna have a consistent OEE deployment across my X number of facilities or my fleet of facilities that I have, that can be a really challenging thing to do when you have different IT folks in different buildings and when you have different infrastructure in different buildings, and what we find is for certain types of applications, it makes a lot of sense to use an edge-to-cloud architecture where your edge is provided as a data pump, it's buffering information, it's doing all of the connectivity to those local applications, and you're actually hosting the applications themselves using the Cloud.

11:32
James Burnand: That doesn't mean it all has to be hosted in one gateway. Some of our customers will actually dedicate a gateway per site, so there's a one-to-one relationship between a Cloud application as well as an Edge data pump. We see that as being a very common use case, because what it allows for you to do is to deploy very quickly without having to stand up a bunch of complex infrastructure in the buildings and to be able to take advantage of consistency in the application itself, so using things like the EAM module or DevOps capabilities with Git to be able to manage and operate those projects that are located up in that Cloud position.

12:15
James Burnand: The next piece is an OEM Edge, so where we see this most often is machine builders or folks that are delivering a piece of equipment to a lot of locations, so they would put on a small IoT Edge instance inside of that machine and use it for capturing statistics, creating reports, creating a user portal. So if you're using Ignition Cloud edition, one of the things you're capable of doing is having multiple tenants connect to that instance in the Cloud, so you can imagine if you're a machine builder and you deliver a 100 of this piece of equipment into these locations, the ability to then have some sort of dialed home statistics gathering allows for you to do things like, number one is monitor the equipment, but also find common failure modes and use things like AI to generate insights and inference on how those systems are performing and most importantly is you can actually create upgrade packages for those pieces of equipment based on what you've seen on improvements that you've done on other pieces of equipment. So this allows for you to use that kind of spread out architecture, that Ignition enables to be able to provide an additional service, which is often a paid-for service to your users or to your customers.

13:33
James Burnand: The last one, which is, I'll say newer in this space, is a hybrid. So, is anyone familiar with hybrid? That term make any sense to anyone? Alright, no hands are going up. So what Hybrid is, is it's a little bit of Cloud in your building. So rather than using an Edge device that is essentially there to operate maybe some Docker containers or maybe there to just provide some function, maybe a database or an Ignition gateway, Hybrid Cloud is literally taking a piece of cloud and deploying it inside of your building, so you don't operate it by logging into the server. It looks like a server. So Stack HCI is offered by a bunch of the common vendors, you would know, so Dell is a good example. It looks like a Dell 750 chassis server, but you can't log into it.

14:26
James Burnand: What it is, is it's a thin operating system that connects up to the Cloud, and then you operate and deploy all of the workloads that are on that server sitting in your building through the Azure portal. The nice part about that is you get access to certain services that are available inside of Azure. So the nice part is now I all of a sudden I have access to hyperscale databases and VDI and Kubernetes clusters that lets me put not just FactoryStack, but a variety of different services that live locally can tolerate the internet going out and still operating, but I get the benefit of being able to manage them as if they were deployed in the Cloud because they're being deployed using that same common methodology.

15:11
James Burnand: I see this being a really important step in the next several years for manufacturing, moving from a completely on-prem sort of a set-up to somewhere where there's an on-prem and in cloud hybrid. Yes, the word means that, I guess. Where we see this is traditional SCADA, alarming applications, commonly places, things like regulated environments that want something physically on-prem or they have to have data residency that doesn't leave a building or a geography. These are common use cases for this. And again, we see this as being a very interesting, but also a very useful set of tools that not a lot of folks in the manufacturing space are using as of yet today.

15:54
James Burnand: Interestingly enough, there are several different ones out there. We believe that in this case, Stack HCI is the one we're advertising, 'cause we think that's kind of the furthest ahead. Amazon has their Snow series. If you take a look at that, or their outpost series, there's Anthos from Google and then stack, Azure Stack as it's called for Microsoft. There are others as well. Those are kind of the leading folks in this space, and it is a growing space.

16:26
James Burnand: Oops, so where do people start? So I talked about a couple of use cases, I talked about different ways of thinking about or looking at different types of applications, but most often this is where people start. They set up an Ignition system, a database, a Git repository, everything with integrated Entra ID, multi-factor authentication, everything monitored and secured and they look for a place or an application to use for it. Most often, it's typically focused around statistics or information gathering or unified namespace, integration with AI systems. These are all different use cases that kind of use the same architecture.

17:09
James Burnand: The nice part about this is you can start with a single gateway and a single database, and you can grow this to whatever meets the needs of your use case and your customer, so there are limits, but they're very, very high, and I haven't seen anyone getting or close to them yet, where you can start with a single gateway and you can run hundreds inside of the same infrastructure without making any real fundamental changes to the way it's built.

17:40
James Burnand: So part of what I think is important to understand is what does 4IR do in all this is that we are operating, managing it, and making it simple for people to use, so your interface as an integrator or an end user is the Ignition Gateway in the Ignition Designer. You don't really need to know or understand all of the inner workings behind this. What you need to know is that someone that understands OT is taking care of it for you, and that we are ensuring a simple interface for you to be able to use that takes care of some of the complexities that you may run into.

18:15
James Burnand: A good example. So one of the complexities that a lot of folks run into when they're putting stuff in the Cloud is SSL certificates. So anyone had that problem where their system goes down because of an SSL certificate?

18:29
Audience Member 1: Microsoft Azure.

18:35
Audience Member 1: Special server crashing and yeah, not a problem at all.

18:39
James Burnand: So in our case, we have automated a lot of what you see on the screen, so we use a tool called Pulumi that allows for us to automate the deployment, management, and updating of all of the infrastructure. That also includes certificates. So we don't just deploy a certificate, set it to 2029, and hope no one forgets about it in a few years. We rotate our certificates every thirty days, and there are some changes coming from the browser providers that probably is gonna become necessity in the next few months, maybe a year. But that automation allows for one of those potential downtime reasons to just sort of go away. It becomes something that you no longer need to have as a part of your mind or part of your maintenance plans, because now it's taken care of as a part of the platform that's deployed.

19:28
James Burnand: Maybe leave certificates. So we do have a presentation tomorrow that I'll talk about in a second where we will... We'll go through a little bit more detail what that is, but we do talk quite a bit about security certificates and scale as a part of that. So it's important to know how do you price stuff, and there's a real interesting part of this discussion around how you look at what the pricing is for when you're doing a deployment. So very similarly to if you're gonna go buy a server, right?

20:02
James Burnand: So if you're setting up an Ignition system in a plant, you're probably going to Dell, maybe buying a VMware 321 stack or OpenStack or Nutanix, whatever the case may be. But you're buying something and you're buying it with the intention of having enough capacity in that thing for the next six, seven years, depending on what your lease or your refresh cycle is on your hardware. It's a little different in the Cloud. So when you're in the Cloud, what you're doing is you're trying to figure out, what do I need today, and making sure that when I've created this, I have a flexible architecture. So as I consume more, I have the ability to expand my capability. So what becomes important as a part of this is understanding that the Cloud and on-prem have different ways of handling reliability. So by default, our systems take advantage of multiple availability zones.

20:51
James Burnand: So we have things like mirrored storage across three completely separate physical buildings that provide not just if some hard drives fail, but if a literal building blows up, the system won't actually have any, or it'll have minimal downtime to move some of the workloads across automatically. So the level of availability and reliability that we offer out of the box is actually higher than what most people are capable of doing inside of the four walls of their building. And we can still go up from there. The challenge is cost. So, you know, a lot of folks are like, it needs to be this, it needs to be that without actually going through and understanding what level of downtime can I tolerate as my business? Can I tolerate... And my cohort, Randy says, can you tolerate somewhere between a 100 milliseconds and a 100 days?

21:39
James Burnand: And the reality is that, you know, depending on what your lead time is for different hardware components or what the criticality of your application is, how much data you can tolerate to lose, those are the decisions that help you choose what level of availability that you need to have as a part of your deployed application. That is a direct correlation to what it costs from those hosting services from the Cloud. So we try to guide people through what it is they need, based on what their application is, what their user use case is, and try to create something that makes sense for those users, taking advantage of the technologies that you have available by using different cloud services and capabilities.

22:19
James Burnand: The other things that drive cost is how complex is the application? So how many gateways? What type of databases do I need? Do I need a VPN or no VPN? How long do I need to retain backups for? These are all, again, considerations that have a direct correlation to what I get charged from an Azure or from an AWS.

22:43
James Burnand: Important to highlight. So we do have a few partnerships in the industry. A lot of logos I think that are here this week. We work very closely with these partners on trying to create cohesive offerings as well as working with Microsoft and Amazon to ensure that our solution is qualified and follows all the best practices that they publish. We do work with a lot of systems integrators as well. I'm not gonna put logos up here, but I think it's very much a collaborative engagement with integrators because we don't build applications. That is not part of our business model. We are here to provide enablement and infrastructure and make sure that it's easy for system integrators to deploy these kind of systems or end users to deploy these kind of systems. But we do not build applications.

23:29
James Burnand: We do offer consulting. So if you are trying to figure out how am I going to do this? How does IT and OT talk together? How do I meet these security requirements? Or you get one of those big long checklists that says, do you have this? Do you have that? What's your policy for this? That's what we do. So if you're trying to go through that and figure out a way to create an offering for a customer that meets those obligations, we probably have an answer for that because that's our business.

24:04
James Burnand: So we talked a little bit about the ICC session. Tomorrow, it's just after lunch in stage 2. I encourage you all to attend. So I will be back up here. I'll have my cohort Randy to talk a little bit about Enterprise Ignition specifically. So we're gonna cover details around what makes an Enterprise unique, as well as we're gonna do a live demonstration of FactoryStack. That demonstration is gonna have a number of Ignition gateways running. We're gonna add a whole bunch, we're gonna upgrade a bunch, and we're gonna downgrade a bunch and kill a bunch. So a really neat demonstration of the technology in action and we're looking forward to sharing that with you guys. That's all I have for the presentation. Any questions?

24:54
James Burnand: So there are some that are deploying hybrid because of that concern and they need to have it in the building. But there are others, and it's not typically like consumer packaged goods or pharmaceuticals. It's like oil and gas is a better example where they have distributed fleets of assets and they're actually doing monitoring and SCADA control of those distributed assets using a central platform, which for them, isn't really that different as to what it would look like if they had a bunch of leased lines going to a building that has a dedicated server. So for them, this is a cost savings and risk reduction piece. So now rather than having no one updating their servers and being a little bit of a Bon Jovi, now they have someone caring for and monitoring their systems 24/7 and providing updates and providing kind of that surety of availability. The biggest downtime reason is often the internet connection, not either side of it.

25:58
James Burnand: Yeah. Yeah. It's all pipeline in that particular case I'm talking about. But yeah, like there isn't, you know, for direct control of process and equipment, we don't recommend using the Cloud. And to be honest, there is not a great set of reasons to take that risk on unless you need to. I personally think that in my professional career, we're going to see a time where the reliability of networks between factories and public clouds are at the point where people will start to do that. We're already seeing... We have a couple of like real big enterprise customers that are forcing all of their onsite SQL servers to be moved to a managed service in Azure by default. So you have to provide basically a set of reasons why they're not going to be moved. So they don't actually care what the application is, they're just trying to get rid of that cost of having to operate and maintain those SQL servers.

26:57
James Burnand: And their reasoning behind it is that they've invested in redundant WAN connections and a level of latency and availability between their buildings and their public cloud instance that is as good as it could possibly be, so they feel comfortable with that risk level. I think we're gonna get there in the industrial space, but not for a while. That's why I think hybrid cloud is so important because hybrid cloud allows for you to bridge that timeline and you can run Stack HCI offline for weeks and it still is local, it's still running virtual machines and clusters in the building, allows for your SCADA system to operate as if it was there. What you lose is visibility and the ability to pump back ups up to the Cloud.

27:41
Audience Member 2: All the software, all that's managed in the Cloud. What about hardware upgrades to the on-prem?

27:47
James Burnand: So that's actually managed from the Cloud as well. So the way that works is there's a Stack HCI OS, and again, I'm just talking about that particular instance that's a like a really cut down version of Windows server and it's upgraded kind of like a firmware on a PLC. And those upgrades are become available in Azure and you push those upgrades down to the system. So it's... they're more like unit upgrades than like doing Patch Tuesday. So it's more akin to like a firmware based device than it is like an operating system.

28:19
Audience Member 2: So no real concerns about hardware obfuscating the software?

28:25
James Burnand: So not really. The nice part about it is just like if you're running a VMware setup, you're obfuscating the hardware from the workloads that are running on top of it. So, you know, for you to migrate that cluster, migrate those virtual machines to another piece of hardware, even if it's dissimilar is not an issue. The level of availability of those systems is variable depending on how much hardware you buy. So you can do as little as one Stack HCI server, which gives you like a RAID 5 array and two power supplies and single server level of reliability. You can do two of them running as a pair and you can do 10 of them running as a cluster.

29:06
James Burnand: Yeah. So the question was, how difficult is it to get estimated price and Azure was the question, but it's similar for AWS and how accurate is that? So the cloud companies actually do a really good job of laying out what their service costs are, and they also have some fairly built-in discounting models. So one of the things you can do is you can reserve for a certain amount of time, and then you get a percentage off of that service cost. So for example, if I have a database and I reserve it for a year, I get thirty percent off that price. And that's basically a fixed quantity based on what the calculators say. So we can go in and what we do to try to simplify it for the end users is we'll kind of create a set of boundaries and say, okay, for this subscription you get a terabyte of storage, you get this much ingress, this much egress and these services, and we'll handle some of the risk of that minutia.

30:03
James Burnand: When it's in a customer's tenant or when you're trying to estimate, you know, is this a hundred bucks a month or 10,000 a month, the calculators are really easy to use provided you know the services that you're going to consume, in an approximation. The data's not the most expensive part, it's the services that cost more. So like for example, if you're gonna put in the storage for storing backups, that's rounding error compared to what it costs to put in like a SQL server database service.

30:32
James Burnand: Yeah. So the question was how does Ignition licensing work? We can only buy, 4IR can only buy Cloud edition, because we purchase Cloud edition through the marketplace, just like anyone else would purchase Cloud edition. Any other Ignition purchases are perpetual licenses. We need the eight digit key so we can be able to reup them whenever we need to. Or if we kill a gateway and bring one back up, we have to be able to reactivate it. But those are purchased either by the system integrator or by the end user directly. So we don't... Part of this, so the licensing that we'll provide is for the managed services that we purchase or anything that we purchase through Azure for things like, if I need an MQTT broker, if I need a flow license or an Ignition license that's typically purchased by the integrator as a part of that project that's being deployed. And then we will... Our requirement is that support is maintained on it, so upgrade protection is available so we can upgrade things. But that's kind of the all we're really looking for.

31:39
James Burnand: Okay. I think... I'm starting to feel like we might be out of time. So I wanted to say thank you all for your time today and I hope you guys enjoy ICC. Have a great one.