Coreflux + Ignition: Industrial Data Integration with MQTT - Ep 105

Okay, so first and foremost, the issue was integration.

So we needed to sort out integration.

And that's why we packed the broker with a component that was able to translate from protocol A to protocol B.

And the protocol that we decided to select was MQTT because you have everything structured.

And for something like Unify namespace, you're able to define it there internally.

It made sense.

And the brokers started to appear with that kind of connection, that connectivity.

We call it at times connectors.

And after a while we found out, no, another problem, another issue that we have is that everyone is doing microservices.

So all the time you need to have the structure that is handling data, trying to transform, aggregate the data, even convert data from one system to another.

So it's all about translation

in the end.

So we needed something that, besides translating protocols, like hardware, real physical ones like Modbus, Canvas, whatever, we needed to translate JSONs, protocol buffers.

And not only, I have a schema that defines a process value this way, and I want it that way.

there is a lot of translation that needs to occur.

So we created what we call the language of things.

So it's a way to handle events, but at the same time to create this aggregation and transforming data within the broker.

And with that, we are able to stream data, create workflows.

For instance, small automation controls, integrations for traceability, recipe management systems, or even machine learning ops, because we are able to do

that.

Yes, and I appreciate that.

So one of the things I recognize about the language of things, just understanding the product myself, one of the things I saw was you have these pillars in your product, and I want to talk about these.

One of them is the actions.

So you have different actions that can occur.

The other one that I really enjoyed just looking at was the models.

Okay, so first and foremost, the issue was integration.

So we needed to sort out integration.

And that's why we packed the broker with a component that was able to translate from protocol A to protocol B.

And the protocol that we decided to select was MQTT because you have everything structured.

And for something like Unify namespace, you're able to define it there internally.

It made sense.

And the brokers started to appear with that kind of connection, that connectivity.

We call it at times connectors.

And after a while we found out, no, another problem, another issue that we have is that everyone is doing microservices.

So all the time you need to have the structure that is handling data, trying to transform, aggregate the data, even convert data from one system to another.

So it's all about translation

in the end.

So we needed something that, besides translating protocols, like hardware, real physical ones like Modbus, Canvas, whatever, we needed to translate JSONs, protocol buffers.

And not only, I have a schema that defines a process value this way, and I want it that way.

there is a lot of translation that needs to occur.

So we created what we call the language of things.

So it's a way to handle events, but at the same time to create this aggregation and transforming data within the broker.

And with that, we are able to stream data, create workflows.

For instance, small automation controls, integrations for traceability, recipe management systems, or even machine learning ops, because we are able to do

that.

Yes, and I appreciate that.

So one of the things I recognize about the language of things, just understanding the product myself, one of the things I saw was you have these pillars in your product, and I want to talk about these.

One of them is the actions.

So you have different actions that can occur.

The other one that I really enjoyed just looking at was the models.