Rhize Up Podcast: Episode 5 – The Manufacturing Data Hub

The last thing is that this all comes through and is accessible through a query endpoint, and our query endpoint is a GraphQL endpoint. That allows a consumer to consume the data that we’ve been persisting via query. So you can hit our GraphQL endpoint and look at the job orders that running and the job orders that have run online. You can look at the current process values through the GraphQL endpoint. We federate our time series database, so you can also get history values right there from within the middle of a query within GraphQL. Because we’ve got quite a convenient architecture within Rhize – we’ve got the NATS broker embedded, we’ve got the graph embedded, and we’ve got the time series embedded. They’re quite well integrated together.

We’ve also got quite a number of options for getting data via subscription as well. We’ve got a natural Pub/Sub option. So if, for example, an order has been started, it’s a fairly trivial exercise to get Rhize set up so that we emit that event and make that available either through our broker, through MQTT, or maybe we pushed down to a queuing Kafka or something like that.

So when the data comes in and gets persisted, we’ve got a bunch of convenient methods for not only persisting that data but allowing the data to bounce back out of the platform and into other platforms and can be published to other interested parties. I think the difference is what we’re doing is reacting to the data as it gets persisted into the knowledge graph, and the moment after it’s been persisted into the knowledge graph, the data then still becomes available for Pub/Sub. The next stage of Pub/Sub where it’s happening is when the graph gives us convenient access to relationships.

A long explanation there, David, but, I think that tries to sum up some of the services that we’ve got in the platform and what we’re trying to do for the use cases that we’re interested in.

David: Yeah. Awesome. There’s certainly a lot in there. So let me see if I understand, and I’ll relay what I just heard back to you.

I would think that the edge agent is, in many ways, what we’re going to call the UNS piece of the Manufacturing Data Hub. This is all that edge data. Ideally, it’s been contextualized and normalized in some way. That’s mostly where we’re going to notice something change down at the PLC or in the SCADA layer. Something is occurring there. Is that a fair comparison to the edge agent?

Andy: It’s correct. Yeah. And the agents responsible for bringing that in.

Geoff: It’s also doing a bit of what Rick Bullotta was describing in the Uber Broker, which is republishing or breaking out a message and publishing it into different bits. What the edge agent is doing is taking a sensor and putting it in the context of your UNS equipment hierarchy. Okay, let’s say we’ve got a temperature sensor, which might be “Temperature Sensor 1” in the PLC. It will come in through the edge agent as “Temperature Sensor 1.” But it will get re-published into the UNS as equipment, maybe it’s “injection molding machine input temperature.”

So, it’s doing the data collection and the Pub/Sub broker bits, but it’s also binding into the standardized model. I know people tend to have different areas for sensor data in the UNS structures that then get re-published into a unified equipment hierarchy structure. The edge agent is doing that bit, as well, in that re-publishing and the breaking out of one message into multiple messages.

David: Yeah. To me, that rule engine is great for when sometimes the data I’m getting at the edge, I’m not really able to determine what’s actually happening here. So that’s when I create this rule engine to say that the temperature sensor changed, or perhaps the state of the machine changed. But based on its relationship to other data, that’s what the rule engine is doing. This thing changed. What does that mean? Ah, it means this is the outcome there. Now, I can apply the rule to it. And it’s that republish of Temperature Sensor 1. Now, it’s a piece of equipment, and something is occurring there. Is that correct?

Geoff: Not quite. So that’s all in the edge agent. This temperature has come in, and it’s republishing that and putting that in context and saying, okay that’s actually injection molding machine input temperature.

What the rule engine is doing is applying rules to that. And those rules are data rules. For example, we receive the temperature. But is that temperature good or bad? Is is it too high? Is it too low?

So the rule engine is actually somewhere you could apply limits to the temperature and then republish an event that says, “actually we’ve had an over temperature event here.”

It’s putting that temperature in the context of other streams of data or other topics. It also allows you to run an expression across multiple topics to determine whether something interesting has happened.

David: Perfect. Well, thanks for that explanation because I definitely misunderstood there. Great clarification.

Once we have the rule and we’ve just said, “Yep, this is proper; this is good.” Now, we’re going to instantiate a workflow. To me, this is really where it gets hard in the manufacturing execution or the manufacturing operations management. What are all the steps that actually need to occur there in this workflow? It could be just some movement of data, but in this workflow, there could also be some interactions with other systems that need to occur in the traditional way we look at workflow. Is ours doing the same thing on there as well?

Geoff: Here’s an example most people can kind of relate to – the car. If we were to run a Manufacturing Data Hub for our car, we would have an edge agent collecting the data. We might have a rule that’s looking at the engine temperature and monitoring the engine temperature between upper and lower limits. Maybe we’ve got that rule set up so that if the engine gets too hot, I want to trigger a workflow, and the workflow might automatically go and book my car into the mechanic and have it checked out. So, the workflow is triggered by an event of some sort.

But as a series of activities or series of actions that can happen in response to that event, that can be doing some sort of data pipeline, or it can be doing something that’s more of a long-running workflow. For example, I’m going to book my car for a service at the mechanic, and then all the steps of paying for that and picking it up afterward, and all of the sequence of actions that happen after I put my car in for a service.

David: I think related to the graph database, and this is when I first was introduced to what Rhize is doing, this to me is the true value. I’m pre-defining all the relationships. And I’ve also built it against a schema that is a widely accepted standard, but it’s a knowledge graph in the sense that we’re not constrained to a relational database, which has existed for a long time.

That’s the whole point. Every time we’re writing, we’re making these mutations, as they are called, within a graph database. The data that’s written in there is written in a way that is already predetermined, and there are rules for what this data needs to look like before we can run that mutation or make the change there.

So a lot of it in these previous steps is making sure that we’re getting it all ready to go. Then we’re going to pop it into the graph, and the beauty is that it’s a knowledge graph. And I’m not constrained to that relationship. Is that that fair?

Andy: Yeah, I think that’s fair. I think our graph database and the way that we’ve gone about implementing our graph database emphasizes the schema upfront.

We’re not emphasizing schema on write, which is kind of the way that a lot of graph databases assume they might be used. We’ve got this sort of flexibility of mutation that allows you to push the relationships. As you push the data it allows those relationships to evolve. We can do that with our graph database.

But what we’ve actually done, for the specifics of the ISA-95 ontology part of the database is we predefined the schema. We’ve pre-codified all the relationships between all the objects that ISA-95 exposes as part of that standard. When you push data into our Manufacturing Knowledge Graph, you need to respect the relationships that have already been pre-established within that schema.

Read more about the Manufacturing Knowledge Graph →

So that gives you a way to express with ISA-95. It allows you to know in advance what the relationships should be and what the queries back out of that database should be based on the ontology, on the schema that’s defined ISA-95. Which is difficult to do in anything other than a graph database because of the complexity of ISA-95. It’s an object model. It’s quite a complicated object model with a lot of recursion. When you want to access the knowledge graph because of the hierarchical nature of ISA-95 and the long learning relationships from materials all the way through to equipment to schedule, there’s often a real need to traverse and recurse those data objects when you’re accessing that data. I think you can only really do that with a graph database. I think that heavy recursion and traversing and joining across entities get wildly complicated when you’re working with an SQL server just because of the object-relational impedance mismatch. Which is probably a bit too technical, but that’s one of the advancements when you go with graph.

David: I was just going to say I’ve run into those queries where you’re joining across ten different tables just so you can get that data back. After that, I think it’s where you really start to bog down the system, especially if 20 people are trying to run a similar type of point.

But querying the data that’s important. We use a GraphQL API. It allows people to access not only the graph database but you can bring in other data as well. It’s not purely limited. And I think this relates to when we were talking about the Uber Broker. It’s about having that common endpoint where there’s going to be all these various nodes that are going to exist within that ecosystem, and if I want to get data out of them, as we look at it from the context of the UNS, I have to go to all of those various nodes. In this case, I can have a common node that will, if it makes sense or if it’s relevant, have it- that GraphQL API. Now, I can maybe have it hit those other services if it’s relevant, whether it’s time-series data or some data warehouse information we need to bring back. Just having that open GraphQL API that we’re using for that gives us the ability to access the data very quickly. Then the way you ask it questions that’s already been predefined. Is that right?

Andy: Yeah, that’s exactly right. But there’s something else with the way that GraphQL works, which makes it particularly convenient compared to all the other ways of expressing an API.

For example, if you’re using a Rest API, a very basic Rest API, you would tend to have an object on an endpoint. So you are able to determine, generally speaking, which object that you’re going to access. So you might have, you know, “my API slash version one slash products,” and then some parameters that allow you to sort of supply which product you are interested in.

Then, when you hit that product endpoint, which is effectively a path in Windows Explorer, for example. When you hit that endpoint, you’re going to get the files that exist in that folder. It’s analogous to a file system in a way. And that’s not the whole story. I’m just trying to find an analogy.

But if you’re accessing multiple entities, if you’re accessing products, but you’re also accessing orders or materials or other objects that are sort of hidden behind this database layer, what you end up having to do with the client side of things, if you’re interested in multiple objects, you’ve got to make multiple calls out to that REST API. Suppose you’re going to bring those objects back in your client code, in memory, or whatever system you’re working in. In that case, you’ve got to rebuild the relationships at runtime between those objects when you’ve queried for them, which limits your ability to manage complex object relationships on the client side. It’s cognitively difficult to code for that kind of thing.

And it’s almost exactly the same problem if you’re working with a broker. If you’re working with an MQTT broker, the topic structure defines part of the data. Your equipment hierarchy is defined by the path, the topic structure, and that kind of thing. So if you want to try to make relationships or understand how things in different parts of the broker are related, then you’ve got to do multiple subscriptions. Then there’s a temporal element to the way that you deal with the data that then arrives that allows you to connect that data back up.

It works because we’ve got this idea that we can democratize data with an MQTT subscription or a REST endpoint. We do run into this next problem of rebuilding relationships on the client side. You don’t get that with GraphQL. You query, and you can traverse and recurse across these objects that are available in the graph. But when you get your data back, the relationships are in place.

They’re embedded in the JSON response that you that you’ve got back. There’s a convenience there for the front-end developer or even for the back-end developer who’s putting together the business logic. You can choose the data you want and the query time, and you can bring it back into a predefined structure with the relationships in place. Then, you can work on that data. So it avoids the need for having orchestration of multiple different object types and many visits to the database because you get them in one hit on a single endpoint.