An MES Is the System of Record for What Happened on the Floor

What an MES does: dispatch, execution capture, booking and traceability

Start with dispatch, which is often mistaken for printing. Planning hands down an order and a routing; the MES decides which resource runs which operation, in what order it is released, and whether it may start at all. The plant-wide sequence computed days out against tooling, labour and changeover families is a different job, and belongs to advanced planning and scheduling, whether that ships as an MES module or a separate system. An infinite-capacity plan dispatched straight to the floor is fiction by mid-shift.

Release has preconditions, and the question about each is whether the system knows it or is only told it. That the previous operation was signed off and the operator's certification is current, the MES knows from its own records. That the right lot is staged needs a scan, or an interface to whichever system holds the reservation. That the correct tool is mounted needs tool management, a chip in the holder or a presetter interface — or an operator confirming it, which makes the check exactly as good as the confirmation. A precondition with a source behind it is a control; one backed by a tick box is a record with a timestamp.

Then execution: setup and run kept apart from labour time, good parts, scrap with a cause, rework routed somewhere, stops with a reason and a duration. Quality belongs in the same stream, defined against the operation and performed by the person doing it, with a result that can stop the part moving on. Final inspection finds the same defect four operations later, after you have paid for all four.

Booking closes the loop with the business systems: material posted against the order, labour against the operation, and those two postings become the actual cost and the actual stock. Traceability sits underneath all of it, and OEE falls out of it, being arithmetic over events execution already produced rather than a separate system.

What belongs in the MES, and what belongs to ERP, SCADA or the PLC

ISA-95, published internationally as IEC 62264, is useful here not for its layer diagram but for its object models — production schedule, production performance, material lot, personnel, equipment — because those are what cross between the floor and the business, which makes them a checklist for an interface specification.

The hardest line is the lowest one. Safety functions — guard interlocks, light curtains, two-hand controls, area scanners — belong in a hardwired safety circuit or a safety controller, at a performance level or SIL established by risk assessment under ISO 13849-1 or IEC 62061. No amount of network determinism makes software above that layer a legal place for one. Process interlocks are the case worth arguing about: do not start without the right tool, do not run outside the parameter window. There the PLC owns the physical prevention, since a rule that must fire in tens of milliseconds cannot live behind a database and a network switch, and the MES owns the consequence: it refuses to open the next operation and holds the lot.

Above that line the allocation is familiar: visualisation, alarming and supervisory setpoints to SCADA; order identity, routing, genealogy, quality disposition and labour to the MES; demand, procurement, costing and the customer commitment to the ERP. Two questions settle a borderline case: how fast must the decision be, and will anyone need to prove it happened two years from now.

What real time actually means at the machine interface

Real time here is not control-loop determinism. It means the record lands close enough to the event that the person who caused it is still standing there — a read cadence of a second or less, where how you read matters more than how fast.

Read accumulating counters and take deltas rather than counting edges. A pulse shorter than your sampling interval is invisible to a polled read, and a subscription only rescues you if the queue depth and sampling rate were set for it, which by default they are not: a monitored item with a queue of one keeps the newest transition and discards the rest. A counter that only climbs is immune to that and costs you nothing but resolution. PLC counters are often sixteen-bit words that wrap, so rollover has to be handled deliberately and the value re-anchored whenever the machine is power-cycled or reset.

Machine state is almost never one bit. A single running signal is usually the drive enable, which stays true while the spindle idles waiting for an operator; usable detection combines cycle-active, drive-enabled and whether the counter moved inside a window. That window sets the detection threshold: stops shorter than it are invisible as downtime and reappear, unexplained, as performance loss. One clock has to stamp the events, and the edge has to buffer, so a switch reboot leaves a gap rather than an hour of phantom downtime.

Downtime reason codes: what a machine signal cannot tell you

The interface knows the machine stopped and for how long. It does not know why, or that the part just counted will be scrapped at the next station, or that the operator was waiting for a crane rather than for material.

A person fills that gap, and the design of that moment decides everything above it. Reason codes are the usual instrument and the usual failure. Offer too many and the operator picks the first plausible entry every time, at which point the order of the list writes your Pareto chart. Offer too few and everything becomes Other. Classification has to happen inside the shift while the evidence is there, and something has to come back to the operator in return.

The paperless shop floor and the electronic batch record

Paperless does not mean the same forms as PDFs on a screen. It means the document at the station is the effective revision for that order, selected by the system, so the only revision the station can be served is the current one — and that the record is created by doing the work rather than transcribed afterwards, which is where contemporaneity, and therefore credibility, is lost. What no document system controls is paper. A drawing printed last Tuesday and kept in a drawer is uncontrolled by definition, and the drawer loses only if the system is faster to consult.

In regulated production that record is the electronic batch record, the product's legal history. The regulatory frame — the FDA's 21 CFR Part 11 on electronic records and signatures, and Annex 11 of EU GMP — turns ordinary software concerns into design requirements: an audit trail that cannot be edited, signatures with an explicit meaning, entries attributable to a named person and recorded at the time. Review by exception, where the real saving lives, only works if the system enforced limits at entry, because only then is an unflagged batch unremarkable.

Traceability and genealogy as a design requirement, not a feature

Genealogy runs in two directions and both have to work: backward, from a finished unit to every component lot, machine, tool, operator, parameter and check that contributed to it, and forward, from a suspect incoming lot to every unit it entered and every customer those units shipped to. The forward direction is the one exercised on the afternoon a supplier calls, and it is usually the weaker.

Granularity is the design decision, and it is fixed by what you capture at the moment of consumption. Serial per unit, lot per pallet, batch per shift, or a time window: each sets a floor on how small a recall can be, because the cost of containment is the size of the set you cannot rule out. Moving from shift-level to pallet-level identity is not a reporting change, it is a change to what the operator scans.

A merge point starts a transition period rather than making a clean cut. Top a silo up mid-run and what discharges afterwards is a blend; how long the old lot keeps appearing depends on vessel volume, the heel already in it, throughput and flow regime, since in funnel flow the old material bleeds down the walls for a very long time. So record the top-up with its lot, tag everything from that event until the old lot is provably exhausted with both lots, and write the exhaustion assumption down. A mixer is not this problem at all: it is a batch with several input lots and a many-to-one genealogy, and belongs in the model as a batch with a multi-lot input list. None of this can be retrofitted to shipped product, so test it before go-live: pull a unit off the dock and demand its full backward genealogy within the hour.

How to measure OEE honestly, and what makes an OEE number a lie

Overall equipment effectiveness is availability multiplied by performance multiplied by quality, each of the three has a standard way of being inflated, and the definition and time base belong in writing before the first number is shown.

The time base is the largest lever. OEE is conventionally measured against planned production time, so every hour you move out of planned production time — declaring it schedule loss rather than downtime — leaves the denominator, while hours you declare unplanned stay in it and are exactly what drags availability down. Rule trials and unstaffed shifts outside the base and the number turns comfortable while the asset idles most of the week. Changeovers are not a grey area at all: under the six big losses, setup and adjustment sits inside planned production time and is meant to cost you availability, which makes excluding it the commonest way an OEE number is cooked. Total effective equipment performance (TEEP), measured against calendar time, belongs next to it: the gap is capacity you own and do not use.

Performance is distorted by the ideal cycle time. The classic definition, and ISO 22400, take it from the theoretical or design cycle; most plants take it from the routing, where a standard set years ago for costing has allowances baked in. If the standard says fifty-five seconds and the machine's demonstrated best is forty, reported performance runs about thirty-seven percent high — and since most systems clamp performance at one hundred percent, what reaches the screen is a clamped error rather than a good result. Pull the fastest sustained cycle out of the event data and compare it with the routing standard before publishing a performance number.

Quality is corrupted by counting rework as good at the operation that produced it, when first-pass yield should show the miss. Availability is corrupted by the detection threshold above, and by downtime that is classified, but mostly as Other.

Two aggregation mistakes remain. Averaging OEE across machines mixes a constrained asset with one idle by design, so the plant number moves for reasons nobody can act on. And raising OEE on a non-constraint that already has protective capacity buys work in progress in front of the bottleneck rather than output — a rule with three common exceptions: a non-constraint short of protective capacity starves the constraint, which is lost output and not WIP; the bottleneck moves with product mix, so this month's non-constraint is next quarter's constraint; and a shared monument, heat treat or paint or the one fixture, is a constraint intermittently. Measure availability everywhere, chase OEE only where the loss converts into throughput, and re-identify the constraint when the mix changes.

What MES to ERP integration really involves

The connector is the small part. The work is deciding ownership field by field and writing it down. Material master, bill of materials, routing, work centre, customer order, work order: for each, one system is authoritative, the other a consumer, with defined behaviour when they disagree. Projects that skip this discover it in the first month, when someone edits a BOM in the system that does not own it.

Confirmation granularity is next. Per operation, per order, per hour or per part, you are trading ERP transaction volume against how stale the stock position may be. Backflush against scanned consumption is the same trade in material form: backflush posts the BOM quantity on confirmation, fast and wrong by your yield variation plus every substitution and unrecorded scrap nobody posted, while scanned issue posts what was physically taken. Scan the traceable and expensive materials, backflush the fasteners.

Then the unglamorous engineering. Every message needs an idempotency key, because interfaces retry and a double-posted goods receipt surfaces in a stock count weeks later. Someone must be able to see the failed-message queue and reprocess an item without a developer, and units of measure need explicit conversions and agreed rounding. The interface also needs a named owner on both sides, because an unowned integration degrades silently: a field is added, a mapping stops matching, errors pile up in a queue nobody reads.

Why MES implementations fail, and what predicts it

Master data is the most common cause and the least discussed. Routings describing a sequence nobody has run in years, work centres modelled at the wrong granularity, standard times never remeasured, materials with three spellings. The MES does not create these problems, it makes them visible on day one, at which point it is blamed for the mess it revealed. Measure a real run and a real changeover before go-live, and expect to rewrite routings.

Operator adoption is the second, for the reasons the entry design above covers; the answer is to time the confirmation steps yourself, during a real changeover, with the operator who will perform them. The third is an interface nobody owns. The fourth is scope that models the exception first, months on a rare split lot while the standard flow is unfinished. The fifth is going live on the constraint in the busiest quarter. The last is definitional: two systems report different numbers for the same shift because nobody agreed whether planned downtime counts, and the meeting becomes an argument about the number instead of the loss behind it.

How to run an MES evaluation that tells you something

A scripted demonstration shows the happy path, which every MES software package handles. Evaluation means forcing the ugly paths into view, with your own data. Bring four cases: an order that changes machine halfway through; an operation started on one shift and finished on the next by a different person; a lot split across two orders; and a retrospective correction, where someone picked the wrong stop reason two hours ago and you want to know who may fix it, what the audit trail shows, and whether the correction reaches numbers already reported.

Ask to see genealogy run on their data, then what it would take to run it on yours. Ask what the machine interface does when a PLC is power-cycled mid-order. Ask to speak to the engineer who would do your integration rather than the account team. On a reference visit, spend the time with an operator and ask what they work around. Commercially: what a second plant costs, what an upgrade costs, what the API gives you — the unusual pieces of your process get built on it rather than bought — and whether you can export your own raw event data in a usable form. That last one is the real test of whether the record is yours.

Where the Meta Smart Factory MES module fits

Meta Smart Factory's MES module covers the ground above: dispatch and release with preconditions, execution capture at the station, downtime and scrap with reasons, labour and material booking, quality checks bound to the operation, genealogy, and OEE derived from the same event stream rather than a parallel one.

On the machine side it reads Siemens over S7comm, Rockwell over AB-ETH, Logix and DF1, Schneider over UMAS, Beckhoff over ADS, Mitsubishi over MC Protocol and Omron over FINS, each natively, and speaks OPC UA, Modbus TCP and RTU, EtherNet/IP and MQTT for the rest, including an existing OPC UA or DA server where nobody wants another device on the network. Machines with no controller worth reading get retrofit I/O modules wired to the discrete signals that already exist — a run contact, a cycle output, an alarm relay — which give state and part count at the resolution of that wiring and, for the reasons above, never a reason for a stop.

It shares a data model with the Quality, Maintenance, WMS and Computer Vision modules and with the ERP integration layer. Finite-capacity sequencing lives in the APS module, on the boundary described above rather than inside execution, and the MRP run is there for plants whose ERP does not do one.

None of that removes the parts that are actually hard, and this page has been mostly about those: agreeing what the numbers mean, fixing routings that were never right, choosing a traceability granularity you can live with, and designing an entry step an operator will perform without being asked twice.