Definition
MES (Manufacturing Execution System) connects ERP and the production site, achieving scheduling, process management, equipment data collection, quality traceability, OEE analysis, and more. Industrial gateways and edge gateways can report data from PLC, robots, and instruments to MES via OPC UA, Modbus, and other protocols.
Core Functions
MES covers production scheduling, work order dispatching, equipment data collection, process parameter monitoring, quality inspection and traceability, OEE calculation, material traceability, exception management, report analysis, and more. Equipment data collection is the foundation of MES, acquiring running status, output, faults, process parameters, and other data from PLC, robots, CNC machines, and instruments through industrial gateways, OPC UA, Modbus, EtherNet/IP, and other protocols.
Data Acquisition
Industrial gateways and edge gateways are deployed in workshops, connecting PLC, robot controllers, CNC systems, barcode scanners, etc., and reporting data to MES or middleware via OPC UA, Modbus TCP, MQTT, and other protocols. They support offline caching, data cleaning, and protocol conversion. MES interfaces with ERP to achieve a closed loop between planning and execution, and collaborates with SCADA and DCS to integrate monitoring and production management.
IIoT integration
Under the IIoT architecture, MES, as the production management layer, receives data from edge gateways and cloud platforms, supporting digital twins, predictive maintenance, and flexible scheduling. The Device Management Platform (DMP) can provide device connectivity and remote operation and maintenance, integrating with MES production data to achieve full lifecycle management.
Aligning Order State with Machine Takt
The execution layer has to absorb the planning grain
A manufacturing execution system receives the orders and materials released by planning, and returns what actually happened at each operation. Planning usually states quantity by day or by batch. The shop floor happens in takt, changeovers, and stops. The execution layer has to split the batch down to station, shift, and machine, or a returned "quantity complete" cannot be tied to a particular machine tool or a particular changeover. What it stores is not a bare telemetry curve. It is an event carrying an order number, an operation number, and an operator.
Machine data is only the raw material of those events. Running, idle, fault, production count, and process window have to become states the execution layer understands, then be bound to the order. Dumping registers into a database can draw a curve on the board and still cannot answer which operation produced this bad batch. If quality records, barcodes, and machine state each use their own key, tracing after the fact is a manual time match.
Collection points have to be bound to the operation
The condition for use is a stable identity on the floor: at least one of machine, station, order, and batch must survive a shift change. A point a gateway reads from the controller needs to be labeled in advance with its operation, and with whether a rising count edge means one piece or one box. Theoretical takt has to come from the process, not from yesterday's average, or a performance comparison has no baseline. When the network drops, the execution layer or an edge buffer should keep recording events on the local clock and merge them by time after recovery, rather than overwriting the whole stop with the latest value.
It does not replace interlocks inside the device, and it does not replace the master's regulation of a process loop. The controller still owns a safe stop. The execution layer explains what that stop does to the order. If the line runs different control networks at once, such as EtherNet/IP and Profibus, the execution layer should see operation events whose timestamps already agree, not two sets of raw frames that are not on the same clock.
Clocks and state machines that disagree
A common error is to treat the machine's "automatic run" bit as available time. Automatic run can include spinning empty, waiting for material, and a blocked discharge. Without a separate reason code, available time is overstated and the bottleneck looks like a quality problem. Another error is an unhandled counter rollover. Night-shift output suddenly becomes negative or astronomical, and the day's good-piece rate is distorted with it.
The clock is the third trap. If the controller, the scanner, and the execution host differ by a few minutes, a material batch is booked to the previous shift. If a manually entered completion quantity is allowed to overwrite the automatic count, an audit cannot tell which figure was real on the floor. Before go-live, fix the state definitions, the count multiplier, and the time source, and balance the books against one real shift of changeovers, faults, and rework before opening the data to planning.
Rework and splitting a batch disturb orders that are already closed. If the system cannot send a defect found downstream back to the earlier operation, the loss stays on the station that discovered it, and the station that caused it keeps a perfect score. Define the window for writing back, who may write back, and whether the shift result is recalculated afterward. Do not correct history by deleting records. Without that write-back rule, the execution layer and the shift crew each keep their own book, and the books do not match at handover.