What Is a Manufacturing Execution System? A Practical Definition for Ignition Users

Ignition users often arrive at MES gradually.

A team starts by visualizing PLC data. Then they add a few Perspective screens. Then someone asks for production counts by shift. Then the plant wants downtime reasons, work order progress, quality checks, schedule adherence, or traceability reports. Before long, the application is no longer just showing what equipment is doing. It is trying to manage production context.

That is where Manufacturing Execution System (MES) thinking starts to matter.

For an Ignition audience, a practical definition is this:

A Manufacturing Execution System is the layer that connects production execution, plant-floor data, operational context, and manufacturing workflows.

MES helps answer questions that raw tags, dashboards, and databases do not answer by themselves:

• What was supposed to be running?
• What was actually made?
• Which asset, line, or area was involved?
• What item or material was being produced?
• Which order, run, shift, or operation does the data belong to?
• Why was equipment down?
• Were required quality checks completed?
• Which lots or materials went into the finished product?
• What records are needed after the run is complete?

That context is the difference between plant-floor data and manufacturing execution data.

MES is not just SCADA

Ignition is an excellent platform for SCADA, industrial applications, data collection, visualization, alarming, scripting, and integration. But SCADA and MES have different jobs.

SCADA is typically focused on monitoring and controlling equipment. It shows current values, equipment status, alarms, trends, and operator controls. It is close to the process.

MES is focused on production execution. It connects equipment behavior to production context: orders, items, shifts, states, downtime, counts, quality checks, lots, and reports.

That distinction matters because a machine state by itself is not enough. A downtime tag may tell you that a line stopped. MES context helps explain whether that stop happened during a production run, which item was being produced, which order was affected, whether the stop was planned or unplanned, and how it should appear in production reporting.

MES is not just dashboards

Dashboards are useful, but dashboards are not MES by themselves.

A dashboard can show counts, OEE, downtime, or line status. But if the underlying system does not understand production orders, assets, items, states, shifts, quality records, and traceability relationships, the dashboard may only be a polished view of disconnected data.

MES is the structure behind the visibility. It defines how production activity is modeled, captured, reviewed, and reported. The goal is not simply to display more information. The goal is to make production information trustworthy and operationally useful.

MES is not just OEE

Overall Equipment Effectiveness (OEE) is one common MES use case, but MES is broader than OEE.

OEE can help teams understand availability, performance, and quality. But MES also supports the surrounding operational context that makes OEE useful: production schedules, work orders, item rates, downtime reasons, modes, production counts, scrap, shift context, operator workflows, and run review.

A single OEE number can tell you something is wrong. MES helps connect that number to what was running, where it was running, what happened, and what the team should investigate next.

MES is not just a database

Many MES projects start with the database question: “Where should we store production data?”

That is important, but a database is not the same thing as MES.

A database can store events, counts, checks, and transactions. MES defines what those records mean and how they relate to each other. It gives structure to production activity so the organization is not just collecting rows of data, but building a usable operating model.

For example, a count record becomes more valuable when it is tied to an asset, item, production order, run, shift, and timestamp. A quality result becomes more valuable when it is tied to the item, asset, production run, specification, operator action, and review process. A lot movement becomes more valuable when it is connected to material consumption, transformation, output, and genealogy.

MES is not only storage. It is context, workflow, and structure.

MES is not just paper forms turned into screens

Digitizing forms can be a good step. But an electronic form by itself is not necessarily MES.

If a check is entered on a screen but is not connected to the production order, asset, item, shift, specification, or run, the plant may still be left with disconnected data. MES brings those records into production context so they can support review, reporting, analysis, and traceability.

The same is true for operator screens. An operator interface becomes more powerful when it is part of a larger execution model: selecting orders, starting runs, entering counts, choosing downtime reasons, recording scrap, completing checks, and reviewing production events.

The core job of MES

The core job of MES is to connect what happened on the plant floor to what was supposed to happen.

That means connecting five kinds of information:

1. The plan: orders, schedules, items, expected rates, shifts, and operations.
2. The equipment: assets, lines, cells, machines, states, modes, and events.
3. The execution record: runs, counts, downtime, scrap, quality checks, lot movements, and operator actions.
4. The context: which product, material, order, lot, shift, asset, or crew was involved.
5. The record afterward: reports, analytics, quality records, traceability records, ERP updates, and continuous improvement data.

When those pieces are connected, teams can move from “the line was down” to “this order, on this line, for this item, during this shift, lost 42 minutes to this downtime reason while running below expected rate.”

That is the practical value of MES.

Common MES building blocks

Most MES systems organize a similar set of manufacturing concepts, even if the implementation varies by industry and plant.

An asset model defines the production structure: enterprise, site, area, line, cell, machine, or other operational hierarchy.

An item or material model defines what can be made, consumed, tracked, measured, or reported against.

Production orders and work orders define the work that should happen. They may originate in an ERP system, be created in the MES, or be managed through an implementation-specific workflow.

Runs and operations connect the work order or production activity to actual execution on the floor.

States, modes, downtime, and events describe what equipment and production were doing over time. This is where teams distinguish running time, planned downtime, unplanned downtime, changeovers, maintenance, breaks, and other operational realities.

Counts and performance data connect machine signals, manual entry, scrap, performance losses, and production rates to the production record.

Quality checks connect inspection, data collection, specifications, tolerances, and review workflows to the production context where quality actually happened.

Lots, material movement, and genealogy connect inputs, outputs, transformations, receiving, transfers, splitting, scrapping, serials, and traceability relationships.

Reporting and operational analytics make the model useful to operators, supervisors, engineers, managers, and business systems.

None of these pieces exists in isolation. MES becomes valuable when the model connects them.

Why Ignition users naturally encounter MES needs

Ignition teams are often close to the real production problem. They can see the PLCs, tags, screens, databases, scripts, devices, and integrations. That makes Ignition a natural environment for building manufacturing applications.

But as those applications move from visualization into execution, complexity grows.

A simple count screen becomes a production-reporting workflow. A downtime dropdown becomes a state model. A work order table becomes scheduling and dispatch. A quality form becomes a check workflow tied to items, assets, specifications, and production runs. A lot entry screen becomes genealogy.

Custom development can work, especially for focused use cases. But over time, teams often need common patterns that are consistent, maintainable, and scalable across lines, areas, or sites.

That is the MES inflection point.

The question becomes: should the team keep building every MES pattern from scratch, or should they start from a productized MES foundation and extend where the plant truly needs something specific?

Where Kanoa MES fits

Kanoa MES is Kanoa’s modular Manufacturing Execution System product for Ignition.

It is built on and for Ignition, installed on an Ignition Gateway, and uses Ignition Perspective for the application layer. Kanoa MES includes installed technical contents such as the Kanoa MES Ignition module, the kanoaCore database, Kanoa API / Ignition system functions, and Ignition Perspective projects. It also includes licensed Solutions that determine which functional areas are entitled for production use.

Kanoa Ops is the required foundation Solution within Kanoa MES. It supports operational workflows such as assets, work orders, schedules, modes, shifts, production events, downtime, scrap, performance losses, operator workflows, OEE, and production visibility.

Kanoa Quality extends that foundation into quality workflows such as configurable Check Sheets, quality checks, specifications, inspections, Statistical Process Control, and production-context quality records.

Kanoa Trace extends the foundation into lot and serial tracking, genealogy, routing, inventory visibility, material movement, and traceability reporting.

The important point is that Kanoa MES is not just a backend module, not just a database, and not just a Perspective project. It is a productized MES foundation for Ignition teams.

That foundation can reduce the amount of custom MES development required. It does not eliminate implementation work. Teams still need to make design decisions, configure workflows, connect plant-floor and enterprise systems, validate behavior, train users, and adapt the system to the plant.

That is why the Ignition foundation matters. Kanoa MES gives teams standard MES structure while preserving the ability to configure and extend through Ignition for plant-specific workflows, integrations, reports, and interfaces.

A practical MES self-assessment

Your Ignition application may be moving into MES territory if your team is asking questions like these:

• Are we managing production orders or work orders?
• Are we tracking which item was made on which asset?
• Are operators selecting modes, states, or downtime reasons?
• Are we recording production counts, scrap, or performance losses?
• Do reports need to align by line, area, shift, item, or site?
• Are quality checks tied to production context?
• Do we need to know which lot, batch, serial number, or material went into which output?
• Are we sending production results back to ERP or another business system?
• Are we trying to standardize execution workflows across more than one line or plant?
• Are we rebuilding similar screens, scripts, tables, and reports over and over?

If the answer to several of those questions is yes, the project is probably no longer just SCADA or visualization. It is becoming MES.

Moving from custom applications to structured MES patterns

For Ignition users, MES does not have to mean abandoning the flexibility that made Ignition attractive in the first place.

The practical goal is to put structure around production execution while keeping the ability to adapt to real plant needs.

That is the role Kanoa MES is designed to play: a modular Manufacturing Execution System product for Ignition that gives manufacturers and systems integrators a productized starting point for common MES patterns, with room to configure and extend through Ignition where the implementation requires it.

If your team is moving from dashboards and custom production screens toward orders, runs, downtime, quality, traceability, and operational reporting, it may be time to define the MES layer intentionally.