What is a Manufacturing Execution System (MES)? Functions, MES vs. ERP, and Interfaces

MES stands for manufacturing execution system. In projects, people usually just say “MES”, and that is the term used here.

An MES typically covers six areas: detailed scheduling of orders across equipment and shifts, production and machine data acquisition, quality assurance with inspection plans and hold decisions, traceability across batches and serial numbers, maintenance with maintenance schedules, and labor time tracking at the line. Not every plant needs all six, and products set different priorities.

What an MES does and how to choose one is covered in detail in What is an MES? on manubes. This article is about the step after that: how it exchanges data with the rest of the company.

In ISA-95, the MES sits on Level 3, manufacturing operations management; in the German automation pyramid, this is the operations level. Above it, both models place the ERP system (Level 4, or the enterprise level). Below it, the two models count differently: the pyramid has a supervisory level, a control level and a field level, ISA-95 has Levels 2 to 0.

This order describes responsibilities. The data paths no longer follow it all the way: where there is no MES, the ERP system reads values one level down, in practice often at the pyramid’s supervisory level. When a plant can do without an MES is covered below under “Does every plant need an MES?”.

More on this: What is ISA-95?

No, but SAP can do parts of the job.

At its core, SAP is an ERP system. It plans against the market: orders, delivery dates, materials, capacities, costs. For the shop floor there are extensions and separate products that take on MES tasks. A standard SAP system without them is not an MES, though, and above all it lacks the cadence.

An ERP system works in orders and days, an MES in operations and minutes.

In practice you therefore find three setups: SAP plans and an MES executes; SAP does both with add-on modules; or there is no MES and SAP is fed directly from production. Which one fits depends on who in the company owns the production schedule.

Both plan, but over different time frames and at a different resolution.

Confirmations flow the other way: the MES reports to the ERP system what was actually produced. In many plants, data gets entered twice at this confirmation, once at the machine and once by hand in the ERP system. Where that happens, the problem often lies in the interface in between rather than in the MES itself.

No. Whether a plant needs one is worth settling before the selection starts.

For this level, the ISA-95 standard describes functions: breaking down orders, tracking batches, sending confirmations. It does not prescribe a product that does all of it.

Whether an off-the-shelf MES fits depends on how much of it a plant really needs. If it brings features that are never used and demands processes that do not fit the company in return, the effort does not end with the rollout; it continues with every adaptation.

Three routes are common at this level:

The middle route has changed the most. These functions used to require developers. Today, process and operations teams can build them themselves on a no-code platform with drag and drop. At inray, that platform is manubes: dashboards, workflows and reporting are put together by the people who know the process, without a detour through IT.

On the third route, the middleware takes over the data path that the MES would otherwise serve. It reads the values at the machine, converts them into the form the ERP system expects and reports back. MES functions such as detailed scheduling, traceability or quality decisions are not part of it. What this route means for resilience when something fails is covered below under “A message can wait, a question cannot”.

The three routes are not mutually exclusive. A plant can run an MES for production and build its own maintenance application. Which of these functions a plant actually needs determines the setup. The trade-off in detail is covered in MES: Make or Buy?

Data flows between the ERP system and production in two directions. Orders and master data, such as material masters and formulations, go down. Confirmations with produced quantities, material consumption and scrap come back up.

Regardless of the ERP product, four channels are common: web services via REST or SOAP; databases and staging tables that both sides access via SQL or ODBC; files, for example in CSV format, that one system writes and another reads in; and the ERP vendor’s own interfaces.

Taking SAP, a common ERP system in manufacturing, as an example, three methods are typical. They differ mainly in their timing behavior.

IDoc or RFC: when to use which?

IDoc is asynchronous. SAP places the message, a receiver picks it up, and processing reports back later with a status code. That is the route that fits production orders and quantity confirmations: the sender does not have to wait, and if the receiver is briefly unavailable, the message stays in the queue. What this secures is delivery, not processing.

A synchronous RFC call (sRFC) waits for the response. The call goes out, the response comes back, and only then does the caller continue. That fits when information is needed immediately, such as a material check at the line. It does not fit bulk data, because every delay on one side blocks the other. RFC also comes in asynchronous and transactional variants; the IDocs themselves are handed over via transactional RFC.

Feedback belongs in both directions. A transfer that fails without a message goes unnoticed longer than one that aborts with an error. A clean setup therefore reports whether the handoff worked, with three distinct states: successful, aborted and failed. An abort is not an error but an orderly decision, for example when a query returns no data. If the two are lumped together, troubleshooting later starts in the wrong place.

More on this: SAP connection in industrial production · SAP interfaces overview

The typical failures at this boundary depend less on the product used than on how the connection works: whether it transfers asynchronously or synchronously, where it holds messages, and with which rights it accesses the ERP system. The examples come from the SAP connection; with other ERP systems, the same patterns appear under different object names. The OPC Router has its own plug-ins for the channels listed above: REST, SOAP web services, ODBC and databases such as SQL Server or Oracle, plus file and CSV objects. The SAP connection is a separate plug-in and requires a license. The setup details are in the checklist at the end of this section.

An acknowledgment confirms delivery, not processing

When SAP sends an IDoc to a connected system, the triggering call is acknowledged immediately, before processing has even started. In the ERP system, the message then counts as delivered. Whether it was also processed is only visible there if a second, separate confirmation has been set up.

The cause: Delivery and processing are two separate operations, and only the first is covered by the protocol. A resend after a restart is therefore based on which messages are not acknowledged, not on which ones were not processed.

In operation: An order arrives twice in the receiving system, always after a restart or a connection loss on the return path. Or the reverse: the message shows as sent, but nothing ever arrived in production.

On your side: Whether a repeated message posts a second time is decided by processing in the receiving system. A message that arrives again must be recognizable there as a repeat, through a business key and a duplicate check. And a status that is reported back has to be evaluated on the sending side.

In the OPC Router: It can write the processing result back to SAP as a status record of its own, over a separate RFC connection rather than over the triggering call. The resend at startup then depends on this acknowledgment rather than on delivery. When an IDoc goes to SAP, SAP keeps the processing status itself, and the OPC Router can query it.

A message can wait, a question cannot

Holding data and sending it later is considered the answer to “what if the connection drops?” Where the connection also sends queries, it covers only part of the problem.

The cause: A buffer moves an operation in time. That works for a message that only has to arrive, but not for a question whose answer is needed within the same flow: the answer would arrive after the decision. An ERP connection that both reports and queries therefore splits into two halves. Confirming produced quantities can wait; a material check at the line cannot. The two halves need different failure strategies, so it pays to separate them early when planning an integration.

On your side: First, every record needs its own timestamp from the source. If a record is delivered late while new ones keep flowing, it does not necessarily arrive in the order it was captured, and no software can invent that timestamp after the fact. Second, the split: which flow may wait. Third, sizing: the longest planned maintenance window of the target system should be covered, by retention time and storage capacity for Store & Forward and by the number of retries and the retry delay for the transfer status trigger (see the checklist); only your own plant knows how long that window is. Fourth, what applies in the synchronous half when no answer comes: a substitute value, a stop or a hold. That is for production to decide.

In the OPC Router: In the reporting half, the Store & Forward add-on buffers the data. As a rule, it can be used on any transfer object at the end of a flow, including the SAP transfer objects; whether it applies to a specific transfer object is shown by the Store & Forward icon once the feature is enabled. The add-on’s product page limits it to channels “which do not expect any responses to be processed”. That rules out, for example, an RFC call whose return values the flow evaluates: it belongs to the synchronous half.

A call can also be retried without Store & Forward, with a Try/Catch transfer object: one to four additional attempts, with a constant, linearly or exponentially increasing wait time. This bridges short interruptions: the flow waits at the object until all attempts are complete, and the flow timeout caps the sum of attempts and wait times. The manual warns to use retry only for flows that can safely run more than once; otherwise there is a risk of duplicate write operations. For the synchronous half, which has no holding area, this is also the defined behavior on failure: if the call finally fails, the flow continues with a default value per output, and two dedicated outputs signal to the following steps that it was a substitute.

A green connection test proves little

If the technical user is missing authorizations, it is not the connection that fails, but access to individual functions and tables. This shows up in live operation, on a specific transaction, often weeks after commissioning.

The cause: Authorizations are checked at the point of access, not at logon: S_RFC per function group, the authorizations for tables and postings only inside the function that is called. A connection test therefore only checks the logon.

In operation: The connection runs in the test system but not in production, because the role there is more restrictive. The error appears with the first order that needs a function nobody has used before.

On your side: This is where software takes on the least. The role for the technical user is built in the SAP system, and it has to be defined identically in test and production. Custom function modules, the SAP libraries, secure communication via SNC and open ports come on top (see the checklist).

In the OPC Router: The check itself stays in the SAP system. The OPC Router takes the searching off your hands: the required authorization objects are listed by name in the manual, so they can be requested before the project instead of being added in operation. One step checks more than the connection test: starting every reading flow manually once after publishing, which needs no trigger, exercises its function group before the first order needs it. Posting flows really post when started this way; for them, a reading call to the same function group checks S_RFC, but not the authorizations for the posting itself.

The question already belongs in the selection phase. Production does not stop because a server restarts, and the data from those minutes must not be missing.

A common approach is to buffer messages. In the OPC Router, on the SAP connection, that can be the Store & Forward add-on, a database table worked through by the transfer status trigger (retry can be enabled) or, when sending IDocs, the IDoc queue for IDocs that cannot be sent (see the checklist above). A manufacturer of outdoor power equipment goes one step further and connects each assembly line through the OPC Router to its own local SQL Server database. The user report from April 2019 counts 16 installations in Germany alone, plus the plants in the USA and China. All information on parts, bills of materials and production periods is available there well before the order starts. The report spells out the consequence: if the connection fails, the current order and the next one can still be produced.

The second question: which system is the master? If ERP and MES both keep the same order status, it has to be settled which one counts. That decision lies with the company and belongs before the first line of configuration.

The following figures come from published user reports and describe the setup at the time of publication, not today.

A manufacturer of self-adhesive materials links 14 machines over 35 connections directly between PLCs and SAP ERP, according to its user report on opc-router.com (undated; its company figures refer to the 2017 financial year). Posting times are below 15 milliseconds at around 15,000 data telegrams per day. The ERP system sends formulation and production speed, and the machines report defects and quality data back. Feedback is part of the design: SAP communication is additionally safeguarded by an RFC handshake, and the confirmation of a completed transfer makes an interruption visible. There is no MES in between.

A packaging manufacturer runs around 500 machines in eleven plants, according to a German-language user report on kepware-opcserver.de from April 2020. An OPC server collects the data at the machines, an OPC Router at headquarters passes it on, and the MES runs on its own SAP database. Collecting the data and making it available takes one to two seconds, and the data volume is around 1.2 gigabytes per day. Where a production data acquisition system used to evaluate the values overnight, the report describes a query every second. Machine connectivity, the integration layer and the MES are three separate systems in this setup.

A manufacturer of polyethylene pipes in Italy, according to the undated international use cases on opc-router.com, uses the OPC Router as the layer between SAP S/4HANA and an MES, over SAP IDoc, SAP RFC and MS SQL Server. Several transactions are configured in both directions, from item master data through raw material receipt and production orders to the confirmation of pieces produced, material consumption and scrap in kilograms.

A long-established specialty chemicals company has automated this confirmation at its filling line. Before, an employee reported the number of containers into the system by hand and applied the label manually. After the changeover, the OPC Router reads the number and the process order number from the PLC and posts the quantity to SAP via RFC; SAP then creates the label, which is applied automatically. The complete message goes back to the PLC and additionally into an SQL database for traceability. As described, this is a case from the synchronous half: the label is created only after the posting in SAP. The line went live on May 1, 2019, after a test phase of around four months.

A manufacturer of wax technologies shows what a connection looks like when it starts as a programming project. According to the use case on opc-router.com about system integrator ZewaTec (page as of January 2025), the first solution connected two Siemens systems and a Yokogawa control system to SAP through a combination of many partial solutions and took around 20,000 lines of code. The page names two weaknesses: the cost of the many software licenses and a data transfer that stalled whenever one of the partial solutions stopped working. The OPC Router then replaced over 90 percent of that programming with graphical connections.