Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ Manufacturing Execution System 2023 R2

MES middleware deployment considerations

  • Last UpdatedFeb 25, 2025
  • 6 minute read

The typical locations on which to run the MES middleware host are either the Application Server (with System Platform) or standalone (no System Platform). It is recommended that the MES middleware host not be run on the Production Database Server except to host specific Production Database Server tasks such as Enterprise Integration.

In a production environment, it is recommended that the MES middleware host run on the Application Server to address the following:

  • It is best to not load the Production Database Server with additional process tasks.

    The MES middleware host can be run on the Production Database Server if you are trying to keep the hardware footprint to a minimum. This is usually only applicable to small systems (an example small system is one for OEE and Downtime with 12 entities collecting downtime).

  • Load balancing of the MES middleware across multiple Application Servers might be required based on the implementation size and production load. See Load Balancing of the MES Middleware.

If the MES Web Portal is used, then the IIS server hosting the MES Web Portal is recommended to have the MES middleware.

The recommended number of MES middleware hosts for a medium-size system are:

  • One for each Application Server

  • One for each Work Tasks Server

  • One for each Terminal Server

  • One for each Web Server with MES Web Portal; the MES middleware on this server hosts the MES Web API

  • One for Enterprise Integration, typically on the Database Server

  • One for each MES Cloud Integration Server hosting the MES Curation service

Scaling

When scaling, scale by process area. Servers running System Platform Application Server engines that host MES application objects must have a local MES middleware host. This is required for performance on high-transaction volume systems.

Components that require an MES middleware connection

The following table lists the different components that require a connection to the MES middleware with some deployment guidelines.

Components

Comments/deployment guidelines

MES client applications (OMI, InTouch, Operator, MES Web Portal, etc.)

50 to 100 user interface (UI) clients/MES middleware host. This guideline is based on performance and isolation considerations. Applications will vary by the number of transactions they will generate per second, minute, or hour. One additional advantage of having more than one MES middleware server is not just to distribute the load but to also eliminate a single point of failure. For example, if you have 80 demanding clients, then you might consider two servers. However, if you have 60 average clients, one server would be enough. Once you reach the 100-client range, it is recommended that the MES middleware host be split between two servers.

For each client you configure the Middleware Proxy to access one or more MES middleware hosts.

These connections have a low load on the server.

MES Cloud Integration

The MES Cloud Integration Curator host service must be installed on a machine that has MES middleware. The curator host service interacts directly with the MES database once it acquires a license through the MES middleware.

Work Tasks Engine and MES model‑driven application content

If using the Work Tasks Connector for MES, one MES middleware host will be required on the node on which the Work Tasks Engine is running. Otherwise, if MES model-driven application content is using MES Web API V3, the middleware host can be located on another node.

System Platform Application Server with MES Application Objects

No more than 100–150 MES application objects per platform.

No more than 30–50 MES application objects per engine.

Local MES middleware to handle MES application object transactions.

Usually, API calls to MES middleware from the Application Server objects are not included in the calculation because the load is significantly less.

Utilization Capability Object (UCO) - The complexity of the expression evaluations and the number of raw reason codes to evaluate will affect the total number of UCOs that can run on an engine. Look for any scan overrun messages in the Logger and the average engine execution time to determine the maximum load. Since utilization events have a minimum resolution of 1 second, the engine scan time should be 1 second or greater.

Operations Capability Object (OCO) - The more functionality included in the object, the more time it will take to execute the object. Multiple job positions, many specifications, and many consumption counters will affect the number of objects hosted on an engine. Look for any scan overrun messages in the Logger and the average engine execution time to determine maximum load.

Sample Recording Object (SRO) - The number of characteristics being captured is the main determining factor for the SRO. The following configuration has been tested: 15 objects capturing data for 10 variable characteristics (each with 5 measurements) against 2 samples per minute for each entity. Look for any scan overrun messages in the Logger and the average engine execution time to determine maximum load.

Enterprise Integration, MES Middleware to run Maintenance Services

One MES middleware runs maintenance services. This includes cleanup for shifts and sessions as well as generating quality samples. For more details, see the MES Middleware and Cloud Integration User Guide.

This MES middleware also manages the creation of future Quality samples and changes in sample status based on passage of time. Quality sampling should not be used as a historian to record large volumes of data at high rates. Samples for each entity are expected to be no faster than every 10 minutes and the total rate for the MES middleware should be no more than 100 per minute.

Enterprise Integration is used to transfer data between MES and other business systems.

Even on a large or demanding interface, a separate MES middleware host would NOT be required. It is only separated to isolate database traffic when troubleshooting.

Archive, Purge, and Restore (APR)

The Database Maintenance Server application defines where the APR will run.

Usually the Archive database is on its own server and has its own dedicated MES middleware host.

These MES processes will use the MES middleware defined by the MES middleware proxy where they are running. This means all MES processes running on a computer will use the same proxy and thus are all connected to the same MES middleware.

For example, if your setup is as follows:

  • Database Server

    • MES Middleware Proxy configured to connect to the MES middleware on the Application Server

    • Enterprise Integration

  • Application Server

    • MES middleware host

Then Enterprise Integration would be using the MES middleware on the Application Server.

If you require one server for the MES clients and one server for the Application Server objects, it is a good practice to split the load and put half your MES clients and half your Application Server objects on one server and the other half on another server. This allows for:

  • Application Server redundancy

  • Isolation by process area. That is you can put all objects and MES middleware for 1 process area on 1 server.

  • Better use of the hardware.

For additional information about load balancing, see Load Balancing of the MES Middleware.

The restriction of 50 to 100 UI client MES middleware connections is based on the performance of the MES middleware. There is still capacity available on the server that can be used.

The following are operating parameters for a typical medium-size plant with:

  • 50 lines with 100 MES application objects

  • 60 Operator Clients (InTouch)

  • Enterprise Integration – small load

This plant could be configured with 2 Application Servers, each supporting 25 lines, a Production Database Server, and an MES Web Portal Server. Note that this system does not include Work Tasks. The following figure shows the architecture for this medium-size system with respect to the MES middleware.

Diagram of showing the recommended architecture of a medium size plant that includes two application servers and a web server running mes middleware.

A medium-size system has been qualified to determine the performance levels that could be achieved. For information about this system and the performance results, see Example: Performance qualification of a medium-sized MES system.

In This Topic
TitleResults for “How to create a CRG?”Also Available in