HolyMate MES
I have written about HolyMate, and MES many times in previous articles. This article is about the same subject, again. And this time, its really cool. Until now, the MES project, and the actual HolyMate project were seperated; because the MES project was not usable yet. In the last few days, I have made many, many additions to the MES project. And currently it is in a usable state.
How does a MES system work again?
I have shown diagrams before, which describe the domain/models of the ISA-95 standard. Today, I will try to show the way they are connected, and their way of describing a production process. In order to describe a process using a computer system, you need to model it first. This means that you need a generic way to describe concepts, which can then interact with each other. Creating the models and the ways they can interact is very difficult, and any flaws that your models/interactions have might only show up late into development; leading to all kinds of nasty hacks. I have experience with the ISA-95 standard, which is a proven collection of models and interactions for this purpose. This does not mean that it is the only way to describe a production process, there are many other roads that also lead to Rome.
The most important models in my implementation are:
| Name | Purpose |
|---|---|
| Material Class | A class of materials, which can be used to group materials. Material Definitions inherit all properties from their respective classes. |
| Equipment Class | The same as a material class, but meant for equipment. |
| Material Definition | Can inherits properties from material classes. Describes a ‘material’, which is something a process can consume and produce. |
| Equipment | The same as a material definition, but meant for equipment. |
| Process Segment | A hierarchical structure of physical locations, going (top-down) from Enterprise to Process cell. Process cells should have properties that get inherited by operations segments. |
| Operations Segment | An operation that can happen inside of a specific process cell. Operations consume and produce materials while using equipment (stored in different models). |
| Job Order | A planned version of an operation segment. This is a read-only copy of an operations segment, that has a specific state: ‘planned’, ‘in production’, or ‘ready’. Job orders describe what should happen |
| Job Response | An executed result for a specific job order. This is a read-only copy of an operations segment, that describes what has happened. |
| Material lot | An actual physical instance of a material definition, with a specific quantity and location. Can be consumed and produced by a Job Response. |
There are more models, but most of those are sub-models that describe properties, requirements, specifications or actual results. So they are left out, and only really exist for the purpose of storing them in a traditional relational database. To make these models more intuitive, lets imagine we have a 1kg pack of sugar we’ve bought at a store. It looks like this:
In order to describe this pack of sugar, we need a handful of different models. Specifically a Material Class, a Material Definition and finally a Material Lot. Lets create a material class that all packs of sugar inherit from, because we might have different kinds of sugar in the future, all of which have shared properties. This material class will simply by called “sugar”. Lets not add any properties, we only use a single kind of sugar, so there is no need for any. Sugar is a bought good, we do not produce any sugar ourselves. Almost all externally produced goods have a few things in common, such as a Batch, a BBD and an EAN. Lets add a material class for externally produced goods, so we can share these properties.
| ID | Material Class name | Properties |
|---|---|---|
| 2 | Sugar | - |
| 3 | Externally produced | EAN(=unset), BBD(=unset), Batch(=unset) |
We can now create a material definition for our pack of sugar, which has a specific type and brand. Lets call this definition “Jumbo Sugar”. This material definition inherits from two classes, “Sugar” and “Externally produced”. Inheriting from a class means that this material definiton belongs to a group, and that it may have the properties its class has. In this case, our pack of “Jumbo sugar” has an EAN, a Batch-code, but sugar does not have a BBD. This means that we simply do not opt-in for inheriting the BBD property. Inheritance is by default opt-out, and must be explicitly set for each property. The EAN is the same for every pack of Jumbo Sugar, so we can define the value of this property at the material definition level. Once a property is set, all children that inherit that property will also inherit the value (but this can be overwritten).
| ID | Material Definition name | Material Classes | Properties |
|---|---|---|---|
| 2 | Jumbo Sugar | Sugar, Externally Produced | EAN(=8718452068340), Batch(=unset) |
We now have everything that is required to create a digital representation (material lot) for our real pack of sugar. Material lot names in my MES implementation are (by default) named as follows “{material id}-{date}-{time}”, The name for this pack of sugar is “2-20250102-154208”, and the material definition is “Jumbo Sugar”, and the batch is written on the side of the pack:
This would be represented as follows:
| ID | Material lot name | Material Definition name | Properties | Quantity |
|---|---|---|---|---|
| 9 | 2-20250102-154208 | Jumbo sugar | EAN(=8718452068340), Batch(=26300124Z2P01) | 1000 gr |
or, as shown in my MES implementation (above photos are from a different pack of sugar, so the batch-code doesn’t match):
If we print a sticker with a barcode, and stick it onto the pack of sugar. we can easily refer to this specific material lot every time we use it. Other models work in a similar way, so I won’t describe them in as much detail.
What does this add to the production of HolyMate?
If you are making your own HolyMate, you may wonder “Why would I ever need this?”, and that is a valid question if you are only making a couple of litres. But if you are making many litres, on a repeated basis, you will eventually want to track and monitor it. By creating a digital representation, you can solve this in an almost automated way. Using this system, I no longer need to lookup the recipe or manually keep track of small deviations/dates. I simply enter the recipes into the system (= operations segment), and schedule them to be executed (= job order) where I simply use my phone to see exactly how much of each ingredient I need to gather. And in the event of a recall, where one of our suppliers (sugar, citric acid, tea, etc.) has made a mistake, we can easily lookup if we have used affected batches, and in which processes. This way we can even forward this recall to every bottle of holy mate that is made using affected ingredients.
It also allows us to easily share insights of the production to everyone who ever gets a bottle of mate. Want to know which batch of sugar we used? when we bought that sugar? If we’ve used that bag multiple times? you can, at the click of a few buttons! Ofcourse, everything is still under construction, and will probably change, but this is already live, right now! There are no bottles in the wild that are created using it yet, but I did use the system yesterday to create 18L of HolyMate. If you are curious, and want to click around; a read-only mode of the MES system is live at mes.holymate.nl. If you want to see the details of yesterday’s (2 jan 2025) production run, simply open the Track & Trace, and view the details for this material lot ‘5-20250102-191033’. It should look like this:
This currently only shows a single step but in the future, when multiple steps are executed, it will look more like this (this is mock data):
And yes, all sources are available on my Gitlab.
Thank you for reading this article.If you spot any mistakes or if you would like to contact me, visit the contact page for more details.
