The idea behind MESBuilder


It all started with our disappointing experiences with standard MES software

MESBuilder is developed from the frustrations that we had when doing projects with existing MES packages. Packages that preached efficiency and flexibility for customers, proved themselves to be far from efficient and flexible. Every time we had to use work-arounds and add-on programming or customization to start from scratch. For both the customer and for us this was unsatisfactory.


We selected 10 MES projects

That gave us the simple idea to choose ten by us performed exemplaric MES projects - ranging for various industries, performed with different requirements for different applications and developed with different packages - and to ask ourselves the question: "Is there a generic method for developing where we quickly and efficiently could make these systems and that each system meets the requirements? ".
This was not easy. It raised fundamental questions such as "What is difference between materials and processes?" or "What is the difference between systems and machines?" up to "What does a MES system actually do?".

Of course we have studied extensively generic standards such as ISA95 to see if they could provide a basic model as start for our MES development. That was not the case. ISA95 is an excellent standard for communication between systems, but no suitable as internal standard inside a MES system.


 OPCUA as interoperability and modeling platform and filled the gap

Eventually the breakthrough came by studying another standard, OPCUA (OPCUA should not be confused with OPC Classic). OPCUA is an modern interoperability standard for the industry. That is to say that it is not only a communication protocol for industrial devices, but also is able to exchange meta-data comming from those devices to other devices.
In other words, except that they talk to each other, they also exchange information in the field of "I'm a xyz device, what are you?" to "What can we do for each other?".
This meta-data is not part of the OPCUA standard model, it has to be modeled in any way for each family of devices and is added to the standard model as "companion standard". Exactly this feature of OPCUA possesses extensive capabilities for object-oriented data modeling without interfering with the content. This feature we have played up to the last fiber.
Our data model for each MES system starts only with four fundamental objecttypes extra added to the standard OPCUA model. These fundamental objecttypes  have to do in which part of the server they are located. By adding these extra objects to the OPCUA basic object model, and with using the object orientated nature of OPCUA it suddenly became possible to compose a fitting model for all 10 projects. Next step was - rather than starting from scratch to create a OPCUA server - to develop a generation tool. We describe this tool as 'a 3-D printer for software'. The concept of OMServer was born.


The next challenge was High Availability

In one of the projects the customer had two production sites with a data connection which often failed. One requirement was that after recovering of the connection the new data created in both locations had to be synchronized. Here's the OMCloud concept emerged. Servers take over each other's tasks in case of failure. The appropriate data is synchronized when the communication returns. Clients communicate transparently, they are on the surface not aware to what server they talk, the outcome should always be the same.