Zack: everybody. Welcome to today's Abelara stream. Today we're going to be diving deep into our Prove It series where we're episode two. If missed episode one, ⁓ head over to the Ascent YouTube channel, subscribe and you can watch the first episode in this series. So real what is Prove It? Prove It is the for community conference need to be at. with that said, I'm going to bring on Dylan. Dylan, welcome to today's live stream.
Dylan DuFresne: Yeah, welcome. Glad to be here. Glad to have everyone in the chat. Looks like we've already got quite a few people watching live, so...
Zack: And there was over 200 people that registered and our channel just crossed over 250 subscribers. So thank you all. Make sure to subscribe to the channel if you're on YouTube It's an honor, honestly, Dylan.
Dylan DuFresne: Thank you. to have you here. Glad to have you at Abellara. Glad to be able to put on these webinars because you're here. Alright, yeah, then guess we'll kick off the webinar for today still related to Proovit. This is the second one in this series. Last time we talked a little bit about the intended architecture and today we're going to go into data modeling and different platforms and ways to do it. of the leading questions that we noticed last year at Proovit was everybody saying, hey, when would I use X over Y or why would I use your software over the other software? And ⁓ the context of data modeling, that's what we're going to do here today a little bit. ⁓ With all that said, ⁓ note is on bringing everybody up. We're not here to talk down at any other vendors. We're here to explain when to use what and why we believe it is the best for those scenarios. so to kick it off with that, the very first piece of all of this ⁓ why. data ops? What is data ops? What is data modeling? ⁓ And of that. And it into the very first piece of one of the biggest problems with most digital transformations is that you don't start with a start with a technology, start with a need for a UNS or the need for data modeling or things like that. You start with a problem and that usually leads to failure. ⁓ So with digital transformation you want to start with a problem. So ⁓ that you might a problem of a pump that keeps failing. Maybe each failure you like $50,000 not even in downtime just in repair costs. And you might have data that tells you that this motor keeps overheating and you have the data to tell you the temperature of that motor. you have something on the motor head or something monitoring temperature, but person who's doing the maintenance doesn't actually have that data. They don't know that it's overheating until it's already too late. So one the there is we have a pump keeps failing, but and we know that has that temperature set point. know somebody has a temperature of motor, that actual process variable, ⁓ but it's sitting in a PLC at data register F8-4 or something like that. And it doesn't have any units of measurement. Nobody knows what an F register is on the maintenance side. And we have a random data point in the middle of nowhere that means nothing to anyone. to actually solve the problem of that motor overheating, or at least to know about it ahead of time so we can solve it before it becomes a failure, ⁓ need to know that F8-4 ⁓ ⁓ motor temperature of that motor. ⁓ it's measured in Celsius or Fahrenheit, where it is to relative, and if it's ramping up. or down or where it's at in the real world and that data point of F8, F8-4 actually means that it's 80 degrees, 90 degrees Fahrenheit or Celsius or whatever that happens to be and when it starts to get over 100, 120, 130 degrees for too long of a time, hours on end, that's when the motor starts to fail. So even the simple things about temperature has been too high for too long can make a difference if you know what that data point means and have information in a way that you can understand. how do we get from that raw data point ⁓ F84 the ⁓ of ⁓ 5 temperature ⁓ is 80 Fahrenheit? That's a lot of extra context that didn't start with that data point. ⁓ In context not necessarily known by all the different systems. ⁓ And the of getting from that first point to that second point where we now have actionable information ⁓ at a
Zack: Right, right.
Dylan DuFresne: level, loose definition, that's data ops. How do we make add context and make information out of that data? With that, we've got different things. A lot of data ops takes the form of pipelines. But if we get even deeper into just data modeling first, before we get there, we have that data point. And this is where you start to get into JSON and things like that. But before we get there, maybe we should share the screen here and walk through a few things, introduce the players, and start from there.
Zack: When we said we were doing this webinar, we actually had several of the vendors reach out to us and set up meetings to kind of go deeper. Dylan's been working with Ignition and UDTs for a better part of a decade now. But this is one of the most common questions we get is, all right, I'm familiar with Ignition, let's say, and I'm using UDTs. how do I do that same concept but in another platform like High Byte or like a Litmus because oftentimes, especially at an enterprise scale, you're gonna have multiple platforms. You're gonna run into ⁓ where you have to take unlike assets and make them like, or unlike platforms and make them like.
Dylan DuFresne: And so. To lay the foundation for what we're going to talk about here today with the different vendors, we've got a handful of them, all that do data modeling in some way, or form to meet the needs of that platform, to allow that platform to solve the problems it was made for. And once we get deeper into each of these tools, we'll start to see exactly what problem they were made for. And once you understand why they were made, what they were made to solve, then you'll start to see how they fit together and why they were made to do that. We'll start on the plant floor systems down here. We've got Ignition started off as a SCADA system. Its real purpose in the very early days was to move data from PLCs to SQL databases. And then from there, it became a SCADA platform. From there, it became more of an IOT platform into the composable SCADA system that we know it as today. On the other side here, we've got Flow Software. Information Hub here, Analytics and Information. So they're really for the analytics layer. They're going to take a lot of that data at rest, model it in different ways, and do some real statistical analytics that a lot of the other systems just don't do because they're an analytics platform first and foremost. They will connect to your things, connect to your data, model that data. You'll see that theme here. And then once it's modeled, they can analyze it, calculate it, and send that out and bridge it to other platforms. ⁓ Next to that, you've got Litmus being the main platform for data, IOT and industrial data on the plant floor is where they really find themselves at home. So everything from device connectivity all the way through modeling it, they do some digital twin functionality. So when we talk about modeling Litmus, it's really built around that digital twin and doing things with that and passing it to other systems for visualization. ⁓ good IoT platform. has some time series storage capabilities and things like that. that's
Zack: So there's two for Litmus. Remember, there's two. on who they're selling to. So if they're selling to industry, they're an industrial data platform. But if they're selling to cloud, Litmus is like the Google Cloud Edge connector. If they're selling to cloud services, then the Litmus onboard, they call data platform.
Dylan DuFresne: Mm-hmm. Mm-hmm. ⁓ Edge data platform, industrial data platform, ⁓ a IOT platform, ⁓ around the plant floor data, but they do have some Edge offerings, ⁓ you said, white labeled in Google and things like that. ⁓
Zack: and some of the best drivers on the planet. a lot of the human, like if you look at who joined Litmus lately in the last year, go look at who joined Litmus in the last year. They've got some really heavy hitters. know, Adam Kennedy, Sam Elsner. These are like industry legends, or especially around the data and driver space, so.
Dylan DuFresne: Yep, and then off of that getting into like HighByte here. HighByte is at its core an integration platform. doing a lot of ETL and transferring of data from one place to another. ⁓ you're more on the IT side, they're really like an iPaaS platform, but for the plant floor ⁓ industrial connectors and connectivity options that a lot of your traditional IT iPaaS platforms don't have. ⁓ so as part of that ETL, you've got the transform piece, you've got ELT, you've got other patterns as well, but you've got that ⁓ matter what you're doing, a big part of that is forming, it's modeling the data in flight. ⁓ And they do a lot of that integration piece there. And then next to that on the top of the layer here, the most enterprise of the software's here, you have Fuse. They are cloud native and they're a lot like Ignition and where you can build platforms and build applications on top of them. But where Ignition came from connecting PLCs to SQL databases, Fuse came from connecting ERP systems to MES systems as a traditional IPaaS and then grew into a much larger composable system from there. Where Ignition is a composable SCADA system, Fuse is a composable MES. So in Fuse being cloud native, the data modeling for them is really around that data storage piece. ⁓ If you're familiar with MongoDB, you'll be defining your schemas in the same way you would there. It's all Mongo under the hood. But you're defining your data schema and your data models in Fuse for that purpose. So at a high level, those are the different
Zack: And the main distinction there is storage is built in. So when you, I don't believe any of the other platforms, you're storing it on a disk or you ⁓ have to in some way spin up some sort of server or spin up some sort of hardware or install a SQL, like for ignition, you got to install a SQL database. Fuse is all built in out of the box, cloud native.
Dylan DuFresne: players. Yes, storage is built in. Yeah, Fuse is all built in out of the box. It's all cloud native. Litmus does store its time series data in Influx database built into Litmus. And then Flow Software with their SQL backend does have some buffer. I believe it's like seven days or something, but there is a temporary storage piece inside of Flow as well. Hyibite doesn't do any storage because they're all about integration. So you're going to be moving something from one place to another and storing it externally. And Ignition has ⁓ relative storage for like real time stuff in the OPC tag. but for any like actual storage it needs an external database. ⁓ And so when we start getting into more of the abstract again, we'll start a little bit simple here, pull back a little bit. You have the very traditional, very common at this point path through digital transformation. I believe it was popularized by Walker Reynolds, if not created by him. But we have the traditional connect, collect, store, analyze, visualize, find patterns, report, solve. And this helps us identify the problems and connect and collect the store data. So the general workflow before we even get there, we have to start even deeper is I have a problem. Something that we need done, something that's not being done in the way we need it to be, but we have a problem that we need to solve. So then we have to identify the gap. Why don't we have that solution now? What do we need to solve it? If only I had that temperature of that motor, I can know it's overheating before it actually overheats and causes a problem, right? And so then we need to figure out what are the tools that we need to make that happen. Is that ignition? Is that litmus? need to do device connectivity, we need to connect to the PLC before we can even get anywhere. So maybe we're either going to select litmus or ignition in this case to connect to that PLC that that sensor is wired to. And then from there, we can use those platforms to prove that first value. And then we can expand that use case from there. And once we get into the prove value piece here, this is where we start our loop for the first time on connect, collect, store, analyze, visualize. So the first step would be using some edge connectivity piece like Litmus or Ignition or to get it into an initial piece from the PLC. Notably in the ones we talked about Ignition and Litmus are the only two that do any level of device connectivity. Fuse does as well but it's really geared towards the cloud piece so we'll stick with Litmus and Ignition for now. And using one of those platforms we're going connect to the PLC. We're going to collect that data point and this is where we're going to start to model it. We can either collect it and store it or we can collect it, model it, and store it. But at some point, we're to have to model it either between collect and store or between store and analyze. And if we're in a tool like ignition, that might just mean that when we take our data point from the PLC, we wrap it into a UDT, add the context, maybe with memory tags or SQL tags or stuff from other systems, package it together as a nice UDT, do some string compares and things like that to concatenate everything into that tag that we can then know this is the temperature of this, that, and that. If you're doing the UNS type implementation or you've got a broker or something, can publish it up to the UNS or you can just look at it right in those ignition tags. The ignition tag server itself can often act as UNS as well. But if we're just going to store it raw and then analyze it later, you might have a tool like Highbytes or Flow Software that's going to connect to that data store and analyze, model it and analyze it in flight there. ⁓ But once we've stored that data, we've analyzed it, we can visualize So we got to show it to the person who has the problem in a way that matters to them and they can start to find that pattern In the very simple example here, they can see a trend chart. Hey motors getting hot You should probably look at in the next couple hours and if they can act on that in time They can save that money prove the ROI and that's how we've proven our value from up here But once we found those patterns we can report on it and solve it That's where either the human in the loop comes in and says hey, I notice this pattern I'm gonna go solve it and I'm gonna shut off that motor let it cool down or I'm gonna run it a little bit slower or something in whatever acceptable way to mitigate the issue without affecting production. Or you could have some automatic systems that identify and do some machine learning to find those patterns, report on them, and solve them automatically closed loop as well. But generally speaking, that's the loop of identifying the problem and coming through to a solution. And with that, we got into the different ones here. Yeah. ⁓ So. With these different options all in their different homes, you've got your Composable SCADA in Ignition, your Analytics Platform in Flow, your Edge Data Platform in Litmus, your Industrial Integration Suite in Highbyte, and your Enterprise Composable MES and other things. You can do a lot of ERP functions too in FUSE. But then the problem is if I'm doing my data models in each one of these platforms, how do I know which data model is the right model? How do I keep them all consistent? and what do we do? And so just because all of these platforms can do data modeling doesn't mean you want to do data modeling them all of them all the time. So let's say we have a UNS stack where we have Litmus doing our device connectivity. Maybe ignition is... So let's say we've got Litmus. doing our device connectivity and visualizing an ignition. and visualizing an ignition ⁓ with its influx database and things like that. Litmus might be connecting to the device. It might be modeling it and storing it, just dumping it in as an UDT and ignition already, if we have the definition. ⁓ Ignition might be taking that data point. I can figure out these arrows and storing it in a SQL database or something of that nature. And from there, And then from there, we might have something like flow software connecting to other SQL databases, other historians and things like that to do more statistical queries and analysis. We might also have, depending on where you've got ignition could connect to high byte. If ignition is doing the PLC connectivity, you might have ignition and high bytes where ignition has the UDT modeled. takes the high byte and then it might publish it out to your unified namespace from there. where other systems can access it as the event driven piece there. there you might have your UNS publishing up to Fuse for enterprise applications. You might have your SQL database coming in and adding more master definitions and things like that in Highbytes. But so the question here comes down to the different use cases. So if you just need to connect to a PLC, a single PLC and show data and value really quickly, you might be able to get away with just ignition and nothing else. You might have a Modbus register, an Ethernet IP, or some other common industrial protocol. Ignition really good at talking to PLCs. And if that's all you're doing, you might be able to connect to the PLC with ignition, model it as a UDT with ignition and show it on a screen in perspective and call it a day with just that tool. But say you've got more context in your ERP or in some other proprietary database that's locked through an API, maybe a test and measurements database that has all of your historical time series and you want to know what the test was, what the measurement was, then you might have used ignition. To and high byte high byte getting that data from another integration platform or sending it to somewhere else and going from there so ⁓ zach making sense so far or what do we guess
Zack: Yeah, question, question. ⁓ So just that last example you gave right there, where you're using HighByte to, let's say, connect to other databases that have some sort of transactions or logs. In theory, you could do that same connection in both HighByte and or Flow. is really good at connecting to many different databases, either historical or transactional, and then bringing those together. ⁓ that scenario, how do you choose between those two?
Dylan DuFresne: Yes. Yes. Yes, so generally speaking my rule of thumb with arrows here and then we'll answer that my general rule of thumb ⁓ ⁓ and Flow is that HighByte is for data in motion ⁓ Flow is best for data at rest. ⁓ if you're going to be connecting to a bunch of databases, OSI Pi instances, various historians and things like that, various data silos and databases out in the field, definitely going to want to choose Flow ⁓ grab that data, contextualize it. It does some fancy magic with timestamps and things like that that your data scientists really happy. and then flow is morphed and then it can use calculation and analytics on that historical data as it models it and then pushes it out to something else. That's something else might even be HighByte as an event could be a calculated KPI and we started to HighByte for further integration platform pieces. But HighByte is really good for if I have an MQTT broker and a couple rest APIs or a webhook or a web socket or something where we need something now and it's all live event stream data around the UNS, HighByte's really good at listening for those events and in flight grabbing and adding that context and then pushing it out the other side as an integration platform. Litmus is definitely, you build your own API or a lot of systems that already have APIs, ⁓ all sorts of stuff like that. ⁓
Zack: Maybe like to build your own API almost, kind of too.
Dylan DuFresne: Yeah, so you might have one of them I came across lately was we have a bunch of spectrum data in fancy complex data types coming from a bunch of test and measurement databases instrumentation and it stores all of that in a proprietary file format that then other software that's built for it can go and understand and ingest it as a time series database, but it only exposes it as an API. And that data is relevant to the work order we're running. And that work order needs the context of what was this test before it can move on for quality control. before you can move on to the next step. Highbyte can interact with ignition for the PLC and live process data, while also connecting to the APIs from say your ERP for master definitions, or your test and measurements databases for your glorified time series databases for your more complex data after they've already been measured and normalized and simplified into scalar data. Highbyte is also really good for grabbing things like other file types, ⁓ much more complicated data. and moving it from place to place even if it doesn't necessarily understand what's in that file. ⁓ So, HighByte is really good for data in motion. If data is, if I'm modeling data and moving data, I want to use HighByte. If I'm modeling data and analyzing that data, I want to use Flow. And typically the data I want to analyze is going to require ⁓ all historical data that's in a database, whether it's a tabular database or a historian or something like that, ⁓ will connect to all.
Zack: Come.
Dylan DuFresne: of that and model it and do the analytics on it that you can only do when you have that history. Where HighByte can connect to databases, it can connect to all the real-time things, but it's really built to transform it in flight and then send it somewhere else.
Zack: So let me ask you this. ⁓ First, do we have on the rest of the agenda for the audience today? What can the audience expect us to go over next?
Dylan DuFresne: Yes, the next stuff, so a lot of the stuff here is we want to talk a little bit about an initiative that's trying to get some interoperability to allow some of these platforms to work together so we can share the data models between them and not have to remake them in every platform every time. We've got the... general Q &A at the end for sure and if we want to dive in a little bit to some ignition UDTs we can definitely do that live assuming it all works.
Zack: OK. And then if the audience has any specific questions or examples or use cases where you're wanting to decide, please leave them in the chat. we're happy to go over them. So then. How are things going with the overall Proovit preparation for the Proovit conference, like with the application and Dupinix and any update you want to give us on that?
Dylan DuFresne: Yep. So... Generally speaking not too much has changed from our last webinar. We'll jump into that here first So we've still got the same old stack we talked about last time So we won't go into too much detail because we've already got a couple hour video describing it But the same kind of concept so we're kind of building this out. We're working with our partner to PNICS to help do the development on it Working on our edge data coming through so the primary site so going back to prove it generally speaking the
Zack: you
Dylan DuFresne: on that we're going to choose to work with is what they're calling Enterprise B. It is a bodily manufacturer with three separate sites and we're going to handle each of those three sites slightly differently but allowing them to merge their data in a consistent format into an enterprise data set infused that allows it all to be usable by the enterprise teams. So on site one we're going to go big. This is a big ambitious site with a very very well-versed very digitally mature team that wants to solve all their own problems on site. It's probably built out some of the stuff before the corporate mandate of what tools to use and how to do it has come out And so on this site will be using ignition. We'll have multiple gateways looks like five different gateways ⁓ One for an edge gateway not necessarily ignition edge licensing but edge gateway as a function for device connectivity and edge functions We got a central tag server that really will act as our UNS even though it is OPC the central application and the single source of truth for all our real time event data on the plant floor is going to be the ignition tag server. And then we've got three different ignition instances here, a typical scale out architecture for the ⁓ MES system with the front end and the back end gateway, and then a single SCADA gateway running vision for plant floor SCADA level applications and possibly control. ⁓ We'll be using the time-based historian and flow software. So time-based historian for all of our scalar history. Flow software is an engine that also can connect to all the context and history in our Postgres database which is going to be doing all of our MES functions and then HighByte is the integration layer to get everything through the UNS and get everything consistent and normalized for the enterprise data applications. So we'll be publishing everything from the site up to the UNS in its raw edge form but also sending that data up through FUSE where we can do the functionality and I believe we're going to be building a warehouse manager management system in Fuse among other things and then using it as the iPaaS platform as well between the UNS and likely Google Cloud and then maintain X as well. But we'll get into the other sites a little bit too where they're going to one site might use just Litmus Edge as the device connectivity and we may or may not want high byte depending on if we need consistency maybe want to use high byte for all the models. So maybe we do some edge modeling close to the edge just like the hour with ignition on the other site in Litmus. but all of our enterprise models are going to be handled by Highbyte and managed and maintained at the corporate level. And we've also got a Fuse Edge Gateway on each site. Yes. Yep. So like here, we've got a Glipmous Edge Gateway. They may or may not want ignition out there for some visualization, but for this site, we just want to get data to the enterprise. This site was told that they need to get data to the UNS, but they didn't really find the need for it themselves yet, so they're just following orders.
Zack: Can you zoom in a little bit on those? Can you zoom in a little bit on those edges? Yeah, thank you.
Dylan DuFresne: And we're just going to run headless data collection with Litmus Edge, HighByte, and the Fuse Edge Gateway. HighByte being our quote unquote corporate standard, we're managing and maintaining all of our models. ⁓ Fuse Edge Gateway being that ⁓ that gets us to the Fuse SaaS ⁓ in the cloud. ⁓ we're getting a little bit away from data modeling on that, but they're using AMQP and some store and forward stuff. That's why we're not going through the UNS as the MQTT broker. ⁓
Zack: Nah, listen. Well, real quick, Dylan, we have some questions coming in on LinkedIn. Do you want me to kind of feed those to you as they're coming in, or do you want to hold them to the end?
Dylan DuFresne: Yeah. Yeah, what do we got? Yeah, I'm happy to answer them all as they come in. mean we go
Zack: All right, we have Glenn Gardner. He's in the chat monitoring the LinkedIn question. So Anas asked if Dylan can say a few words about security in Fuse. And he works in aerospace, and it's a prime concern generally. This is a great question. Real quick, want to mention on Fuse, I was so stoked yesterday because we had a $4 billion manufacturer reach out to Fuse. and say we came to you because Abelara recommended us. yeah, shout out to Fuse. right, but yeah, so tell us about security and Fuse.
Dylan DuFresne: Yeah. Yep, so security and fuse, that's part of why we're using the fuse edge gateway. rather than going through the MQTT broker and everything is the Fuse Edge Gateway is a single outbound connection from the Edge Gateway to its own service. So there's no third party apps. There's just one tunnel from Fuse to Fuse's managed cloud services. So for that, the security, for better or worse, there's only one application talking to itself in the cloud. So you've got one port to open from Fuse, outbound only to Fuse. ⁓ It's a closed connection. Nobody else has access it's just that one outbound port. ⁓ So if we were really concerned about security, then we might just use FUSE in the real world, we might just use FUSE alone to go say, Edge connectivity, Edge components through Litmus Edge, we're gonna do all of our Edge data ⁓ applications there, and then let's use FUSE as the single point outside of the system. One of the things being the SaaS platform and the cloud hosted tenants here, Fuse is handling all of that for you. They're doing all the role-based authentication. They're doing all the security. And one of the benefits of a more monolithic, I know they're a very micro service oriented platform, but from a user perspective, we're using one app, one vendor across the board means that we don't have doors open to other vendors as that pipeline moves. And then the Fuse handles all the security and scalability things inside of Fuse managed by your IT team in the Fuse application itself.
Zack: you Yeah, when we get into a boardroom, when we get into a discussion with someone from IT, like CIO or CTO, they love Fuse. Let's just put it that way. ⁓ Those are conversations we like to be in. But I like that you have, ⁓ yeah, Fuse, like what I was saying was, I lost my train of thought. ⁓ We had another question come in, let me ask this one. ⁓ So Ray asks, how much litmus is?
Dylan DuFresne: yourself. Mm-hmm.
Zack: How is this landing data inside of ignition? Are you using an OPC or another integrated method?
Dylan DuFresne: Uh-huh, yes. So, Litmus, landing inside of ignition, you've got different options, one of them being OPC, you could do MQTT if you've got the Serious Link modules, you could do other things like HiBytes. The simplest method is to use their ignition module, and it can land things as UDTs or things just natively in ignition as the module. It's gonna be the simplest option.
Zack: That's good.
Dylan DuFresne: So for this one here, from an ignition integration standpoint, both litmus. and Highbytes have ignition modules that treat it very natively and very first class support for ignition. The other one is not so much from a data modeling perspective, but over here, one of the reasons to use time-based historian is that it also has an ignition module that treats it just like a historian on anything else. So that's why we'd use this over another just raw time series database is it allows us to keep all of the functionality that ignition thinks of as a historian, all of your queries, all your scripts, all the pre-made functionality. inside of ignition is all still supported by using timebase and the ignition module where you have to recreate it if you use something else.
Zack: And I think it was just yesterday or today, the time-based ⁓ Ignition module is available on the third-party marketplace. ⁓ we're seeing an explosion of native modules, like, maintainX has a native module. I think Waits was talking about making an integration with Ignition. But so we're seeing all these different, like, Hi-Bite and Litmus. I actually wasn't aware that Litmus had a native module for Ignition.
Dylan DuFresne: Mm-hmm. Mm-hmm. Yeah, it's a powerful, powerful option there for sure.
Zack: And litmus and inductive are like the two titles. It's like litmus inductive. But yeah. All right, let me ask you this. ⁓ what I was going to say is I'm going to share a story about when I was using Fuse when you talk about security. Like I said, IT loves Fuse.
Dylan DuFresne: Mm-hmm. Yep.
Zack: It has all the certs. But from a personal experience, one of the things I liked was it was super easy for me to add two-factor authentication. So I can use a changing passkey, like a Google authenticator, to log into that cloud app. And that was just so easy to turn on. It was native out of the box. so from a security standpoint, they take care a lot of that for you. And if that didn't answer your question, Ray, or? ⁓
Dylan DuFresne: they do. ⁓
Zack: honest, just let us know. Yeah. Thank you.
Dylan DuFresne: And I do want to add one thing that all these ignition modules opens a lot of doors for integration options. Sometimes they're the best options, sometimes they're not. ⁓ There's always the trade-offs just like anything else in the build versus buy. So if you use a more open integration method like OPC or MQTT or some other REST API or some other way of integrating with ignition, other services can use that more natively too. But if it's a very tightly coupled ignition architecture, the ignition modules make it incredibly easy. to integrate fast. So there's the trade-off of simplicity versus long-term openness as well. So if you rely too heavily on ignition modules, you're really coupled to ignition. Whereas if you're using some of the more open standards, more APIs and OPC type stuff, then you can definitely have more interoperability to other things without having to also make those pipelines as well. So there's always the questions on do you use the API, do you use the MQTT integration,
Zack: you
Dylan DuFresne: use the OPC direct or to use an ignition module or some other platform that has modules like that. There's always trade-offs and one plant might want the modules and the other one might have a good reason not to use them but it opens a lot of doors and keeps things very capable so that's always a good thing.
Zack: ⁓ nike on six seven seven isn't ignition and high by a a match made in heaven i think it's a match made i also think ignition and let me say that that's great
Dylan DuFresne: So the thing with these are on every site we might not want all five of them, but they all play with each other really well in different ways in different situations. I mean, if you. ⁓ There's a lot to be said about litmus plus ignition plus fuse. This stack could get you best in class device connectivity, plant floor visibility and application building, as well as IT friendly application and feature building as well. If you throw. ⁓ Ignition, Hi-Byte, and Litmus together. You could do a lot of really cool things with Litmus, Ignition, and Hi-Byte, where Hi-Byte can be a much more manageable layer to a lot of API integrations, say even like ERP and stuff, where Ignition can technically do API calls, Hi-Byte can do them in a much more managed workflow-oriented way as an integration platform, and then Litmus opens the door to a lot more device connectivity options that Ignition has out the box. The other one is I could throw Ignition and Flow software at just about any problem where we have a bunch of existing data silos. And these are going to open up all the doors. So if you're a site that has 12, five, 10 different historians, a bunch of SQL databases, a bunch of data silos throughout your organization, just the Ignition plus Flow software, Flow software can connect to all of those historical data sources, do the analytics and pass that data to Ignition for visualization. So connect, collect, store might not be PLCs and devices. It might also be ERPs, API. warehouse management systems, supply chain, PLM, things like that with Highbyte or it could be historians and data sources with Flow software or it could be devices in the field with Litmus. Fuse and Highbyte have a lot of overlap as integration suites. So if you need a bunch, if you don't need all of your platform building enterprise applications in the cloud, you just need connectivity, Highbyte can do it. But if you also need all those connectivity options, Fuse can build the screens and the dashboard. the data backbone ⁓ storage and things like that, just like a Github can on the plant floor, but in the cloud for the enterprise. ⁓ Litmus and HighByte are both capable doing workflows and connecting to data points and publishing them out. ⁓ Where is really good at getting things from the OPCs and the APIs and things like that, ⁓ Litmus much better at getting them from the actual devices on the plant floor. ⁓ So might want both, you might only need one or the other, but you can combine these five logos in a hundred different ways. with or without all five, with two, with three, and there's hundred different matches made in heaven just with these five platforms.
Zack: And that's why we're very happy to be partnered with, I think, almost all of them. So my question is, ⁓ and we work with platforms that we're not partnered with all the time. We're agnostic. We like to pride ourselves on serving the client's needs and solving problems. So ⁓ where would you not use these platforms? Kind of give us a rapid fire. You would not use this platform for this type of use case.
Dylan DuFresne: Mm-hmm. So let's give you a quick example of, and this is again, this all comes down to what problem do we have and what problem are we trying to solve, right? So if I have a site that already has, let's say it's already running Rockboast Suite, it already has plant packs, it already has a factory-talked historian, everything's running perfectly fine on the controls layer, it's a relative process industry running plant packs, and everything's working just fine, but we can't access the data very well. to able to access that data and use the historian data and that live data in a way that makes a lot more sense, we could just throw flow on top, use the dashboards and flow and call it good enough for now because we can connect to the Faction Talk historian, we can connect to the OPC servers, we can do all we need to connect and model and analyze the data on top of existing brownfield situations. If we want to visualize it in various ways, then on the plant floor, that's when I would add ignition back in and now we can have ignition and flow sitting on top. of the existing infrastructure with plant packs in a way that's non-disruptive. But we might not need all the rest of these yet. But if I want to get that hooked up to the ERP in one way or another, I'm going to bring in either Hivite or Fuse, depending on what other problems we have that we need to solve as well. ⁓ If our problem is just device connectivity and we need data now and we need to know what it's doing and we just need to connect, collect, store as fast as possible, litmus is by far going to be your best answer. The other one, is if we're a mostly PLC based organization, we're only a one or two site small to medium company, Ignition will probably do everything you need out the box without any of the rest of them. But if I need device connectivity, even simple PLCs across a hundred sites, Litmus is definitely the one that's made for scale above all of the rest. So if we're talking a massive 100, 200, 300 site rollout, I might have just Ignition and Fuse, or sorry, just Fuse and Litmus because Litmus has the ability to maintain and deploy models
Zack: Yeah.
Dylan DuFresne: at an enterprise level where from a central location I can define a model and push it to my 100 litmus instances. And Fuse being the cloud native multi-tenant platform, I can build all of those in the cloud and functionality. So we might just have litmus on the field, going to Fuse in the cloud and calling it a day. If we need to add visibility on the plant floor, then we probably have Fuse, sorry, litmus and ignition on the plant at the site level and Fuse in the cloud level. And we might not need the rest of these. But again, where we would use one or the other really depends on what the needs are and what the brownfield currently looks like.
Zack: Damn. Do you dream about this stuff Dylan?
Dylan DuFresne: Maybe. ⁓
Zack: So for me, there's almost no scenario where I wouldn't use ignition. Fuse, you're in an environment where there's no cloud access, then obviously that cuts Fuse out. But then again, you can also run Fuse in your own environment as well too. And a lot of people in pharmaceutical, they will choose to run their own private instance of Fuse. if you don't have any historical data, your use case is probably going to be limited for flow, which is why they created the time-based historians. So if you don't have any historical data, start at time-based and then work your way into flow. Hi-Byte, there's almost no scenario where Hi-Byte wouldn't add value, like almost in any organization, even outside of manufacturing. Yeah. And then Litmus, if you don't have, if the drivers you need are all within ignition, then you don't need a bunch of different drivers, maybe Litmus isn't the best option.
Dylan DuFresne: You have four. Hmm. For a small to medium sized business, I'd probably start with these unless you've got some data types that ignition doesn't support, then you might need to throw something like Litmus in there. ⁓ For an enterprise customer, I would definitely start with something like this and maybe throw Flow in there as well for a large scale enterprise customer. But this is also assuming that we need plant floor visibility. There's a lot of times too where we might already have an existing OPC server and we just need to get data to the cloud and connect 100 sites really fast. HighByte on its own could do that as well. So then we might just have HighByte and Fuse we don't need all the data and visibility on the plant floor. We just need to get it to the cloud where we can do stuff with it as an enterprise. ⁓ then you could just have Fuse and HighByte or just Fuse and Litmas as well. ⁓
Zack: you Where do you choose no tool? Like where do you choose like if you're just starting, like if you're under five million a year or I would assume when you said small to medium you're talking like under 25 or under 50 million a year or?
Dylan DuFresne: Yeah, if you're to the point of digitizing. It's all going to be about ROI. Like all these tools cost money. if the problem you're solving doesn't generate enough revenue or save enough, if it doesn't reduce costs or increase profits enough, then to offset what it costs in the first place by enough of a margin that it's not worth doing. For your really small companies, and this people might not like me saying this too much, but for the really small companies, a good process is way more important than the tools you're using. So there are times where if you're small enough or even if you're relatively big, You can do a lot with just a clipboard and an Excel sheet. That's not a popular opinion, but if you don't have the processes in place yet, you're not ready for any of these. So you definitely need to have the process and the people on board before you can start integrating technology. It's people, process, and technology in that order for a reason. So if you're small and you're just testing things out, starting with Excel or Jira or some other tools that you can just spin up real quick and make work good enough for you today, getting started is always more important. than whatever technology you're choosing. So I would definitely recommend just an Excel sheet if you're small enough where that's all you need until you at least figure out what the process is and then figure out what the ROI would be of a bigger tool.
Zack: This is why our most successful clients choose to hire us to do a workshop to work with you. Like Dylan, know, is being hired to do digital transformation workshops where he'll dive into your processes, your people, and help you select this technology and architecture. ⁓ So that's one way to get started in focusing around the problem. We had a question that came in, speaking of all these tools costing money, can you give us an idea of what the price of all these solutions is?
Dylan DuFresne: It's going to depend on what you're doing with it. ⁓ I have to look offhand, actually let's do this then. Let's go Let's start with highbytes. Let's find it live. All most of these have public available pricing so for highbyte Let me see There we go
Zack: Zoom in, can you zoom in a little bit? There you go, yeah, perfect.
Dylan DuFresne: So for high byte, you can start with your evaluation license. I would just recommend at that point, it's still really cheap. I don't want to talk to support right now. I just want to look at the price. 17,500 a year, and that'll integrate all your platforms. You can have various users and it could get more expensive based on what else you need, but that's a good starting point. Flow software is pricing. You can start in here. They've got various options as well. So you can start at just under 10,000 for performance. perpetual license. ⁓ 14,000 ish for the unlimited. So I'd probably start with a 14,000 for Flow Software Unlimited, ⁓ 17,000 for Hi-Bite, Litmus Edge. Let's see if they still have pricing up here. This is gonna be a good test for all the vendors. So there's different options here. We'd have to talk to them about what the growth would be for real, but it's gonna depend on what your scale is. ⁓ Fuse doesn't have public pricing, it's going to be the most expensive of the options. Again, it's an enterprise scale, so we don't want to scare you away. The teams that are selecting these are usually much more... They're the same teams that are specing ERPs and the value of the use cases across 100 site versus the value on one site is a very different story. ⁓ High byte, we already went over. And then ignition is going to depend on what you're doing. But if we go to our various pricing options on ignition, there is ways
Zack: .
Dylan DuFresne: to started with ignition for as little as 10-15,000 all the way up to 25-50,000 depending on what the architecture looks like. But if you want to just get started really quick, a good gateway that'll do most of your features is going to be typically in my experience around 15-20,000 these days. And if you want to do a multi-gateway architecture that will scale a lot better for you, that's going to be between 25 and 50, depending on where you're looking at what modules you need. personal experience. If you want to get started with ignition, definitely go to their website and price out the module that way.
Zack: Sweet, yeah, and it's important to note, like, all of these are monthly or annually recurring subscriptions with the exception of Ignition, which is licensed standalone, and then there's like 18 to 25 % support annually. But all the other ones, I believe, are just an annual subscription.
Dylan DuFresne: And all of these have various forms of free trials as well. ⁓ Believe Flow has some form of a two hour trial. I've got to remember exactly what they have. If anyone from there is watching, if they could drop it in the chat, that would be really helpful. ⁓ Ignition has a two hour resettable trial, so you just have to reset it every two hours. Highbite and Litmus are the same, so you can download those and get started immediately ⁓ and just reset the trial every two hours to see if it'll solve your problems before you pay for it. And then Fuse is currently working to add that same two hour trial in. It's not quite there yet, they will be there soon. So all of these you can download and get started with pretty quickly and pretty easily especially once Fuse adds that two-hour trial. And in my personal experience every single one of these if you reach out to them we'll be more than happy to give you a demo and if you reach out to us we can orchestrate, coordinate, or do the demo with yourselves with multiple options.
Zack: Excellent. And if you reach out to any of these vendors and tell them Abellara sent you, it only helps.
Dylan DuFresne: Yeah, and guess in the last couple of minutes here, I did want to give a shout out a little bit. The one agenda item that I don't want to miss, we can always do the rest on other vendors, but in the name of data modeling, in all five of these platforms, you have various levels of data models. But the problem is I can't just take a data model, export it from ignition and import it into Litmus or Highbyte or from Flow to Fused to Highbyte or things like that. I have to redefine that data model in each of these platform. And in chat, I just want to make sure to clarify this. Jeff just very helpfully said that Flow provides a two-week trial so reach out to them if you want to get started quickly. ⁓ They're very friendly people they don't bite so it's always good. It's yeah crazy. So yeah with this yep you're good.
Zack: It's time to value on flows, pretty insane. They do two week pilots. Sorry I didn't mean to cut you off, Dylan.
Dylan DuFresne: So yeah, the one I wanted to give a shout out to was because of that problem of not making, needing to remake all the models every time, Sesame is coming up here for an interoperability. Their whole mission is smart manufacturing, interoperability. They're working on an API that a lot of these different vendors are involved with Sesame in various capacities. And the mission is to make a shared data profile. think they're calling it SMIPS smart profiles. They're making an API that will ideally make all of this interoperability. So I could define one data model in one place and import it into all the different softwares. So, SESME is definitely somebody to watch and support so that we can eventually in the future realize that mission.
Zack: Sweet, sweet.
Dylan DuFresne: home. Coming close to the hour here. We do have a hard cut off today so I to make sure there's no other questions Zach. Have been looking for those?
Zack: Yeah. And disclaimer, we're partners with a lot of these vendors. We're not actually affiliated or sponsored by, like, CESMII or any of these. This is an Abelara livestream, and this is our own thoughts.
Dylan DuFresne: And definitely keep up with the webinars here, because if you come to Proovit, everything we're talking about in these webinars will have built and ready to show in the booth live. I'm literally going to bring the server to the show. Everything's going be locally hosted. And we can run over all of these applications, how they integrate, and what problems we solved inside of them and with these platforms at the show.
Zack: What else? What are you most excited for at the Prova conference? ⁓
Dylan DuFresne: It's seeing all the demos, seeing all the new announcements. ⁓ If last year is any indication, we're going to see a lot of cool new product announcements. And then also just there's a lot more integrators this year. So last year there was almost all vendors and OEMs building and showing you their software. This year there's a lot more integrators, ourselves included, who are going to be there showing how these platforms work together and what problems you can solve. I've already heard rumblings of a lot of people talking about AI and it just workflows and different ways of working with that so definitely check those them all out. I'm not going to spoil who that is I'll let them do that on their time but there's a lot of cool stuff coming a lot of cool announcements and a lot of good people. Yeah. Any last comments here? ⁓
Zack: Dude, Dylan, thank you, man. Thank you. ⁓ What do you want to go over next? We'll do another live stream at the beginning of the year. And what should we cover next? If you guys have any suggestions, let us know.
Dylan DuFresne: Yeah, drop comments down below for any suggestions on future topics to cover. ⁓ In the absence of any of those, I think our next topic is going to be walking through the actual unified namespace that was provided and going from there. And I guess a quick teaser into that, really quick in the last two minutes here. Didn't tell Zach I wanted to do this, so sorry, Zach. So this is what we're going to talk about a little bit more next time. A little bit more exploring the Unified Namespace and what's there. But this was a quick application just for the discovery phase we built. And next time we'll talk about what the use case is, what type of ⁓ plant, and what they're doing at the different... ⁓ at the thing. And we'll be exploring the Unified Namespace, the business, and the use cases.
Zack: get to look little bit more at the data. Awesome. ⁓ Thank you, Dylan. you guys for watching. See you guys. Make to subscribe, like the video, share it with a friend. Thank you all for tuning in. And we'll see you in the next one. ⁓ Peace.
Dylan DuFresne: Yep, we'll get a look more at that. Alright, thank you.
Dylan DuFresne: Yeah, welcome. Glad to be here. Glad to have everyone in the chat. Looks like we've already got quite a few people watching live, so...
Zack: And there was over 200 people that registered and our channel just crossed over 250 subscribers. So thank you all. Make sure to subscribe to the channel if you're on YouTube It's an honor, honestly, Dylan.
Dylan DuFresne: Thank you. to have you here. Glad to have you at Abellara. Glad to be able to put on these webinars because you're here. Alright, yeah, then guess we'll kick off the webinar for today still related to Proovit. This is the second one in this series. Last time we talked a little bit about the intended architecture and today we're going to go into data modeling and different platforms and ways to do it. of the leading questions that we noticed last year at Proovit was everybody saying, hey, when would I use X over Y or why would I use your software over the other software? And ⁓ the context of data modeling, that's what we're going to do here today a little bit. ⁓ With all that said, ⁓ note is on bringing everybody up. We're not here to talk down at any other vendors. We're here to explain when to use what and why we believe it is the best for those scenarios. so to kick it off with that, the very first piece of all of this ⁓ why. data ops? What is data ops? What is data modeling? ⁓ And of that. And it into the very first piece of one of the biggest problems with most digital transformations is that you don't start with a start with a technology, start with a need for a UNS or the need for data modeling or things like that. You start with a problem and that usually leads to failure. ⁓ So with digital transformation you want to start with a problem. So ⁓ that you might a problem of a pump that keeps failing. Maybe each failure you like $50,000 not even in downtime just in repair costs. And you might have data that tells you that this motor keeps overheating and you have the data to tell you the temperature of that motor. you have something on the motor head or something monitoring temperature, but person who's doing the maintenance doesn't actually have that data. They don't know that it's overheating until it's already too late. So one the there is we have a pump keeps failing, but and we know that has that temperature set point. know somebody has a temperature of motor, that actual process variable, ⁓ but it's sitting in a PLC at data register F8-4 or something like that. And it doesn't have any units of measurement. Nobody knows what an F register is on the maintenance side. And we have a random data point in the middle of nowhere that means nothing to anyone. to actually solve the problem of that motor overheating, or at least to know about it ahead of time so we can solve it before it becomes a failure, ⁓ need to know that F8-4 ⁓ ⁓ motor temperature of that motor. ⁓ it's measured in Celsius or Fahrenheit, where it is to relative, and if it's ramping up. or down or where it's at in the real world and that data point of F8, F8-4 actually means that it's 80 degrees, 90 degrees Fahrenheit or Celsius or whatever that happens to be and when it starts to get over 100, 120, 130 degrees for too long of a time, hours on end, that's when the motor starts to fail. So even the simple things about temperature has been too high for too long can make a difference if you know what that data point means and have information in a way that you can understand. how do we get from that raw data point ⁓ F84 the ⁓ of ⁓ 5 temperature ⁓ is 80 Fahrenheit? That's a lot of extra context that didn't start with that data point. ⁓ In context not necessarily known by all the different systems. ⁓ And the of getting from that first point to that second point where we now have actionable information ⁓ at a
Zack: Right, right.
Dylan DuFresne: level, loose definition, that's data ops. How do we make add context and make information out of that data? With that, we've got different things. A lot of data ops takes the form of pipelines. But if we get even deeper into just data modeling first, before we get there, we have that data point. And this is where you start to get into JSON and things like that. But before we get there, maybe we should share the screen here and walk through a few things, introduce the players, and start from there.
Zack: When we said we were doing this webinar, we actually had several of the vendors reach out to us and set up meetings to kind of go deeper. Dylan's been working with Ignition and UDTs for a better part of a decade now. But this is one of the most common questions we get is, all right, I'm familiar with Ignition, let's say, and I'm using UDTs. how do I do that same concept but in another platform like High Byte or like a Litmus because oftentimes, especially at an enterprise scale, you're gonna have multiple platforms. You're gonna run into ⁓ where you have to take unlike assets and make them like, or unlike platforms and make them like.
Dylan DuFresne: And so. To lay the foundation for what we're going to talk about here today with the different vendors, we've got a handful of them, all that do data modeling in some way, or form to meet the needs of that platform, to allow that platform to solve the problems it was made for. And once we get deeper into each of these tools, we'll start to see exactly what problem they were made for. And once you understand why they were made, what they were made to solve, then you'll start to see how they fit together and why they were made to do that. We'll start on the plant floor systems down here. We've got Ignition started off as a SCADA system. Its real purpose in the very early days was to move data from PLCs to SQL databases. And then from there, it became a SCADA platform. From there, it became more of an IOT platform into the composable SCADA system that we know it as today. On the other side here, we've got Flow Software. Information Hub here, Analytics and Information. So they're really for the analytics layer. They're going to take a lot of that data at rest, model it in different ways, and do some real statistical analytics that a lot of the other systems just don't do because they're an analytics platform first and foremost. They will connect to your things, connect to your data, model that data. You'll see that theme here. And then once it's modeled, they can analyze it, calculate it, and send that out and bridge it to other platforms. ⁓ Next to that, you've got Litmus being the main platform for data, IOT and industrial data on the plant floor is where they really find themselves at home. So everything from device connectivity all the way through modeling it, they do some digital twin functionality. So when we talk about modeling Litmus, it's really built around that digital twin and doing things with that and passing it to other systems for visualization. ⁓ good IoT platform. has some time series storage capabilities and things like that. that's
Zack: So there's two for Litmus. Remember, there's two. on who they're selling to. So if they're selling to industry, they're an industrial data platform. But if they're selling to cloud, Litmus is like the Google Cloud Edge connector. If they're selling to cloud services, then the Litmus onboard, they call data platform.
Dylan DuFresne: Mm-hmm. Mm-hmm. ⁓ Edge data platform, industrial data platform, ⁓ a IOT platform, ⁓ around the plant floor data, but they do have some Edge offerings, ⁓ you said, white labeled in Google and things like that. ⁓
Zack: and some of the best drivers on the planet. a lot of the human, like if you look at who joined Litmus lately in the last year, go look at who joined Litmus in the last year. They've got some really heavy hitters. know, Adam Kennedy, Sam Elsner. These are like industry legends, or especially around the data and driver space, so.
Dylan DuFresne: Yep, and then off of that getting into like HighByte here. HighByte is at its core an integration platform. doing a lot of ETL and transferring of data from one place to another. ⁓ you're more on the IT side, they're really like an iPaaS platform, but for the plant floor ⁓ industrial connectors and connectivity options that a lot of your traditional IT iPaaS platforms don't have. ⁓ so as part of that ETL, you've got the transform piece, you've got ELT, you've got other patterns as well, but you've got that ⁓ matter what you're doing, a big part of that is forming, it's modeling the data in flight. ⁓ And they do a lot of that integration piece there. And then next to that on the top of the layer here, the most enterprise of the software's here, you have Fuse. They are cloud native and they're a lot like Ignition and where you can build platforms and build applications on top of them. But where Ignition came from connecting PLCs to SQL databases, Fuse came from connecting ERP systems to MES systems as a traditional IPaaS and then grew into a much larger composable system from there. Where Ignition is a composable SCADA system, Fuse is a composable MES. So in Fuse being cloud native, the data modeling for them is really around that data storage piece. ⁓ If you're familiar with MongoDB, you'll be defining your schemas in the same way you would there. It's all Mongo under the hood. But you're defining your data schema and your data models in Fuse for that purpose. So at a high level, those are the different
Zack: And the main distinction there is storage is built in. So when you, I don't believe any of the other platforms, you're storing it on a disk or you ⁓ have to in some way spin up some sort of server or spin up some sort of hardware or install a SQL, like for ignition, you got to install a SQL database. Fuse is all built in out of the box, cloud native.
Dylan DuFresne: players. Yes, storage is built in. Yeah, Fuse is all built in out of the box. It's all cloud native. Litmus does store its time series data in Influx database built into Litmus. And then Flow Software with their SQL backend does have some buffer. I believe it's like seven days or something, but there is a temporary storage piece inside of Flow as well. Hyibite doesn't do any storage because they're all about integration. So you're going to be moving something from one place to another and storing it externally. And Ignition has ⁓ relative storage for like real time stuff in the OPC tag. but for any like actual storage it needs an external database. ⁓ And so when we start getting into more of the abstract again, we'll start a little bit simple here, pull back a little bit. You have the very traditional, very common at this point path through digital transformation. I believe it was popularized by Walker Reynolds, if not created by him. But we have the traditional connect, collect, store, analyze, visualize, find patterns, report, solve. And this helps us identify the problems and connect and collect the store data. So the general workflow before we even get there, we have to start even deeper is I have a problem. Something that we need done, something that's not being done in the way we need it to be, but we have a problem that we need to solve. So then we have to identify the gap. Why don't we have that solution now? What do we need to solve it? If only I had that temperature of that motor, I can know it's overheating before it actually overheats and causes a problem, right? And so then we need to figure out what are the tools that we need to make that happen. Is that ignition? Is that litmus? need to do device connectivity, we need to connect to the PLC before we can even get anywhere. So maybe we're either going to select litmus or ignition in this case to connect to that PLC that that sensor is wired to. And then from there, we can use those platforms to prove that first value. And then we can expand that use case from there. And once we get into the prove value piece here, this is where we start our loop for the first time on connect, collect, store, analyze, visualize. So the first step would be using some edge connectivity piece like Litmus or Ignition or to get it into an initial piece from the PLC. Notably in the ones we talked about Ignition and Litmus are the only two that do any level of device connectivity. Fuse does as well but it's really geared towards the cloud piece so we'll stick with Litmus and Ignition for now. And using one of those platforms we're going connect to the PLC. We're going to collect that data point and this is where we're going to start to model it. We can either collect it and store it or we can collect it, model it, and store it. But at some point, we're to have to model it either between collect and store or between store and analyze. And if we're in a tool like ignition, that might just mean that when we take our data point from the PLC, we wrap it into a UDT, add the context, maybe with memory tags or SQL tags or stuff from other systems, package it together as a nice UDT, do some string compares and things like that to concatenate everything into that tag that we can then know this is the temperature of this, that, and that. If you're doing the UNS type implementation or you've got a broker or something, can publish it up to the UNS or you can just look at it right in those ignition tags. The ignition tag server itself can often act as UNS as well. But if we're just going to store it raw and then analyze it later, you might have a tool like Highbytes or Flow Software that's going to connect to that data store and analyze, model it and analyze it in flight there. ⁓ But once we've stored that data, we've analyzed it, we can visualize So we got to show it to the person who has the problem in a way that matters to them and they can start to find that pattern In the very simple example here, they can see a trend chart. Hey motors getting hot You should probably look at in the next couple hours and if they can act on that in time They can save that money prove the ROI and that's how we've proven our value from up here But once we found those patterns we can report on it and solve it That's where either the human in the loop comes in and says hey, I notice this pattern I'm gonna go solve it and I'm gonna shut off that motor let it cool down or I'm gonna run it a little bit slower or something in whatever acceptable way to mitigate the issue without affecting production. Or you could have some automatic systems that identify and do some machine learning to find those patterns, report on them, and solve them automatically closed loop as well. But generally speaking, that's the loop of identifying the problem and coming through to a solution. And with that, we got into the different ones here. Yeah. ⁓ So. With these different options all in their different homes, you've got your Composable SCADA in Ignition, your Analytics Platform in Flow, your Edge Data Platform in Litmus, your Industrial Integration Suite in Highbyte, and your Enterprise Composable MES and other things. You can do a lot of ERP functions too in FUSE. But then the problem is if I'm doing my data models in each one of these platforms, how do I know which data model is the right model? How do I keep them all consistent? and what do we do? And so just because all of these platforms can do data modeling doesn't mean you want to do data modeling them all of them all the time. So let's say we have a UNS stack where we have Litmus doing our device connectivity. Maybe ignition is... So let's say we've got Litmus. doing our device connectivity and visualizing an ignition. and visualizing an ignition ⁓ with its influx database and things like that. Litmus might be connecting to the device. It might be modeling it and storing it, just dumping it in as an UDT and ignition already, if we have the definition. ⁓ Ignition might be taking that data point. I can figure out these arrows and storing it in a SQL database or something of that nature. And from there, And then from there, we might have something like flow software connecting to other SQL databases, other historians and things like that to do more statistical queries and analysis. We might also have, depending on where you've got ignition could connect to high byte. If ignition is doing the PLC connectivity, you might have ignition and high bytes where ignition has the UDT modeled. takes the high byte and then it might publish it out to your unified namespace from there. where other systems can access it as the event driven piece there. there you might have your UNS publishing up to Fuse for enterprise applications. You might have your SQL database coming in and adding more master definitions and things like that in Highbytes. But so the question here comes down to the different use cases. So if you just need to connect to a PLC, a single PLC and show data and value really quickly, you might be able to get away with just ignition and nothing else. You might have a Modbus register, an Ethernet IP, or some other common industrial protocol. Ignition really good at talking to PLCs. And if that's all you're doing, you might be able to connect to the PLC with ignition, model it as a UDT with ignition and show it on a screen in perspective and call it a day with just that tool. But say you've got more context in your ERP or in some other proprietary database that's locked through an API, maybe a test and measurements database that has all of your historical time series and you want to know what the test was, what the measurement was, then you might have used ignition. To and high byte high byte getting that data from another integration platform or sending it to somewhere else and going from there so ⁓ zach making sense so far or what do we guess
Zack: Yeah, question, question. ⁓ So just that last example you gave right there, where you're using HighByte to, let's say, connect to other databases that have some sort of transactions or logs. In theory, you could do that same connection in both HighByte and or Flow. is really good at connecting to many different databases, either historical or transactional, and then bringing those together. ⁓ that scenario, how do you choose between those two?
Dylan DuFresne: Yes. Yes. Yes, so generally speaking my rule of thumb with arrows here and then we'll answer that my general rule of thumb ⁓ ⁓ and Flow is that HighByte is for data in motion ⁓ Flow is best for data at rest. ⁓ if you're going to be connecting to a bunch of databases, OSI Pi instances, various historians and things like that, various data silos and databases out in the field, definitely going to want to choose Flow ⁓ grab that data, contextualize it. It does some fancy magic with timestamps and things like that that your data scientists really happy. and then flow is morphed and then it can use calculation and analytics on that historical data as it models it and then pushes it out to something else. That's something else might even be HighByte as an event could be a calculated KPI and we started to HighByte for further integration platform pieces. But HighByte is really good for if I have an MQTT broker and a couple rest APIs or a webhook or a web socket or something where we need something now and it's all live event stream data around the UNS, HighByte's really good at listening for those events and in flight grabbing and adding that context and then pushing it out the other side as an integration platform. Litmus is definitely, you build your own API or a lot of systems that already have APIs, ⁓ all sorts of stuff like that. ⁓
Zack: Maybe like to build your own API almost, kind of too.
Dylan DuFresne: Yeah, so you might have one of them I came across lately was we have a bunch of spectrum data in fancy complex data types coming from a bunch of test and measurement databases instrumentation and it stores all of that in a proprietary file format that then other software that's built for it can go and understand and ingest it as a time series database, but it only exposes it as an API. And that data is relevant to the work order we're running. And that work order needs the context of what was this test before it can move on for quality control. before you can move on to the next step. Highbyte can interact with ignition for the PLC and live process data, while also connecting to the APIs from say your ERP for master definitions, or your test and measurements databases for your glorified time series databases for your more complex data after they've already been measured and normalized and simplified into scalar data. Highbyte is also really good for grabbing things like other file types, ⁓ much more complicated data. and moving it from place to place even if it doesn't necessarily understand what's in that file. ⁓ So, HighByte is really good for data in motion. If data is, if I'm modeling data and moving data, I want to use HighByte. If I'm modeling data and analyzing that data, I want to use Flow. And typically the data I want to analyze is going to require ⁓ all historical data that's in a database, whether it's a tabular database or a historian or something like that, ⁓ will connect to all.
Zack: Come.
Dylan DuFresne: of that and model it and do the analytics on it that you can only do when you have that history. Where HighByte can connect to databases, it can connect to all the real-time things, but it's really built to transform it in flight and then send it somewhere else.
Zack: So let me ask you this. ⁓ First, do we have on the rest of the agenda for the audience today? What can the audience expect us to go over next?
Dylan DuFresne: Yes, the next stuff, so a lot of the stuff here is we want to talk a little bit about an initiative that's trying to get some interoperability to allow some of these platforms to work together so we can share the data models between them and not have to remake them in every platform every time. We've got the... general Q &A at the end for sure and if we want to dive in a little bit to some ignition UDTs we can definitely do that live assuming it all works.
Zack: OK. And then if the audience has any specific questions or examples or use cases where you're wanting to decide, please leave them in the chat. we're happy to go over them. So then. How are things going with the overall Proovit preparation for the Proovit conference, like with the application and Dupinix and any update you want to give us on that?
Dylan DuFresne: Yep. So... Generally speaking not too much has changed from our last webinar. We'll jump into that here first So we've still got the same old stack we talked about last time So we won't go into too much detail because we've already got a couple hour video describing it But the same kind of concept so we're kind of building this out. We're working with our partner to PNICS to help do the development on it Working on our edge data coming through so the primary site so going back to prove it generally speaking the
Zack: you
Dylan DuFresne: on that we're going to choose to work with is what they're calling Enterprise B. It is a bodily manufacturer with three separate sites and we're going to handle each of those three sites slightly differently but allowing them to merge their data in a consistent format into an enterprise data set infused that allows it all to be usable by the enterprise teams. So on site one we're going to go big. This is a big ambitious site with a very very well-versed very digitally mature team that wants to solve all their own problems on site. It's probably built out some of the stuff before the corporate mandate of what tools to use and how to do it has come out And so on this site will be using ignition. We'll have multiple gateways looks like five different gateways ⁓ One for an edge gateway not necessarily ignition edge licensing but edge gateway as a function for device connectivity and edge functions We got a central tag server that really will act as our UNS even though it is OPC the central application and the single source of truth for all our real time event data on the plant floor is going to be the ignition tag server. And then we've got three different ignition instances here, a typical scale out architecture for the ⁓ MES system with the front end and the back end gateway, and then a single SCADA gateway running vision for plant floor SCADA level applications and possibly control. ⁓ We'll be using the time-based historian and flow software. So time-based historian for all of our scalar history. Flow software is an engine that also can connect to all the context and history in our Postgres database which is going to be doing all of our MES functions and then HighByte is the integration layer to get everything through the UNS and get everything consistent and normalized for the enterprise data applications. So we'll be publishing everything from the site up to the UNS in its raw edge form but also sending that data up through FUSE where we can do the functionality and I believe we're going to be building a warehouse manager management system in Fuse among other things and then using it as the iPaaS platform as well between the UNS and likely Google Cloud and then maintain X as well. But we'll get into the other sites a little bit too where they're going to one site might use just Litmus Edge as the device connectivity and we may or may not want high byte depending on if we need consistency maybe want to use high byte for all the models. So maybe we do some edge modeling close to the edge just like the hour with ignition on the other site in Litmus. but all of our enterprise models are going to be handled by Highbyte and managed and maintained at the corporate level. And we've also got a Fuse Edge Gateway on each site. Yes. Yep. So like here, we've got a Glipmous Edge Gateway. They may or may not want ignition out there for some visualization, but for this site, we just want to get data to the enterprise. This site was told that they need to get data to the UNS, but they didn't really find the need for it themselves yet, so they're just following orders.
Zack: Can you zoom in a little bit on those? Can you zoom in a little bit on those edges? Yeah, thank you.
Dylan DuFresne: And we're just going to run headless data collection with Litmus Edge, HighByte, and the Fuse Edge Gateway. HighByte being our quote unquote corporate standard, we're managing and maintaining all of our models. ⁓ Fuse Edge Gateway being that ⁓ that gets us to the Fuse SaaS ⁓ in the cloud. ⁓ we're getting a little bit away from data modeling on that, but they're using AMQP and some store and forward stuff. That's why we're not going through the UNS as the MQTT broker. ⁓
Zack: Nah, listen. Well, real quick, Dylan, we have some questions coming in on LinkedIn. Do you want me to kind of feed those to you as they're coming in, or do you want to hold them to the end?
Dylan DuFresne: Yeah. Yeah, what do we got? Yeah, I'm happy to answer them all as they come in. mean we go
Zack: All right, we have Glenn Gardner. He's in the chat monitoring the LinkedIn question. So Anas asked if Dylan can say a few words about security in Fuse. And he works in aerospace, and it's a prime concern generally. This is a great question. Real quick, want to mention on Fuse, I was so stoked yesterday because we had a $4 billion manufacturer reach out to Fuse. and say we came to you because Abelara recommended us. yeah, shout out to Fuse. right, but yeah, so tell us about security and Fuse.
Dylan DuFresne: Yeah. Yep, so security and fuse, that's part of why we're using the fuse edge gateway. rather than going through the MQTT broker and everything is the Fuse Edge Gateway is a single outbound connection from the Edge Gateway to its own service. So there's no third party apps. There's just one tunnel from Fuse to Fuse's managed cloud services. So for that, the security, for better or worse, there's only one application talking to itself in the cloud. So you've got one port to open from Fuse, outbound only to Fuse. ⁓ It's a closed connection. Nobody else has access it's just that one outbound port. ⁓ So if we were really concerned about security, then we might just use FUSE in the real world, we might just use FUSE alone to go say, Edge connectivity, Edge components through Litmus Edge, we're gonna do all of our Edge data ⁓ applications there, and then let's use FUSE as the single point outside of the system. One of the things being the SaaS platform and the cloud hosted tenants here, Fuse is handling all of that for you. They're doing all the role-based authentication. They're doing all the security. And one of the benefits of a more monolithic, I know they're a very micro service oriented platform, but from a user perspective, we're using one app, one vendor across the board means that we don't have doors open to other vendors as that pipeline moves. And then the Fuse handles all the security and scalability things inside of Fuse managed by your IT team in the Fuse application itself.
Zack: you Yeah, when we get into a boardroom, when we get into a discussion with someone from IT, like CIO or CTO, they love Fuse. Let's just put it that way. ⁓ Those are conversations we like to be in. But I like that you have, ⁓ yeah, Fuse, like what I was saying was, I lost my train of thought. ⁓ We had another question come in, let me ask this one. ⁓ So Ray asks, how much litmus is?
Dylan DuFresne: yourself. Mm-hmm.
Zack: How is this landing data inside of ignition? Are you using an OPC or another integrated method?
Dylan DuFresne: Uh-huh, yes. So, Litmus, landing inside of ignition, you've got different options, one of them being OPC, you could do MQTT if you've got the Serious Link modules, you could do other things like HiBytes. The simplest method is to use their ignition module, and it can land things as UDTs or things just natively in ignition as the module. It's gonna be the simplest option.
Zack: That's good.
Dylan DuFresne: So for this one here, from an ignition integration standpoint, both litmus. and Highbytes have ignition modules that treat it very natively and very first class support for ignition. The other one is not so much from a data modeling perspective, but over here, one of the reasons to use time-based historian is that it also has an ignition module that treats it just like a historian on anything else. So that's why we'd use this over another just raw time series database is it allows us to keep all of the functionality that ignition thinks of as a historian, all of your queries, all your scripts, all the pre-made functionality. inside of ignition is all still supported by using timebase and the ignition module where you have to recreate it if you use something else.
Zack: And I think it was just yesterday or today, the time-based ⁓ Ignition module is available on the third-party marketplace. ⁓ we're seeing an explosion of native modules, like, maintainX has a native module. I think Waits was talking about making an integration with Ignition. But so we're seeing all these different, like, Hi-Bite and Litmus. I actually wasn't aware that Litmus had a native module for Ignition.
Dylan DuFresne: Mm-hmm. Mm-hmm. Yeah, it's a powerful, powerful option there for sure.
Zack: And litmus and inductive are like the two titles. It's like litmus inductive. But yeah. All right, let me ask you this. ⁓ what I was going to say is I'm going to share a story about when I was using Fuse when you talk about security. Like I said, IT loves Fuse.
Dylan DuFresne: Mm-hmm. Yep.
Zack: It has all the certs. But from a personal experience, one of the things I liked was it was super easy for me to add two-factor authentication. So I can use a changing passkey, like a Google authenticator, to log into that cloud app. And that was just so easy to turn on. It was native out of the box. so from a security standpoint, they take care a lot of that for you. And if that didn't answer your question, Ray, or? ⁓
Dylan DuFresne: they do. ⁓
Zack: honest, just let us know. Yeah. Thank you.
Dylan DuFresne: And I do want to add one thing that all these ignition modules opens a lot of doors for integration options. Sometimes they're the best options, sometimes they're not. ⁓ There's always the trade-offs just like anything else in the build versus buy. So if you use a more open integration method like OPC or MQTT or some other REST API or some other way of integrating with ignition, other services can use that more natively too. But if it's a very tightly coupled ignition architecture, the ignition modules make it incredibly easy. to integrate fast. So there's the trade-off of simplicity versus long-term openness as well. So if you rely too heavily on ignition modules, you're really coupled to ignition. Whereas if you're using some of the more open standards, more APIs and OPC type stuff, then you can definitely have more interoperability to other things without having to also make those pipelines as well. So there's always the questions on do you use the API, do you use the MQTT integration,
Zack: you
Dylan DuFresne: use the OPC direct or to use an ignition module or some other platform that has modules like that. There's always trade-offs and one plant might want the modules and the other one might have a good reason not to use them but it opens a lot of doors and keeps things very capable so that's always a good thing.
Zack: ⁓ nike on six seven seven isn't ignition and high by a a match made in heaven i think it's a match made i also think ignition and let me say that that's great
Dylan DuFresne: So the thing with these are on every site we might not want all five of them, but they all play with each other really well in different ways in different situations. I mean, if you. ⁓ There's a lot to be said about litmus plus ignition plus fuse. This stack could get you best in class device connectivity, plant floor visibility and application building, as well as IT friendly application and feature building as well. If you throw. ⁓ Ignition, Hi-Byte, and Litmus together. You could do a lot of really cool things with Litmus, Ignition, and Hi-Byte, where Hi-Byte can be a much more manageable layer to a lot of API integrations, say even like ERP and stuff, where Ignition can technically do API calls, Hi-Byte can do them in a much more managed workflow-oriented way as an integration platform, and then Litmus opens the door to a lot more device connectivity options that Ignition has out the box. The other one is I could throw Ignition and Flow software at just about any problem where we have a bunch of existing data silos. And these are going to open up all the doors. So if you're a site that has 12, five, 10 different historians, a bunch of SQL databases, a bunch of data silos throughout your organization, just the Ignition plus Flow software, Flow software can connect to all of those historical data sources, do the analytics and pass that data to Ignition for visualization. So connect, collect, store might not be PLCs and devices. It might also be ERPs, API. warehouse management systems, supply chain, PLM, things like that with Highbyte or it could be historians and data sources with Flow software or it could be devices in the field with Litmus. Fuse and Highbyte have a lot of overlap as integration suites. So if you need a bunch, if you don't need all of your platform building enterprise applications in the cloud, you just need connectivity, Highbyte can do it. But if you also need all those connectivity options, Fuse can build the screens and the dashboard. the data backbone ⁓ storage and things like that, just like a Github can on the plant floor, but in the cloud for the enterprise. ⁓ Litmus and HighByte are both capable doing workflows and connecting to data points and publishing them out. ⁓ Where is really good at getting things from the OPCs and the APIs and things like that, ⁓ Litmus much better at getting them from the actual devices on the plant floor. ⁓ So might want both, you might only need one or the other, but you can combine these five logos in a hundred different ways. with or without all five, with two, with three, and there's hundred different matches made in heaven just with these five platforms.
Zack: And that's why we're very happy to be partnered with, I think, almost all of them. So my question is, ⁓ and we work with platforms that we're not partnered with all the time. We're agnostic. We like to pride ourselves on serving the client's needs and solving problems. So ⁓ where would you not use these platforms? Kind of give us a rapid fire. You would not use this platform for this type of use case.
Dylan DuFresne: Mm-hmm. So let's give you a quick example of, and this is again, this all comes down to what problem do we have and what problem are we trying to solve, right? So if I have a site that already has, let's say it's already running Rockboast Suite, it already has plant packs, it already has a factory-talked historian, everything's running perfectly fine on the controls layer, it's a relative process industry running plant packs, and everything's working just fine, but we can't access the data very well. to able to access that data and use the historian data and that live data in a way that makes a lot more sense, we could just throw flow on top, use the dashboards and flow and call it good enough for now because we can connect to the Faction Talk historian, we can connect to the OPC servers, we can do all we need to connect and model and analyze the data on top of existing brownfield situations. If we want to visualize it in various ways, then on the plant floor, that's when I would add ignition back in and now we can have ignition and flow sitting on top. of the existing infrastructure with plant packs in a way that's non-disruptive. But we might not need all the rest of these yet. But if I want to get that hooked up to the ERP in one way or another, I'm going to bring in either Hivite or Fuse, depending on what other problems we have that we need to solve as well. ⁓ If our problem is just device connectivity and we need data now and we need to know what it's doing and we just need to connect, collect, store as fast as possible, litmus is by far going to be your best answer. The other one, is if we're a mostly PLC based organization, we're only a one or two site small to medium company, Ignition will probably do everything you need out the box without any of the rest of them. But if I need device connectivity, even simple PLCs across a hundred sites, Litmus is definitely the one that's made for scale above all of the rest. So if we're talking a massive 100, 200, 300 site rollout, I might have just Ignition and Fuse, or sorry, just Fuse and Litmus because Litmus has the ability to maintain and deploy models
Zack: Yeah.
Dylan DuFresne: at an enterprise level where from a central location I can define a model and push it to my 100 litmus instances. And Fuse being the cloud native multi-tenant platform, I can build all of those in the cloud and functionality. So we might just have litmus on the field, going to Fuse in the cloud and calling it a day. If we need to add visibility on the plant floor, then we probably have Fuse, sorry, litmus and ignition on the plant at the site level and Fuse in the cloud level. And we might not need the rest of these. But again, where we would use one or the other really depends on what the needs are and what the brownfield currently looks like.
Zack: Damn. Do you dream about this stuff Dylan?
Dylan DuFresne: Maybe. ⁓
Zack: So for me, there's almost no scenario where I wouldn't use ignition. Fuse, you're in an environment where there's no cloud access, then obviously that cuts Fuse out. But then again, you can also run Fuse in your own environment as well too. And a lot of people in pharmaceutical, they will choose to run their own private instance of Fuse. if you don't have any historical data, your use case is probably going to be limited for flow, which is why they created the time-based historians. So if you don't have any historical data, start at time-based and then work your way into flow. Hi-Byte, there's almost no scenario where Hi-Byte wouldn't add value, like almost in any organization, even outside of manufacturing. Yeah. And then Litmus, if you don't have, if the drivers you need are all within ignition, then you don't need a bunch of different drivers, maybe Litmus isn't the best option.
Dylan DuFresne: You have four. Hmm. For a small to medium sized business, I'd probably start with these unless you've got some data types that ignition doesn't support, then you might need to throw something like Litmus in there. ⁓ For an enterprise customer, I would definitely start with something like this and maybe throw Flow in there as well for a large scale enterprise customer. But this is also assuming that we need plant floor visibility. There's a lot of times too where we might already have an existing OPC server and we just need to get data to the cloud and connect 100 sites really fast. HighByte on its own could do that as well. So then we might just have HighByte and Fuse we don't need all the data and visibility on the plant floor. We just need to get it to the cloud where we can do stuff with it as an enterprise. ⁓ then you could just have Fuse and HighByte or just Fuse and Litmas as well. ⁓
Zack: you Where do you choose no tool? Like where do you choose like if you're just starting, like if you're under five million a year or I would assume when you said small to medium you're talking like under 25 or under 50 million a year or?
Dylan DuFresne: Yeah, if you're to the point of digitizing. It's all going to be about ROI. Like all these tools cost money. if the problem you're solving doesn't generate enough revenue or save enough, if it doesn't reduce costs or increase profits enough, then to offset what it costs in the first place by enough of a margin that it's not worth doing. For your really small companies, and this people might not like me saying this too much, but for the really small companies, a good process is way more important than the tools you're using. So there are times where if you're small enough or even if you're relatively big, You can do a lot with just a clipboard and an Excel sheet. That's not a popular opinion, but if you don't have the processes in place yet, you're not ready for any of these. So you definitely need to have the process and the people on board before you can start integrating technology. It's people, process, and technology in that order for a reason. So if you're small and you're just testing things out, starting with Excel or Jira or some other tools that you can just spin up real quick and make work good enough for you today, getting started is always more important. than whatever technology you're choosing. So I would definitely recommend just an Excel sheet if you're small enough where that's all you need until you at least figure out what the process is and then figure out what the ROI would be of a bigger tool.
Zack: This is why our most successful clients choose to hire us to do a workshop to work with you. Like Dylan, know, is being hired to do digital transformation workshops where he'll dive into your processes, your people, and help you select this technology and architecture. ⁓ So that's one way to get started in focusing around the problem. We had a question that came in, speaking of all these tools costing money, can you give us an idea of what the price of all these solutions is?
Dylan DuFresne: It's going to depend on what you're doing with it. ⁓ I have to look offhand, actually let's do this then. Let's go Let's start with highbytes. Let's find it live. All most of these have public available pricing so for highbyte Let me see There we go
Zack: Zoom in, can you zoom in a little bit? There you go, yeah, perfect.
Dylan DuFresne: So for high byte, you can start with your evaluation license. I would just recommend at that point, it's still really cheap. I don't want to talk to support right now. I just want to look at the price. 17,500 a year, and that'll integrate all your platforms. You can have various users and it could get more expensive based on what else you need, but that's a good starting point. Flow software is pricing. You can start in here. They've got various options as well. So you can start at just under 10,000 for performance. perpetual license. ⁓ 14,000 ish for the unlimited. So I'd probably start with a 14,000 for Flow Software Unlimited, ⁓ 17,000 for Hi-Bite, Litmus Edge. Let's see if they still have pricing up here. This is gonna be a good test for all the vendors. So there's different options here. We'd have to talk to them about what the growth would be for real, but it's gonna depend on what your scale is. ⁓ Fuse doesn't have public pricing, it's going to be the most expensive of the options. Again, it's an enterprise scale, so we don't want to scare you away. The teams that are selecting these are usually much more... They're the same teams that are specing ERPs and the value of the use cases across 100 site versus the value on one site is a very different story. ⁓ High byte, we already went over. And then ignition is going to depend on what you're doing. But if we go to our various pricing options on ignition, there is ways
Zack: .
Dylan DuFresne: to started with ignition for as little as 10-15,000 all the way up to 25-50,000 depending on what the architecture looks like. But if you want to just get started really quick, a good gateway that'll do most of your features is going to be typically in my experience around 15-20,000 these days. And if you want to do a multi-gateway architecture that will scale a lot better for you, that's going to be between 25 and 50, depending on where you're looking at what modules you need. personal experience. If you want to get started with ignition, definitely go to their website and price out the module that way.
Zack: Sweet, yeah, and it's important to note, like, all of these are monthly or annually recurring subscriptions with the exception of Ignition, which is licensed standalone, and then there's like 18 to 25 % support annually. But all the other ones, I believe, are just an annual subscription.
Dylan DuFresne: And all of these have various forms of free trials as well. ⁓ Believe Flow has some form of a two hour trial. I've got to remember exactly what they have. If anyone from there is watching, if they could drop it in the chat, that would be really helpful. ⁓ Ignition has a two hour resettable trial, so you just have to reset it every two hours. Highbite and Litmus are the same, so you can download those and get started immediately ⁓ and just reset the trial every two hours to see if it'll solve your problems before you pay for it. And then Fuse is currently working to add that same two hour trial in. It's not quite there yet, they will be there soon. So all of these you can download and get started with pretty quickly and pretty easily especially once Fuse adds that two-hour trial. And in my personal experience every single one of these if you reach out to them we'll be more than happy to give you a demo and if you reach out to us we can orchestrate, coordinate, or do the demo with yourselves with multiple options.
Zack: Excellent. And if you reach out to any of these vendors and tell them Abellara sent you, it only helps.
Dylan DuFresne: Yeah, and guess in the last couple of minutes here, I did want to give a shout out a little bit. The one agenda item that I don't want to miss, we can always do the rest on other vendors, but in the name of data modeling, in all five of these platforms, you have various levels of data models. But the problem is I can't just take a data model, export it from ignition and import it into Litmus or Highbyte or from Flow to Fused to Highbyte or things like that. I have to redefine that data model in each of these platform. And in chat, I just want to make sure to clarify this. Jeff just very helpfully said that Flow provides a two-week trial so reach out to them if you want to get started quickly. ⁓ They're very friendly people they don't bite so it's always good. It's yeah crazy. So yeah with this yep you're good.
Zack: It's time to value on flows, pretty insane. They do two week pilots. Sorry I didn't mean to cut you off, Dylan.
Dylan DuFresne: So yeah, the one I wanted to give a shout out to was because of that problem of not making, needing to remake all the models every time, Sesame is coming up here for an interoperability. Their whole mission is smart manufacturing, interoperability. They're working on an API that a lot of these different vendors are involved with Sesame in various capacities. And the mission is to make a shared data profile. think they're calling it SMIPS smart profiles. They're making an API that will ideally make all of this interoperability. So I could define one data model in one place and import it into all the different softwares. So, SESME is definitely somebody to watch and support so that we can eventually in the future realize that mission.
Zack: Sweet, sweet.
Dylan DuFresne: home. Coming close to the hour here. We do have a hard cut off today so I to make sure there's no other questions Zach. Have been looking for those?
Zack: Yeah. And disclaimer, we're partners with a lot of these vendors. We're not actually affiliated or sponsored by, like, CESMII or any of these. This is an Abelara livestream, and this is our own thoughts.
Dylan DuFresne: And definitely keep up with the webinars here, because if you come to Proovit, everything we're talking about in these webinars will have built and ready to show in the booth live. I'm literally going to bring the server to the show. Everything's going be locally hosted. And we can run over all of these applications, how they integrate, and what problems we solved inside of them and with these platforms at the show.
Zack: What else? What are you most excited for at the Prova conference? ⁓
Dylan DuFresne: It's seeing all the demos, seeing all the new announcements. ⁓ If last year is any indication, we're going to see a lot of cool new product announcements. And then also just there's a lot more integrators this year. So last year there was almost all vendors and OEMs building and showing you their software. This year there's a lot more integrators, ourselves included, who are going to be there showing how these platforms work together and what problems you can solve. I've already heard rumblings of a lot of people talking about AI and it just workflows and different ways of working with that so definitely check those them all out. I'm not going to spoil who that is I'll let them do that on their time but there's a lot of cool stuff coming a lot of cool announcements and a lot of good people. Yeah. Any last comments here? ⁓
Zack: Dude, Dylan, thank you, man. Thank you. ⁓ What do you want to go over next? We'll do another live stream at the beginning of the year. And what should we cover next? If you guys have any suggestions, let us know.
Dylan DuFresne: Yeah, drop comments down below for any suggestions on future topics to cover. ⁓ In the absence of any of those, I think our next topic is going to be walking through the actual unified namespace that was provided and going from there. And I guess a quick teaser into that, really quick in the last two minutes here. Didn't tell Zach I wanted to do this, so sorry, Zach. So this is what we're going to talk about a little bit more next time. A little bit more exploring the Unified Namespace and what's there. But this was a quick application just for the discovery phase we built. And next time we'll talk about what the use case is, what type of ⁓ plant, and what they're doing at the different... ⁓ at the thing. And we'll be exploring the Unified Namespace, the business, and the use cases.
Zack: get to look little bit more at the data. Awesome. ⁓ Thank you, Dylan. you guys for watching. See you guys. Make to subscribe, like the video, share it with a friend. Thank you all for tuning in. And we'll see you in the next one. ⁓ Peace.
Dylan DuFresne: Yep, we'll get a look more at that. Alright, thank you.
