Using the MES as the Owner of the Configuration

There are different patterns and anti-patterns for storing information critical to the integration on MES. I will try to address those scenarios.

Topics#

1. Configuration
2. Anti-Pattern
3. Pattern

Configuration#

The Automation Manager on boot, already retrieves a lot of context information, such as what drivers to start and what is the logic in the Automation Controllers that it will need to execute. Nevertheless, when implementing an integration scenario sometimes it’s very helpful to try and maintain our controller more abstract and have a dynamic resolution for some configuration such as ports, ips, what interfaces to enable, etc.

If we for example, want to use an Automation Manager to control several Resources, but want to reuse the same Automation Driver and Automation Controller we want to be dynamic enough in our Automation Controller to support this scenario.

Anti-Pattern#

The common anti-patterns are two different approaches that seem ok, but don’t scale or obfuscate too much.

Workflow - Static#

The first one is a no-brainer, just leave it static, leave it in the OnEquipmentSetup or in the driver definition. This works well for immutable configurations, things that won’t change, when reusing the controller. This obviously is not very dynamic, because if Resource A and Resource B need different ports or ip, or any other configuration we will need to create a new Automation Controller.

As we can see in this example, we have the ResourceA as part of file Path, if we want to reuse this implementation for ResourceB it won’t work.

Workflow - Tokens#

One of the clever solutions we can use is tokenize, so instead of explicitly stating ResourceA we can write ${entityName} and Connect IoT will replace it in runtime with the correct value for the entity that is appended to the execution.

NOTE: In my opinion, I don’t like tokenization, because it results in obfuscation of the code and that is why for me it’s an anti pattern. It adds cognitive load to whomever is reading the workflow to know that tokens exist and to what they are replaced with. So I would advise caution when using tokens, but it has helped solve problems in the past, so it’s important to mention it.

Pattern#

The common patterns described here, may not be the only way, but are beaten paths that have worked well in the past.

NOTE: One consideration that always has to be made is the level of dynamism in correlation to the addition of complexity in you workflow.

Leveraging the MES Entity#

If the Connect IoT Controller is running embedded with the context of a MES Entity, it seems obvious to add the needed configuration to that context. This works well when we require few configurations and we can solve our issue just by adding attributes to our entity.

So this seems like it solves all problems right? Well take a look at this Resource:

We can see the list grows fast and bloats the definition of the resource. It also forces us to create some kind of query if we want to see all the configurations for Connect IoT. So this can be a too decentralized solution. It also does not allow for more dynamic resolution than just the entity, like a particular vendor, type, etc. Also, the type of user with access to the Resource Entity, may not be the user you want to have access to these types of configurations.

Using Configs#

An alternative, is the use of an MES Configuration. We can create a tree of configurations and then retrieve them in the workflow before starting. We can define the config tree appropriate to our needs and then use an Execute Service task to retrieve our configs. We can get the configurations with the service GetConfigByPath.

This will return a JSON object, which we will have to convert and extract the value.

This approach, enables us to group the information in a Configuration tree and behind the Administration tab, giving a more secure and aggregated location to our implementation configurations.

Smart Table#

The last pattern we will discuss is the Smart Table pattern. This enables dynamic resolution of configurations based on several different columns. Let’s try and see an example of this.

Imagine that depending on a context, for example, Resource, Resource Type or Area, we want to collect a particular subset of configurations. The configurations will have a name and value. We can create a Smart Table, like this:

This enables us to have a priority of resolution, history of changes and also we can have DEE Rules triggered on changes.

In the workflow we can then use a Resolve Table task, that will automatically be populated with the inputs and outputs and will resolve the Smart Table according to what are the inputs given.

In this case we had Name and Value, to simplify you can have only value and then have the object to manipulate there. We can also access either the rows output which will have all the columns. This use case requires a bit of logic downstream to treat the value and use them.

An example of the rows output, would be something like this:

[
  {
    "ROWID": "1",
    "Resource": "1805111613350000001",
    "Name": "Path",
    "Value": "C:\\",
    "CreatedBy": "System",
    "CreatedOn": "2018-05-11T15:13:42.030Z",
    "ModifiedBy": "System",
    "ModifiedOn": "2023-04-12T05:54:16.563Z",
    "LastServiceHistoryId": "2304121347210000011",
    "LastOperationHistorySeq": "638168756565633333"
  },
  {
    "ROWID": "2",
    "Resource": "1805111613350000001",
    "Name": "Type",
    "Value": "Test",
    "CreatedBy": "System",
    "CreatedOn": "2020-10-01T20:31:46.333Z",
    "ModifiedBy": "System",
    "ModifiedOn": "2023-04-12T05:54:16.660Z",
    "LastServiceHistoryId": "2304121347210000011",
    "LastOperationHistorySeq": "638168756566600000"
  }
]

The goal would then be to extract the values and according to name create our configuration.

This is probably the most powerful and dynamic method of configuration, but as we saw, it requires some more configuration and know-how. So use it with balance and consideration, in order to not introduce too much complexity to our solution.

Summary#

There are multiple approaches to tackling the same issue. We should always strive for balance a solution that is simple, but retains an adequate level of dynamism. Unfortunately, this is not a one size fits all post, but I hope it helps illustrate the thought process that you must have when thinking about these types of issues.

Author#

Hello 👏 , my name is João Roque ✌️#

I’ve been working for some years at Critical Manufacturing. I split my time working in the IoT Team and working with the project’s teams. You can visit me at https://j-roque.com/ or check me at LinkedIn

Skills: Connect IoT / DevOps