The complexity of operating manufacturing and production facilities continues to grow. Data is abundant but often siloed in many different applications. The need to drive improvements in safety, efficiency, quality and reliability often requires data from these many divergent sources.

In this Emerson Automation Experts podcast, Hamza Malik shares a solution to these silos of data, to bring them together to turn data into actionable information in order to drive performance improvements.

Give the podcast a listen and visit the Inmation—The Industrial Data Fabric section for more information on how you can build a foundation to optimize operations across your enterprise.

Jim: Hi, everyone. I’m Jim Cahill with another Emerson Automation Experts podcast. For too long, companies have faced an ever-evolving challenge trying to unlock the value trapped within their operational technology or OT data. The variety and volume of data sources is growing and it was time for a solution that ties them together whilst keeping the total cost of ownership low. OT benefits and IT have a solution in their estate that’s easy to manage.

I’m joined today by Hamza Malik to discuss ways to untrap this OT data with the Inmation application and drive performance improvements. Welcome, Hamza.

Hamza: Thank you, Jim. Happy to be here.

Jim: Well, it’s great having you here to share some of your expertise with our listeners. So, let’s dive right in and begin by asking you what exactly is Inmation?

Hamza: That’s a very pertinent question to begin with. For a lot of our listeners, this is more than likely to be the first time they’re going to hear about Inmation. So, I tried very hard to summarize what Inmation is in one sentence, but I ended up with two. So, here it goes. Inmation is essentially a secure, scalable OT data platform, purpose-built for the ever-increasing variety and volume of data that our customers around the world, regardless of industry, are collecting. Within an architectural perspective, it bridges systems from the field all the way to the cloud and all the way back.

Jim: Well, that gives it a good perspective, I think, of kind of where it fits for our customers. So, can you share some background on why it was created?

Hamza: Sure can. So, the folks that developed the Inmation platform, the Inmation OT data platform, were working within a space where connectivity between different systems was their bread and butter. And about, I’d say, 12 years ago, they realized that, again, because of the variety and volume of data that customers are collecting and that there is trapped value within all of this data that customers are collecting, there is actually no purpose-built system that is easy to deploy, has a relatively low total cost of ownership, can drive a relatively quick return on investment. And from a connectivity platform, there is no single product that allows you to do this.

So, essentially, Inmation was created to be the single product that this company makes so that it can handle the demands of a multitude of data-hungry applications within our customers’ organizations without the need to address the system and interface integration topic ever again. We have customers that we’ve been working with for decades. Teams change, priorities change, the amount of funding and resources available to our customers change. When these things happen, over the years, the architectural stack that our customers end up with can appear like a spaghetti, like a spaghetti diagram, which I think is a term a lot of our IT and OT customers will resonate with.

Connectivity, interfacing, cybersecurity challenges, all of these are topics that keep coming up again and again and again whenever a new system needs to be brought online or a new data source is brought online so that customers can tap into their data. Inmation solves that problem at the very heart of it. As a very core competency of the solution, it allows you to handle all of this data without having to worry about that integration and that interface struggle ever again.

Inmation DataStudio, the main client application for Inmation, is designed to be a secure and singular interface to access your entire data source network.

Jim: Yeah, you’re right that there’s so many sources of data and it’s ever-increasing to have something in there kind of bring it together to help do what you need to do to improve performance. That sounds very important. So let’s get into it a little more. Can you share some examples of use cases it can help our customers realize?

Hamza Yeah, so I’ve got two that I wanted to talk about today and I believe again just based on experience, conversations with a multitude of different customers across different sectors, these two tend to come up as challenges that a lot of our customers, if not all of them, are constantly dealing with. They’re not like one and done, they keep coming back up for reasons which our customers will know already.

So out of the two, the first one is about data integration and having a centralized OT data platform. So Inmation can collect and integrate data from different sources across the organization. I’ve already said that but here’s where I’ll mention what some of these data sources typically are. And they’re not limited to these but they’re just some of the most popular data sources that I’ve come across in my experience. So these could be your traditional data historians or your time series historians. These could be sensors, these could be PLCs, these could be HMIs, these could be IIOT devices and of course, there’s now a plethora of them available on the market and our customers are making use of them because they provide a valuable function. But the list goes on. These data sources, Jim, can also include process control systems, LIMS, so your laboratory information management system, your environmental monitoring systems, as well as your enterprise resource planning system, so your ERP systems.

By centralizing the data from all of these data sources into a central location, it becomes easier to access this data and then to analyze the information from various stages of the production process. One of the most common challenges I’ve heard directly from customers is that when you’ve gotten teams of multiple people, now those could be belonging to the same department, just certain different geographical locations, or they could be folks based in the same geographical location but working across two different teams. Let’s say there’s the process engineers and the maintenance engineers, but they’re working on the same problem and that happens a lot. One of the most common questions they’ll ask each other and it becomes a hindrance when they’re trying to crack this problem is they’re asking each other, are you looking at the same data that I’m looking at? And then are you looking at the most current data? Because my timestamp for data is this, what’s your timestamp? And just aligning on the same data set takes time, effort, resources, and what is it delaying? Solution to the problem. Inmation solves that head-on by giving everyone access to the same, sorry, by centralizing data from all data sources in the same place. You’re no longer relying on different systems and different databases, so it harmonizes together. So the first one in summary is around data integration and a centralized OT data platform and the benefits that that brings.

The second one Jim that I wanted to focus on today is predictive maintenance. Now, prescriptive maintenance is also a part of this, but the first step of course is trying to have a system that can predict when a process is going out of bounds and of course that can vary process to process, company to company, sector to sector. Or when a process is about to fail or when a particular asset is about to fail. Of course, these are extremely powerful capabilities for our customers to empower themselves with.

So by leveraging the external machine learning algorithms and the predictive analytics capabilities, Inmation can enable predictive maintenance over a range of scenarios. It can expose data from equipment sensors and historical maintenance records, for example, to a predictive maintenance engine to help identify patterns that indicate potential equipment failures. So it will ingest data largely from your maintenance records and also from data sheets pertaining to particular sensors or assets and also data from the traditional historian that almost all of our customers have in place.

Once it’s ingested all of that data, the machine learning algorithm now is empowered and trained to a degree where it can look at historical performance and then project where those failures are likely… or sorry, when those failures most importantly are likely to occur again. So no longer are you focused on let’s say, calendar-based maintenance, rather you can optimize your maintenance spend on condition-based maintenance, which is a move almost all of our customers are trying to achieve. So in essence, this allows proactive maintenance interventions, reducing downtime and improving overall equipment effectiveness.

Jim: Well, that sounds like a really powerful use case, that predictive maintenance and being able to take advantage once you have that data, the machine learning to be able to help you identify bad situations that may be coming up. So how is, just to make sure we’ve got this here, how is Inmation different than a traditional control system historian?

Hamza: That’s a very pertinent question. You know, whenever you talk to anybody about something new, no matter what it is, it doesn’t have to be work. It could be outside of work. They need a benchmark. They need context. They need something to compare this new idea, this new solution, this new product to, because it allows them to digest that information a lot quicker. So whenever I’ve spoken about Inmation, and I know some of my other colleagues have faced the same questions, the most common question we get is this, “Hamza, we have a traditional control system historian in place already. We have an OT database. We have a traditional time series historian in place. How is Inmation different?” And it’s a very, very valid question because Inmation does bring new capabilities to the market, to our customers.

So to start off with the types of data that our customers are collecting has extended way beyond or much beyond type series data. Inmation is purpose-built to handle all these types of OT data, and it is also therefore purpose-built to handle the volume of all these types of OT datasets. It is a highly and easily extensible, distributed, parallel, object-oriented, soft real-time system with horizontal scaling on multiple layers. It also has with it a hybrid in-memory and document database. And it allows you the ability or gives you the ability to historize your data. And because it is scalable, extensible, horizontally, the historian, the embedded historian of choice within the Inmation solution is MongoDB, which is the NoSQL database. And the reason that was chosen by the developers of Inmation is because of its scalability.

We’ll come on to some customer examples later, but the feedback from the market was that if your solution is going to be this scalable, the historian, the embedded historian within Inmation needs to be just as scalable. And that’s why, as I mentioned, Jim, the developers of Inmation went down the route of MongoDB. And all of those capabilities coming together make it starkly different in terms of the capabilities it’s going to empower our users with than a traditional control system historian, which has its place. But like I said, they’re addressing very, very different worlds as it were.

Jim: Yeah. That makes sense that it’s not just that time series, it’s everything else. And I guess the sheer amount and speed that scalability would require something that’s not SQL to be able to do that. So can you share some customer examples of how Inmation has been applied?

Hamza: That’s right. I mean, I sure can. And I think there’s nothing better than actually sharing these examples because of course, everybody would say and would like to say, hey, my solution is the best thing since sliced bread, but there is nothing better than actual customer examples. So I’ve got three and I’ve tried to diversify them across different sectors. So I’ve got one from the chemical sector, one from the pharmaceutical life sciences sector, one from the oil and gas sector, the energy sector.

So let me start off with BASF, a huge German chemical company that’s been around for decades. So BASF actually uses Inmation to connect information from a variety of different data sources, including legacy historians from over 130 globally distributed sites, to provide an IT/OT integration backbone. It’s handling upwards of 2 million inserts per second currently, and that’s growing. And it is ever expanding as additional facilities and processes are brought online. Performance by BASF, they’ve been using it for over a decade now, I believe. So the performance that has been benchmarked by BASF is between 10x to 100x that of a traditional enterprise historian. So if we go back to the benchmarking that we were talking about, the previous question where people tend to compare Inmation to something, it tends to be a traditional historian, whether that’s site-specific or whether it’s enterprise, BASF over 10 years. So you can have confidence in a qualitative and a quantitative amount of data on which they base this benchmarking. They believe it’s 10x to 100x that of a traditional historian.

My other example comes from the Japanese life sciences giant Takeda, Jim, and they’re using Inmation to broker data between hundreds of plant historians and their IT data lake, with which it provides clean and contextualized data. When you’ve got different plant historians, they are coming from different sites, whether those sites were brought online via acquisition, what baggage or legacy historians those sites are going to bring with them, it can take years and truly years, Jim, to harmonize all of those to bring them on to the same level of automation maturity. But there is trapped value within those historians in the case of Takeda specifically.

So you’re trying to achieve one thing, but the data those systems can save is entirely valuable. With Inmation, there is no longer the need to harmonize all of these different systems to bring them on to the same level of automation maturity. As they are, you can tap into that data, pull it into Inmation, and they’d send it on to your IT data lake readily. So you can go about unlocking that trapped value from day one.

My third example, Jim, is a major oil and gas company, which is using Inmation to harmonize data from various vendors that have been put in place over decades. Within Inmation, they’ve been able to turn these systems, their instrumentation asset management systems in particular, they’ve been able to turn these systems into more than engineering tools. They now have a way to protect their old investments. As I mentioned, these systems have been put in place over the decades, and they’ve enabled the direct benefits that this implementation has been able to unlock, is reduction of unplanned downtime, increased maintenance efficiency, and better turnaround scoping.

In the words of one of the individuals I work with on a very close basis at this particular company, they said it’s enabled them to climb further the autonomous operations staircase. And I think when it comes to autonomous operations, not least due to the challenges we’ve faced over the last three or four years where people had to have the ability to connect to their sites remotely without being able to go on the site. I think a lot of our customers are trying to enable autonomous operations in some degree, to some level of maturity. And Inmation has allowed this particular customer to achieve that.

Jim: Yeah. And I think the people in the oil and gas industries are at the forefront, just given the spread out, whether it’s onshore or offshore, in doing that and driving it. So, those are great examples from a breadth of industries there. Let’s switch gears a little bit. I know people are very concerned about standards, compliance, and everything. So, how does Inmation follow the global OPC UA standard?

Hamza: Yeah. Again, a very pertinent question, not least, Jim, because of the proliferation of this OPC UA standard in industry. It’s been happening for a number of years, and it’s only going to continue. It’s only going to gain pace.

Now, Inmation have actually taken the OPC UA data models as an inspiration for the entire core design of the system, but the standard is strictly adhered to on the interface level, so between the client and the server. A bonus positive outcome of this, which is not always obvious in the initial stages of evaluation of the Inmation system, is that it turns any exposed object in the model hierarchy into an OPC UA-compliant item in the Inmation server interface. What that means, as a result, is that by this intrinsic conversion, any solution to facelift, or… yeah, to facelift really, legacy interfaces is obsolete. This in itself is a significant value add. So, if you combine this with object-level security, this creates a very flexible global UA namespace, which can be leveraged by UA clients in multiple use cases.

Another area where Inmation follows the global OPC UA standard is the data aggregation in its historian, i.e. MongoDB. So, they provide all the specified historical aggregates according to the OPC specifications. A number of customers come to me to say, Hamza, great that this supports this, this, and this. Well, we’re moving towards OPC UA, but we’ve got a lot of redundancy. We’ve got a lot of interfaces that we’re worried will not help set us up for the future, so we’re not future-proofed. This is where this positive, like a bonus positive outcome, as I mentioned, Jim, comes into its own. These guys are launching extremely expensive and resource-intensive products to, like I said, modernize, facelift all of these legacy interfaces. But because of this core competency within Inmation, they don’t have to do any of this. And as I mentioned, we want our customers to be empowered to make use of their data, no matter where it’s coming from, from day one, so that their total cost of ownership, their ROI, starts taking place from day one. And this core competency of Inmation allows them to do that.

But that’s OPC UA. But of course, a lot of our customers have not taken a leap yet into that area. So I do want to point out that it’s important to note that Inmation also provides support from any common legacy interface technology with a significant install base. A lot of these, if not all of them, will resonate with our customers. These could be classic COM-based. It could be OPC DA, so OPC Classic. These could be HTTP-based interfaces, native PLC communication for the likes of, say, Siemens S5 or S7, and Allen-Bradley Logix 5000, etc. So we’re not leaving anybody behind. It’s just that we’re realizing that OPC UA is where a lot of folks are standardizing. So we want to be there for them. We don’t want to leave anyone behind. So we’re supporting all of the interfaces and protocols that have a significant install base.

Jim: Yeah. That breadth is really important based on what people may have from a legacy perspective. But you’re right that OPC UA is just becoming more and more and more prevalent out there.

Now earlier, we touched on scalability. But can you tell us a little bit more about how Inmation works from a scalability perspective?

Hamza: So, when we look at industrial use cases, oftentimes they have a common goal, better decision support, higher degree of automation, reduction of abnormal situations, etc. The list goes on. But real-life requirements to implement these use cases vary depending on individual system landscapes, different forms of master data, the standards, which we just spoke about that are in place, the desired products that are, again, available at that point and that the folks who are evaluating this have an inclination towards, and technologies to use, policies to respect, and so on and so forth. As such, a global data integration platform therefore must be extensible, scalable, infinitely adaptive. In other words, it must be elastic. Inmation is such an elastic system.

The Outer Execution Environment is the single Inmation component service, i.e. a connector. So the verbiage used for this interface is connector. Each instance of such a connector can embed as many user code tasks as required. So the scalability is immense just from that one area. What needs to be ensured, however, is not something on the Inmation side. It’s actually on the other side, which is that the processing power and the memory resources of the host computer, so the server, whether it be virtual or on-prem or hybrid, and its limitations do not hinder the performance of the Inmation system. So the connector is infinitely scalable. You can embed as many user code tasks as required. In other words, you can get a lot out of a single connector. It just needs to be ensured that the demand that you’re putting on the system, let’s even say the demand you’re putting on the Inmation connector in this example, Jim, is not hindered by limitations, whether they be processing power or memory resources of the host computer. As long as those match, and I’ll call it hardware, as long as the hardware matches the demands you’re putting on the Inmation system, the Inmation system will not fail you.

Jim: Well, that makes sense, that matching it to the capabilities of that hardware there.

So I guess as we begin to wind down here, so how easy is Inmation to deploy?

Hamza: So Jim, over the last couple of minutes, or last few minutes, sorry, spoken about the scalability, the horizontal scalability, the ability to adapt, the extensibility, the elasticity of the system. That’s a very pertinent question, because some listeners might be thinking, my goodness, it can do all of this. So that means implementing it is going to be, or deploying it is going to be tasked in a project within itself. Thankfully, the folks at Inmation have already thought of this. Again, when they were developing the system, they realized that if it’s not easy to deploy, the benefits will become a secondary consideration for our, in this case, our IT folks, because they’re typically the ones who are evaluating the implementation of the solution into their route, into their estate, into their IT estate for the OT folks to make use of.

So Inmation’s services are distributed in the form of a single file. So it’s one binary, which hosts all the code for all the service facets. There are no dependencies whatsoever. There are no DLLs. There’s no .NET dependency. Normally, the product setup will be used to install a component service, which only takes a couple of minutes and a few mouse clicks. Once up and running, it will be further managed, monitored, and engineered through the central workbench Inmation, and that’s named Inmation Data Studio.

So to summarize, there’s two things there. The installation is a single file, and to get that up and running takes a couple of minutes. I have first-hand experience of sitting with customers on calls, and they’re new to Inmation, a little bit nervous, they need a little bit of hand-holding, Jim. I’ve been on calls with some of our engineers and the customer and their IT team to actually see this play out in person. They’re constantly surprised by how quick it is to deploy the system. Then the question comes towards actually maintaining the system. As I mentioned, there is a single dedicated central workbench within the world of Inmation named Data Studio, in which you can see the performance and status of your entire system. The companies I mentioned a few minutes ago, the Takedas of this world, the BASFs, the major oil and gas company I gave the example of, Jim, all of these folks have sizable, significant Inmation implementations, but they’re entirely being managed through a single component, a single workbench called Data Studio. It makes the whole process of deploying it and then managing the deployment a lot less resource-intensive, which will, of course, music to our customers’ ears.

Jim: Well, that sounds pretty straightforward that you’re not having to futz around with .NET stuff or DLLs and all that kind of stuff, and then managing through the Inmation Data Studio. So, Hamza, I guess to wind down, where can our listeners go to learn more about Inmation?

Hamza: Yeah. So, my first recommendation, Jim, to our listeners would be to speak to their local Emerson salesperson. That is the best place to start. If it is a question they cannot answer, it will find itself to someone like myself who focuses on our industrial software portfolio. And Inmation is a key part of that. So, yeah, speak to your local Emerson salesperson. There’s also a website link that I can share for customers who want to do some pre-reading. And that may spark some questions in itself they can raise with their local Emerson salespeople.

Jim: Yeah. And we’ll add a hyperlink in the transcript so people can get right to the site for Inmation.

Well, Hamza, thank you so much for joining the podcast today and sharing your expertise with our listeners.

-End of transcript-