By the end of this chapter you can

• Say in one sentence what an MES executes, enforces and records.
• Place the MES among the ISA-95 levels and name the standards the module follows.
• Sort the eleven MESA functions into those this module builds and those other modules own.

Execute, enforce, record

An MES defines how products are made, dispatches orders to work centres, guides operators step by step, checks materials and qualifications, collects data from machines and people, builds the genealogy of every lot, captures downtime and OEE, and reports performance back to the ERP. Three verbs cover it: execute the work, enforce the rules while it is done, and record what happened in a form nobody can quietly change.

Tools in this class include Rockwell Plex and FactoryTalk ProductionCentre, Siemens Opcenter Execution, Critical Manufacturing, AVEVA MES, Dassault DELMIA Apriso, Parsec TrakSYS, Tulip and Sepasoft on Ignition. This module is the capstone of the library: the platform's direction is that the MES hub emerges from the other modules (scheduling, maintenance, documents, training, quality), and this module ties them together on the one shared spine.

Where it sits: ISA-95

ISA-95, published internationally as IEC 62264, divides a manufacturer into levels ^[1][2]. The business systems (ERP) are at Level 4, and the machines and their controls are below. Manufacturing operations management, the MES, sits at Level 3, between the two. That position explains what an MES does: it receives a schedule from above, turns it into work on the floor, and sends what was done back up.

The standard has five parts. Parts 1 and 2 give the object models and terminology; Part 3 gives the Level 3 activity model, which is four categories of operation (production, maintenance, quality and inventory) crossed with eight activities; Part 4 describes the information that flows between those activities; and Part 5 defines the business-to-manufacturing (B2M) transactions between the ERP and the MES ^[3]. The module uses Parts 1 and 2 to name its equipment and material, and Part 5 for the ERP exchange in chapter 4.

The eleven functions

The MESA model lists eleven functions an MES covers: resource allocation, scheduling, dispatching, document control, data collection, labour, quality, process management, maintenance, genealogy and performance analysis ^[1]. It is a checklist, not a design: use it to find out which of the eleven your plant does today, with what, and who does them.

What is in and out of scope

Twelve capabilities, in three tiers

The specification groups the module's capabilities by tier. MVP is what every plant needs first; STD is what a standard MES also does; BIC is best in class.

Exercise · Place your plant on the models15 minutes

You need: Your Session 1 notes (docs/mes-inventory.md if you have started it), one routing from your plant, and a pen

Use one real line. Work on paper first; leave operator and customer names out of anything you save.

1. 1. Draw your plant's systems as five stacked boxes, Level 4 to Level 0, and write the name of each tool or sheet in the level where it really works.
2. 2. Mark the one place that decides what a work centre makes next and records what it made. If it is a person, a whiteboard or a spreadsheet, write that. That place is your Level 3 today.
3. 3. Write the eleven MESA functions down the side of a page. Beside each, write who does it today (a tool, a person, paper) and how.
4. 4. Colour the functions this module will take over (resource allocation, dispatching, data collection, labour, process management, genealogy, performance analysis) and mark the four that stay with M03, M05, M06 and M08 or M09.
5. 5. Pick the three functions that cost you the most time or errors today and write one sentence for each saying what goes wrong.
6. 6. Write down one thing on your line that must never be controlled from software you are building, and who owns it.

Outcome: A one-page placement of your plant on ISA-95 and MESA-11, with the three painful functions named and the control boundary written down.

References

1. SYMESTIC: the 11 core MES functions (MESA-11) and the ISA-95 Part 3 matrix. https://www.symestic.com/en-us/what-is/mesa-11
2. Siemens: ISA-95 framework and layers. https://www.siemens.com/en-us/technology/isa-95-framework-layers/
3. Automation World: the five parts of ISA-95. https://www.automationworld.com/products/software/article/13309288/the-five-parts-of-isa-95
4. ISA: ISA-95 series of standards (enterprise-control system integration). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard

By the end of this chapter you can

• Name the fifteen mes_ tables and sort them into definitions, order and run, and records.
• Explain how a product definition is approved, becomes effective and is superseded without being edited.
• Say why equipment, items and people are keys to the spine and why measured values are typed columns.

Three groups of tables

Every table starts with the standard columns every platform table has: id, tenant_id, created_at, created_by, updated_at, updated_by, row_version, archived_at and ext. The module has no item master, machine list, lot table or people table of its own. Its keys go to core_item, core_equipment, core_lot, core_person and core_shift_instance, and to core_e_signature, core_uom, core_data_tag, core_reason_code, core_attachment, core_site and core_serial_unit. Its own tables share the prefix mes_.

The tables below give every column the module adds to the standard ones. Types are as in the specification: text, int, num (a decimal number), qty (a quantity, kept with its unit in a uom_id column), bool, ts (a timestamp with time zone), uuid and json (jsonb in Postgres). An arrow means a foreign key to that table, req means required (not null), and a list after a colon is the allowed values. This is what your agent builds from in Session 2.

Definitions: how a product is made

Order and run: who makes what, where

Records: what happened

Two links are soft on purpose. instruction_doc_ref, required_skill_ref and deviation_ref are plain uuid columns with no foreign key, because the modules that own those tables (M06, M07 and M08) may not be installed yet; the module library's cross-module file adds the keys once both sides exist.

Definitions are versioned, never edited

A routing is a promise about how a product is made, so a change to it is a new revision, not an edit. A definition is a draft while it is being written, becomes approved only with an approval signature, becomes effective on a date (and the earlier effective revision of the same item becomes superseded on that date), and is never changed after that. An order records the definition it was made against, so a year later you can say exactly how a lot was made.

ISA-88 names four recipe types: general, site, master and control. For a batch process a mes_product_definition is the master recipe, and the control recipe is what one batch actually runs, which here is the order with its runs pinned to the effective revision. The isa88_level column marks an operation as a unit procedure, an operation or a phase; it is none for a discrete routing such as the seed's bracket.

Regulated plants need this rule. For batch production, the US rules ask that a master record exists and that each batch record shows each step completed and checked ^[1]; for devices the QMSR asks for a device history record ^[2]. Where records are electronic, the electronic-signature rules apply ^[3]. Even where nothing is regulated, the habit is worth having: a revision you can point to ends arguments about what the instruction said on the day.

Rules this course adds

The specification names the tables and columns. This course adds rules inside the database so impossible rows cannot get in; ask your agent to add each, with a test.

• One core_item has at most one mes_product_definition with status effective at a time (a partial unique index: a uniqueness rule that applies only to rows meeting a condition).
• One piece of equipment has at most one mes_equipment_state_event with no ended_at, so it cannot be in two states at once.
• One mes_operation_run for each order and operation; one operation for each definition and seq; one step for each operation and step_no; one mes_shift_performance for each equipment and shift.
• lsl is not above usl; ended_at is not before started_at; a run's qty_good, qty_scrap and qty_rework are not negative.
• Counts and consumptions may be negative, because that is how they are corrected: a row with the opposite sign that names the row it corrects in ext and carries a core_comment with the reason. The supervisor enters a count correction with source manual; the operator reverses a wrong scan while the run is still running; after a run is complete a wrong consumption becomes a deviation instead.

Exercise · Write one routing as rows15 minutes

You need: The routing from your Session 1 inventory, the column tables in this chapter, and your AI coding agent

Use the product you chose in Session 1. Do steps 1 to 5 on paper or in a text file; the agent comes in at step 6.

1. 1. Write the header: code, item, revision, process_type and status draft.
2. 2. List its operations in order. For each give seq, code, name, the work centre (the code of an existing core_equipment row), std_setup_min, std_cycle_sec and std_crew, and mark whether it is a quality gate.
3. 3. Under each operation list its steps with step_no and step_type. Make the last one a signature step that requires verification.
4. 4. For every measured value write a parameter: key, unit, target, lsl, usl, whether it is captured by tag or by hand, and whether it is critical.
5. 5. List the inputs and outputs of each operation with quantity per finished unit, direction, and whether each input is consumed by scan, by backflush or by hand.
6. 6. Ask your agent: show me the rows these tables would hold for this routing, with typed columns, keys only to core_ and mes_ tables, and no new table for a work centre. Check every work centre against core_equipment and every measured value against value_num.

Outcome: A routing written as rows of the five definition tables, every work centre an existing spine equipment code, and every measured value a typed parameter with limits.

References

1. eCFR: Title 21, Part 211, current good manufacturing practice for finished pharmaceuticals (subpart J holds the batch production records, sections 211.188 and 211.192). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211
2. eCFR: Title 21, Part 820, Quality System Regulation and QMSR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
3. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
4. ISA: ISA-95 series of standards (object models for equipment and material). https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard

By the end of this chapter you can

• Follow an order from release to completion and say which status changes at each point.
• Name the interlocks that stop an unqualified operator, an overdue gauge, a held lot and a step done out of order.
• Explain signed step records, review by exception and how genealogy is built from consumption and production.

Release and dispatch

An order starts planned. The planner releases it, which is allowed only if its product definition is effective and signed, and releasing creates one run for each operation: the first is ready and the rest are pending. Releasing also writes an event, mes.production_order.released, to the outbox. The dispatch list for a work centre then shows one card for each ready run in the operator's area, ordered by priority and then due date, with a Start button only when the run is ready.

The interlocks

An interlock is a rule that must be satisfied before an action is allowed. The module puts them in the database as triggers (rules that run on each insert or update), so no screen, route or script can skip one. If the database refuses an action, the route returns the rule's message to the operator. History is the one exception, and it is keyed to who inserts it, not to what a row says: a row marked ext imported_from skips the insert checks only when the importer account or the migration role that loads the seed inserts it, so the same marker on a row from an operator's route is ignored.

Two notes on how the database applies them. A role can only update rows it can read, so the operator's rights must include reading the qualification and calibration tables the interlocks consult; if they do not, every start is refused or, worse, the check finds nothing. Running as the operator, the checks also see only the operator's area, which is one reason the first scope is a single area. And a refusal leaves no trace behind: a rejected scan creates no consumption row, which is why the dispatch list and the lot balances stay true.

Parameters and steps

The operator sees one step at a time, with large targets: an instruction, a scan box, a number box with its limits and a colour for in or out of specification, a signature button and a pause button. A measured value is stored in mes_parameter_value with in_spec set by the database from the limits, inclusive of both: with limits of 119.5 and 120.5, a value of 120.5 is in specification and 120.51 is not. An out-of-spec critical value publishes mes.parameter.out_of_spec, and the run cannot complete until a deviation is recorded against it.

Material in, lots out: genealogy

Scanning a lot into a run writes a row to mes_material_consumption. Completing a run writes the lot it made to mes_material_production, and a row to the spine's core_lot_genealogy with relation consumed_into: it says the parent lot went into the child lot. Follow those links forward and you find every lot that used a material; follow them backward and you find everything that went into a lot. A lot made by a run is numbered order number, a dash and the operation code (PO-1001-OP10), so it is readable and unique, and its status is released, because this course builds no inspection hold.

A trace is a recursive query: it follows the links level by level until none are left, returns each lot with its depth and the run that linked it, and refuses to loop. The module's target is a full forward and backward trace across three levels in under one second on seeded data, and you time it in Session 4 with EXPLAIN ANALYZE (the command that runs a query and reports how long it took).

Signed step records and review by exception

The step records of a run are the module's electronic batch record or device history record. Each has a performer and, where the step requires it, a verifier, each with their own electronic signature (core_e_signature) that names the meaning (performed, verified or reviewed) and a hash that changes if one character of the signed content changes. US rules ask that electronic signatures be unique to a person and linked to their record ^[1], and that batch records show each significant step ^[2].

Reading every record of every run does not scale. Review by exception means a person reads only the runs that need it: one with an out-of-spec value or a deviation. A clean run is approved in one action. The specification also names overrides; this course builds no way to override an interlock or skip a step, so there are none to flag, and if you ever add one it must be flagged in the record like the others. The rule that makes this honest is that every exception is flagged in the record, so none can hide in a run that looks clean.

Exercise · Write the rules page20 minutes

You need: Your Session 1 inventory, the interlock table in this chapter, and a text editor open on docs/mes-rules.md in your repository

Session 4 builds the triggers from this page, so write it as rules a developer could not misread. Keep to one page.

1. 1. List the interlocks your line needs, using the nine in this chapter as the start, and write beside each the exact message an operator should see when it refuses (for example: Qualification expired on 31 January 2026; ask your supervisor).
2. 2. Write the status ladders for orders and runs and say who may make each move. Say what makes a run ready.
3. 3. Write how a lot made by a run is numbered, and check that the same run can never make two lots with one number.
4. 4. For each interlock, write the test that would prove it from the Session 2 seed: the person or lot, the action, and the refusal expected. Use OPR-1, OPR-2, OPR-3, RAW-L3 and RAW-L1 where they fit.
5. 5. Write which table rows can never be changed once written, and which three columns of a step record may be set later by a verifier.
6. 6. Say what the module will never do to a machine, and which person decides if that ever changes.
7. 7. Ask the supervisor and the process engineer to read it and write down every rule they would add or remove.

Outcome: A docs/mes-rules.md with each interlock, its message, its status moves, its lot numbering, its seeded test, and the sign-off of two people from the floor.

References

1. eCFR: Title 21, Part 11, Electronic records; electronic signatures. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
2. eCFR: Title 21, Part 211, current good manufacturing practice for finished pharmaceuticals (batch production records are in subpart J). https://www.ecfr.gov/current/title-21/chapter-I/subchapter-C/part-211
3. Siemens: ISA-95 framework and layers. https://www.siemens.com/en-us/technology/isa-95-framework-layers/
4. SYMESTIC: the 11 core MES functions (MESA-11), including dispatching, labour and genealogy. https://www.symestic.com/en-us/what-is/mesa-11

By the end of this chapter you can

• Map machine states to the module's nine states and say when a short stop is a micro-stop.
• Calculate availability, performance, quality and OEE from one time base, by hand, to two decimals.
• Describe how messages reach the ERP through the outbox, and what must be migrated at cut-over.

Machines report; the module records

Counts, states and process values reach the module through the spine's tag registry (core_data_tag). OPC UA (IEC 62541) is the standard way for a machine or gateway to publish values ^[1]; MQTT with Sparkplug B is a light publish and subscribe scheme with an agreed layout for industrial data ^[2]. A tag collector machine account posts them: counts go to mes_production_count, state changes to mes_equipment_state_event and parameter values to mes_parameter_value with source tag. Where no tag exists, the supervisor enters the shift's states on the downtime screen and its counts in a counts box (an operator may enter counts for their own run), with source manual, and the performance job calculates from those rows exactly as it does from tag rows.

The feed is safe to repeat. Every message carries an id made by the sender, which the route keeps in the row's ext as message_id; a message whose id is already stored is skipped, and a simulator that posts a fixed feed twice leaves the same rows. A tap sent twice from a phone with a poor signal behaves the same way, so counts and downtime are never doubled.

States, reasons and micro-stops

The module has nine equipment states: running, idle, starved, blocked, planned_down, unplanned_down, changeover, micro_stop and offline. A packaging line's machine publishes the PackML state model (ISA-TR88.00.02), and the module maps it as follows.

In PackML, Held is a stop for a condition inside the machine, and Suspended is a wait for something outside it, such as no input or a full output. Machines differ, so read the state list of your own machine and write its mapping on the rules page; the table is a starting point.

A blocked, starved or unplanned_down stop shorter than 2 minutes is stored as micro_stop and needs no reason. Two minutes is this course's own threshold, written in docs/mes-rules.md where you may change it. Micro-stops matter because they are too short for anyone to log and too frequent to ignore, so they are where lost time can hide unnoticed. A longer stop appears on the downtime screen until someone gives it a reason from core_reason_code, which marks each reason planned or not.

OEE on one time base

OEE (overall equipment effectiveness) is availability times performance times quality. ISO 22400-2 defines the manufacturing KPIs, and names the same three factors as availability, effectiveness and quality ratio ^[3]. The danger is not the formula; it is mixing time bases, so that availability is measured against the shift, performance against the run, and nobody can reproduce the figure. The module fixes one base, written on the rules page, for every figure.

The numbers a plant manager asks for

Talking to the ERP

The ERP owns orders and plans. The schedule comes in as production orders (source erp, with the ERP's number in external_ref). Performance and material movements go out as B2MML-style messages: B2MML is the MESA set of schemas that carries ISA-95 messages, and a run or lot message is named ProductionPerformance ^[4]. A message is never sent from the middle of an operation. The completion writes an event to core_event_outbox in the same database transaction as the record it describes, so either both exist or neither does.

Cut over and retire the old tool

MES history is rarely migrated whole. Migrate the open orders, the product definitions and the last 12 to 24 months of genealogy for the traceability obligations you have; leave the rest in an export you can still open. Rows brought in this way carry ext holding imported_from. When the importer account (or the migration role that loads the seed) inserts them, they skip the signature rule, the draft-only rule and the insert checks on history, so a definition can arrive already effective with its operations; the same marker on a row from any other role is ignored, so it can never open an interlock. An import sends nothing to the ERP. Imported history (completed runs, consumptions, productions and genealogy) can never be changed afterwards; imported open orders and definitions follow the normal rules. Before cut-over check that every operation points to a real work centre and every lot link resolves.

Run the old and the new side by side for at least a week, then check three things before you cancel. A lot traces forward and backward across three levels in under one second on seeded data. An unqualified operator is blocked from starting an operation that requires a skill. OEE for a seeded shift matches a hand calculation to two decimals.

Exercise · OEE and a trace, by hand20 minutes

You need: Paper or a spreadsheet, and the numbers below (they are the Session 2 seed for CELL-B on Monday 2 March 2026)

The shift runs 06:00 to 14:00. State intervals: changeover 06:00 to 06:30; running 06:30 to 09:30; unplanned_down 09:30 to 09:45; running 09:45 to 11:45; planned_down 11:45 to 12:15; running 12:15 to 13:45; starved 13:45 to 14:00. Counts: good 225 with reject 9, good 150 with reject 6, good 75 with reject 3. The ideal cycle for the operation at this press is 45 seconds. Lot links (consumed_into): RAW-L1 into PO-0900-OP10 (80 KG); PO-0900-OP10 into PO-0900-OP20 (40 EA); RAW-L1 into PO-0901-OP10 (60 KG); PO-0901-OP10 into PO-0901-OP20 (30 EA).

1. 1. Write planned busy time: the shift's minutes less the planned_down minutes.
2. 2. Write run time: the sum of the running intervals, in minutes.
3. 3. Calculate availability as run time divided by planned busy time. Keep four decimals.
4. 4. Calculate performance: the ideal cycle times the total count, divided by the run time in seconds. Total count is good plus reject.
5. 5. Calculate quality as good count divided by total count.
6. 6. Multiply the three unrounded figures to get OEE, and only then round it to four decimals. Write the sums, not just the answers.
7. 7. Trace forward from RAW-L1: list every lot reached with its depth. Then trace backward from PO-0901-OP20 and list every lot with its depth.
8. 8. Put your answers in docs/mes-seed.md before Session 4. When the function runs, it must agree to two decimals.

Outcome: Written sums for planned busy time, run time, availability, performance, quality and OEE, and two traces, each lot with its depth. If your time base is the one on the rules page you will reach an OEE of 0.7500, four lots forward from RAW-L1 (two at depth 1, two at depth 2) and, backward from PO-0901-OP20, PO-0901-OP10 at depth 1 and RAW-L1 at depth 2.

References

1. OPC Foundation: OPC UA. https://opcfoundation.org/about/opc-technologies/opc-ua/
2. Eclipse Sparkplug specification. https://sparkplug.eclipse.org/
3. ISO 22400-2:2014, Key performance indicators for manufacturing operations management: definitions and descriptions. https://www.iso.org/standard/54497.html
4. Automation World: the five parts of ISA-95 (Part 5, business-to-manufacturing transactions). https://www.automationworld.com/products/software/article/13309288/the-five-parts-of-isa-95

Choose one answer for each question, then submit. You will see the right answer and why for every question.

1. Which three verbs describe what an MES does?

APlan, buy and sellBDesign, test and shipCExecute, enforce and recordDForecast, budget and report

2. A schedule arrives from the ERP and performance goes back to it. Which ISA-95 level is the system in the middle?

ALevel 3, manufacturing operations managementBLevel 4, business planning and logisticsCLevel 2, supervisory control of the lineDLevel 1, sensing and manipulating the process

3. Which MESA function does this module leave to another module (M03)?

ADispatchingBGenealogyCData collectionDScheduling

4. How is the MES kept from building a second equipment hierarchy?

ABy giving each machine two codes, one in the MES and one in the maintenance system, and matching them nightlyBWork centres and machines are rows of core_equipment, and no mes_ table holds a machine or lineCBy copying the ERP's machine list into a mes_ table every night and keeping that copy up to dateDBy letting each operator add the machines they use to a mes_ table when they first need them

5. A product definition's status is effective. What is the right way to change a limit on one of its parameters?

AMake a new revision, approve it and make it effective, which supersedes the old oneBEdit the parameter in place and write a note in the order's comments afterwardsCDelete the definition and the orders made on it, then start again with a new oneDChange the limit on the order only and leave the definition as it was approved

6. Why is mes_parameter_value.in_spec set by the database from the limits and not typed by the operator?

AOperators are not allowed to see the limits of a parameter, so the database has to judge for themBLimits change every hour, so only the database can keep up with the limit for each valueCThe database evaluates every value the same way, inclusive of lsl and usl, so 120.5 passes and 120.51 does notDIt saves one column in the table, which keeps each insert smaller and faster for the press

7. An operator whose SK-FORM qualification has expired tries to start OP20. What stops the start?

AA poster at the press that reminds operators to check their own qualificationBThe supervisor's memory of who has been trained on which press this yearCA warning on the screen that the operator may dismiss and carry on regardlessDA trigger in the database that checks the qualification when the run moves to running

8. RAW-L1 had 1000 KG, with 80 KG and 60 KG consumed. What happens if a run tries to consume 900 KG more?

AIt is refused: 860 KG is leftBIt is accepted and the lot goes negativeCIt is accepted and flagged for laterDIt is accepted if the operator signs

9. What does review by exception mean?

AReviewers skip the runs they find dull and read only the ones that look interesting to them on the day, whatever the data saysBOnly the runs with an out-of-spec value or a deviation are read by a person, because every exception is flagged; clean runs are approved in one actionCEvery record is read twice, once by the supervisor and once by the quality engineer, and neither may approve a run aloneDExceptions are deleted from the record once the reviewer has seen them, so that only clean runs remain on file afterwards

10. A mes_production_count row was keyed wrongly. How is it corrected?

ABy editing the row, then recording the reason in the audit logBWith a new, audit-trailed entry, because counts are append-onlyCBy deleting the row and posting the corrected count againDBy restarting the shift so that the counter begins again from zero

11. On CELL-B the shift is 480 minutes with 30 minutes planned_down and 390 minutes running. What is availability?

A390 ÷ 480 = 0.8125B390 ÷ 30 = 13C30 ÷ 480 = 0.0625D390 ÷ 450 = 0.8667

12. Why does an MES message to the ERP come from an outbox row written in the same transaction as the record?

ATo make each message shorter, because the outbox row holds only a few fields of the record and the ERP reads the rest itselfBBecause the ERP cannot read the MES database and therefore needs a second copy of every table that the MES keeps for itselfCEither both exist or neither does, so a message is never sent for a record that was not saved, and a failed send can be retriedDTo avoid using B2MML, which the outbox row replaces for every message that goes to the ERP, so no schema is needed at all

Submit answers