Motionwell Automation builds the machine end of the MES, ERP and SCADA question in Singapore: the controller, the panel and the interface that carries a machine’s data upward. What that looks like on delivered equipment is specific enough to describe. The cleanroom automated test equipment series runs a Siemens HMI, holds results per serial number, exports them by batch for Cp/Cpk study and offers OPC UA connectivity for real-time SPC charting on Siemens WinCC or an equivalent SCADA platform. The SCARA sensor panel assembly line carries a Mitsubishi GOT2000 panel and logs production by variant and batch to CSV for MES integration. A carton palletizing cell calls one of up to 50 stored layer patterns by barcode scan or MES command with no mechanical adjustment. An automated storage and retrieval crane is sequenced by a Siemens S7-1500 over Profinet to a fleet management server. Machines are designed, assembled and tested at our Woodlands Link facility, and the company has delivered more than 150 special purpose machines since 2014 under ISO 9001:2015 and bizSAFE Level 3.
The short answer. ERP plans and accounts for production, MES executes and records it, SCADA supervises the equipment while it runs, and underneath all three the machine’s PLC and HMI make the motion happen. The clean rule is the time constant. A PLC decides in milliseconds, SCADA refreshes in seconds, MES thinks in units and jobs, ERP thinks in shifts, days and weeks. Nothing whose time constant is a machine cycle may live above the machine, and nothing that needs to see more than one machine can live inside one. A new machine normally reports to exactly one layer above it, chosen by which question you actually have, and it publishes the same thing regardless: a typed set of states, counts and per-unit parameters with identity and a source timestamp attached.
Where we stand, said once. We do not sell an MES, an ERP, a historian or a SCADA product, so nothing here is written to move a licence. What we build is the machine and its published interface: the controller logic, the state definitions, the tag or node structure, the local buffer and the operator layer. Plant network design, server administration and the business systems above the line belong with your IT organisation and the vendors who supply them.
This page takes the decisions in the order they arrive: what each layer owns, how data moves between them, which layer a new machine should report to, what the interface looks like in practice, who owns which segment of it, what breaks when a function sits on the wrong layer, what changes when the data becomes a regulated record, and when you do not need an MES at all.
What Does Each of the Three Layers Actually Own?
Ownership is easier to settle than definitions, because every vendor defines its own product generously and the overlap in the middle is where projects get expensive. The useful question is not what a layer can do. It is what has to be true when that layer is unreachable.
| Layer | The question it answers | What it owns | Time constant | What it must never own |
|---|---|---|---|---|
| ERP | What did we promise, what did it cost, what do we have | Orders, materials, stock, costing, the planning horizon | Shifts to weeks | Anything the floor needs inside a shift |
| MES | What is being made right now, on what, and what was actually made | Work order execution, routing, genealogy, per-unit and per-batch records | Units and jobs, minutes | Machine sequencing, interlocks, cycle timing |
| SCADA | What is every machine doing, and what has it done | Supervision, alarm annunciation and aggregation, trends, historian | Seconds | Anything that must survive a server reboot |
| Machine PLC and HMI | How does this mechanism move, safely, right now | Motion, interlocks, sequence, alarm generation, the operating language at the panel | Milliseconds | Cross-machine scheduling and long retention |
Two rows deserve reading against each other. SCADA and MES both look like screens showing production, which is why they get conflated in a specification and then bought twice. The difference is what the screen is a view of. SCADA is a view of equipment, so its natural objects are tags, alarms and trends. MES is a view of work, so its natural objects are orders, units, operations and records. A plant that wants to know why line 3 stopped at 04:12 is asking a SCADA question. A plant that wants to know which lot of components went into serial number 41,207 is asking an MES question, and no amount of tag history answers it.
The bottom row is where our work sits, and it is the row most often left implicit in an integration specification. A machine is not a data source that happens to move. It is a control system with a safety case, and everything the layers above receive is a by-product of decisions taken in the controller: what counts as running, what counts as a good part, which alarm was first, when the clock says it happened. Those decisions are described in full on our HMI and SCADA integration page; what matters here is that they are made below the interface, not above it.
How Does Data Actually Move Between the Three Layers?
In two directions with different characters, and confusing them is a recurring cause of interfaces that work in a factory acceptance test and then fail in service.
Downward, the flow is instruction and it narrows at every step. ERP releases an order for a quantity of a product. MES turns that into a job on a route: this operation, on this machine, with this recipe identity and these components. The machine receives a recipe selection or a parameter set, and executes. What matters about the downward flow is that it becomes less negotiable as it descends. An order can be rescheduled; a job can be moved to another machine; a recipe loaded into a running cycle cannot be changed without deciding what the half-made batch is.
Upward, the flow is evidence and it aggregates at every step. The machine emits state, counts, alarms and per-unit parameters. SCADA annunciates and stores them. MES binds them to the work order and the unit identity, which is the step that turns a measurement into a record. ERP receives confirmations: quantity produced, material consumed, order closed.
| Direction | What crosses | What the message has to carry | What goes wrong when it does not |
|---|---|---|---|
| ERP to MES | Order, product, quantity, due date, bill of materials | A stable order identity that survives a reschedule | Two systems disagree about which order is live |
| MES to machine | Job, recipe identity and version, component lots, target quantity | The version, not only the recipe name | A machine runs a recipe nobody can name a year later |
| Machine to SCADA | State with a reason, alarms, process values, counts | A source timestamp and a device identity | Trends that measure the polling interval rather than the machine |
| Machine to MES | Completed-unit or completed-batch event with its parameters and results | Unit, batch or serial identity captured as the value was taken | A measurement that is a statistic instead of evidence |
| MES to ERP | Produced quantity, scrap, material consumption, order completion | Agreement about what counts as a good part | Stock that drifts against the floor and gets corrected by hand |
The fourth row is the one worth spending design time on, because it is cheap while the machine is being built and awkward afterwards. The delivered test equipment holds force, displacement, resistance and continuity results per serial number and exports them by batch, and the identity is captured at the moment of measurement inside the machine, not reconciled afterwards by whatever system received the file. A reject handler on a filling or packaging line should be specified the same way: every rejected container logged against its serial number, with the rejection reason and the inspection image behind the decision, which is what makes an investigation possible rather than speculative.
The downward flow has a delivered example too, and it shows how little has to cross to be useful. The carton palletizing cell stores up to 50 layer patterns and calls one by barcode scan or MES command, with no mechanical adjustment. The message is a pattern identity. Everything else, including the placement coordinates, stays inside the machine where it can be tested.
Which Layer Should a New Machine Report To?
The lowest layer that can answer the question you actually have, and normally exactly one of them. Reporting the same machine to two layers creates two versions of the truth, and after they disagree once neither is trusted.
Five questions settle it, and the first that gives a hard answer usually decides the shape.
- Does the machine’s output have to be traceable to a unit or a batch? If yes, the destination is a record layer, and the machine has to publish identity with every measurement.
- Does a work order have to reach the machine, or only leave it? A machine that receives jobs is an MES interface. A machine that only reports is a SCADA or historian interface, which is a much smaller build.
- How many machines have to be seen in one place? One machine is a panel question. Several is a supervisory question.
- Does the answer change within a shift? If it does not, the destination is probably ERP and the message set is small.
- Who administers the system on the other side? That answer usually lives outside the engineering department, and finding it late delays more of these projects than people expect.
| Your situation | Report to | The interface that fits | Why |
|---|---|---|---|
| One machine, one operator, no work order routing | Its own panel, plus a scheduled export | CSV export by batch or shift | Nothing above it has a second machine to compare against |
| Several machines, one office wanting one view | SCADA or a historian | OPC UA upward, machines stay independent | The requirement is visibility, not sequencing |
| Work orders exist, the floor still runs on a paper traveller | MES | Completed-unit event upward, recipe or job identity downward | The record is the reason for the project |
| High mix, changeover consumes the week | MES or a barcode scan, for recipe identity only | Recipe call by identity, the machine holds the parameters | The SCARA line switches more than 15 panel variants in under three minutes because the recipe layer carries the changeover |
| Regulated production, the record is required by rule | A record layer with an audit trail | Buffered event stream with identity, roles and signatures | Retention and audit trail change the build, not only the destination |
| No MES on site, ERP already holds the order | ERP, with a small confirmation set | Produced quantity, scrap and consumption | An ERP will accept confirmations and will not hold per-cycle data |
Where two rows apply, the machine has two audiences rather than two destinations. Publish once, in one structure, and let the layers above take what they need from it. A machine that formats its output differently for each consumer acquires a maintenance burden that nobody costed.
What Does the Interface Look Like in Practice?
Usually OPC UA from the controller, or a direct driver against PLC tags where the controller predates it. The machine publishes a completed-unit or completed-batch event carrying its parameters, and the layer above stamps it against the work order and the serial number. That is the shape whether the consumer is a historian, an MES or a record system, which is why we build it once and treat the consumer as a configuration rather than as an architecture.
Three things decide whether that interface survives its first year in service.
The namespace is a contract. Node names, types and units are agreed in writing before commissioning and versioned afterwards. A rename after go-live breaks every consumer without producing an error anybody sees, and a name nobody agreed to own gets discovered during commissioning by the person who has the least time to fix it.
Buffering belongs to the machine. Buffer locally with enough depth to cover a server reboot or a change window, forward when the link returns, and raise an alarm when the buffer fills rather than when it overflows. A line that halts because an IT patch window ran long gets unplugged from the record system within a month, and then you have neither the automation nor the compliance.
Somebody owns the clock and the certificates. Real-time clocks in controllers, panels and industrial PCs drift apart, and a merged event log across three devices is only defensible if they were synchronised on purpose. Store timestamps in UTC, display local time, and write the convention down. OPC UA security rests on trust between client and server, and that trust expires; an unowned renewal is a link that fails on a date nobody has in a calendar.
What the machine can offer upward is not a free choice, and this is the part of the conversation that changes when the machine is not new. Getting numbers out of equipment that was never designed to give any runs down a ladder of options, set out in full on our machine data acquisition page. Read from the MES side, that ladder is a statement about which layer can be fed at all.
Read that ladder from the top, each rung feeds a thinner interface than the one above it. Where the controller’s own tags can be read, the layer above can be given state with reason codes, counts, per-unit parameters and alarm words, and nothing is missing except what the program never computed. A protocol gateway republishing an older controller gives most of that, limited to whatever the old interface exposes rather than to what the controller holds internally. Bolt-on sensing on a machine nobody is allowed to touch gives run and stop state, a cycle count and sometimes a condition trend, and cannot say why it stopped or which product it was making. A hardwired dry contact gives running, stopped and fault.
That bottom rung is the one that ends MES conversations early, and it should. A work order execution system fed by a three-state contact can tell you that a machine was down and nothing about what to do next. That is not an argument against dry contacts, which are honest and verifiable in an afternoon. It is an argument against buying a layer that expects data the machine cannot produce.
Who Owns Which Segment of That Interface?
An interface with two owners has none, and the failure is quiet: each side builds to a reasonable reading of a document neither side wrote. Naming the segments early costs an hour.
| Segment | Owned by | What it looks like when it is unowned |
|---|---|---|
| Controller logic, state definitions, alarm generation and first-out capture | Machine builder | Two systems disagree about which alarm came first |
| The published node set: names, types, units, versioning | Machine builder, agreed with the consumer before commissioning | A rename during commissioning that breaks every report silently |
| Source timestamping and the local buffer | Machine builder | Timestamps that measure the network, and data lost during a patch window |
| Panel roles and account structure | Machine builder, from the site’s role model | One shared login, and no way to tell who changed a recipe |
| Work order model, mapping to orders and units, reports | MES or ERP vendor | A completed-unit event that arrives correctly and lands nowhere useful |
| Network segmentation, switches, servers, certificates, backup | Plant IT and OT | A boundary device that nobody has hardened, patched or renewed |
| Clock source and the timezone convention | Named once, site-wide | Audit trails that cannot be merged and are therefore indefensible |
Two segments in that table are the ones we see fall between organisations. The node set is treated as documentation rather than as a contract, so it is written after commissioning by whoever has the file open. And the clock source is treated as an IT service rather than as a design item, so it gets specified for the servers and not for the controllers, which is exactly backwards for anything timestamped at the source.
Our scope ends at the published interface on the machine, which is a real boundary rather than a polite one. We write the controller code and the panel, define the states, structure the nodes, and hand over a document saying what each one means. What the consuming system does with that is its vendor’s work, and where a plant has already standardised on a platform, our job is to deliver signals it reads rather than to argue with it.
What Breaks When a Function Sits on the Wrong Layer?
One rule settles most of it: nothing the machine needs to keep running or to stay safe may depend on a link that can be unplugged. The rest is a question of which layer has the better view.
| Function | Where it belongs | Symptom when it sits too high | Symptom when it sits too low |
|---|---|---|---|
| Interlocks, safety functions, motion, sequence | Machine | A cell that stops because a server was patched | None; this is where it belongs |
| Handshakes between neighbouring stations | Machine, station to station | A line paced by a polling loop runs at the poll rate | None; the line above should see it, not set it |
| Alarm generation and first-out capture | Machine, with annunciation above | The cause is lost under the consequences it produced | None; aggregation still happens above |
| Recipe master and version distribution | The machine holds and stamps the version it is running; the master sits above where several machines share a product | A machine cannot run while the server is down | Panel copies fork within months |
| Job dispatch and order selection | MES, or ERP where there is no MES | None; this is where it belongs | Scheduling logic buried in a machine nobody can schedule around |
| Genealogy and per-unit records | MES or a record layer | None; it needs to see more than one operation | History dies with the machine that stored it |
| Long retention, cross-machine comparison | SCADA historian or above | None; it is the only place that sees more than one machine | A dataset on a memory card until the card fills |
The recipe row is where judgement enters, and one delivered system deliberately goes the other way. On the QA laboratory automation programme, re-ordered in four consecutive years, the storage, scheduling and routing logic and the sample state machine live inside an Allen-Bradley PLC rather than in an external execution system, with every state transition timestamped at millisecond resolution against sample identity, source and destination state and station. A second software system between the work order and the gripper would add a failure mode to every sample movement. That is a defensible answer at the scope of one cell and a poor one when the same logic has to coordinate a plant, which is the whole reason the layers exist.
Independence between machines is a design choice with a cost attached, and it is usually worth paying. On the modular carton unloading station built for a consumer goods distribution centre, each station runs its own PLC for local control and exchanges data with its neighbours over OPC UA, so a station keeps working when the one beside it stops. Applied to the layers above, the same argument says a machine should degrade to running without reporting, never to reporting without running.
What Changes When the Data Becomes a Regulated Record?
The destination stops being a management choice and becomes a requirement, and three things change in the build.
The rule never applies by itself. It applies because a predicate rule requires the record and you have chosen to keep it electronically: 21 CFR 211.188 for batch production and control records on the drug side, and on the device side 21 CFR 820, which since 2 February 2026 has been the Quality Management System Regulation incorporating ISO 13485:2016 by reference, where the obligation survives in clause 7.5.1. Once that is true, 21 CFR Part 11 asks for a validated system, access limited to authorised individuals, authority checks on who may sign or alter a record, and a secure computer-generated time-stamped audit trail the operator cannot switch off.
The layer that receives the machine’s data acquires an audit trail, a retention period and an account model. That is a different object from a historian, even where the same values flow into it. Motionwell delivered such a system for a medical device OEM as a standalone order rather than as part of a machine purchase, accepted in August 2026 and going in one site at a time, because every site has a different mix of machine generations and validation repeats per site anyway.
Three data paths reach that record and each needs a different decision. Operator entries come from the station and carry the authority and signature rules. Machine-generated parameters come from the controller: on a multi-station rotary assembly machine, for example, we would put a load cell on every press station and a pass or fail result on the vision station, and log both against the unit identity at the moment they were taken rather than reconcile them afterwards. The design side of that is set out in how we design multi-station rotary assembly machines. Instrument and reader data comes from the measurement devices, and the record should carry which device produced the reading and whether it was in calibration at the time. The clause-by-clause equipment view is on our 21 CFR Part 11 and electronic records page.
When Do You Not Need an MES at All?
We build the machine end of these interfaces, so read this as the argument against buying more layer than the question needs.
One machine, one operator, no work order routing. A panel and a scheduled export answer it. A layer above one machine is a second thing to patch, back up, qualify and eventually migrate.
You do not yet know which machine is the constraint. Instrumenting a station that is not limiting output produces a number and no shipments. Dry contacts across several machines are cheap, verifiable and enough to rank them against each other, and that ranking is what tells you where a richer interface is worth buying.
The controller is being replaced within the year. A parallel interface bolted onto an obsolete controller buys a few months of data at full price and is then discarded. If a migration is already on the plan, the tag list and the node set belong inside that scope, where the alarm structure is being rebuilt anyway. That is set out on our PLC migration and upgrade page.
The problem is the alarm structure rather than the layer above it. An execution system fed by unmapped alarms produces a downtime report whose largest category is Other. Mapping alarm bits to loss categories at the controller costs almost nothing during a rebuild, and what the resulting numbers can and cannot tell you is worked through in our explainer on OEE.
Nobody owns the output. An interface with no named owner and no standing meeting produces a database. It is a familiar reason these systems go quiet in the second year, and no amount of hardware quality prevents it.
Conclusion
The three-layer picture is easier to use as a set of ownership questions than as an architecture diagram. Which decisions change within a machine cycle, and therefore cannot leave the machine. Which questions need to see more than one machine, and therefore cannot be answered inside one. Which records have to outlive the equipment that produced them. Answer those three and the layer a new machine reports to is usually already decided, along with how much of the interface is our work and how much is somebody else’s.
What we can commit to on the machine side is narrow and testable: states defined so they mean the same thing on Tuesday and Friday, identity captured at the moment of measurement, timestamps applied at the source, a local buffer sized against a realistic outage, and a node set documented as a contract rather than as a drawing. Everything above that line reads better when those five are true, whichever product is sitting there.