Connect981 – Content Dev

RSC Topic: Manufacturing Execution Systems (MES)

How production work is routed, tracked, and controlled on the shop floor.

  • What are common hybrid architectures for aerospace MES?

    Common hybrid architectures for aerospace MES usually combine existing ERP, PLM, QMS, maintenance, and sometimes legacy MES systems with newer execution, traceability, integration, or analytics layers. Full replacement is often unrealistic in aerospace-grade environments because qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, change control, and long equipment lifecycles can outweigh the theoretical simplicity of a clean cutover.

    The practical question is usually not whether to replace everything. It is which execution functions must be controlled directly by MES, which systems remain authoritative, and how records, revisions, exceptions, and approvals move across the architecture without breaking evidence trails.

    Common hybrid patterns

    • MES as an execution layer over ERP and PLM. ERP remains the system of record for orders, inventory, costing, and planning. PLM remains authoritative for engineering definitions, bills of material, drawings, and revisions. MES controls shop-floor execution, routing status, labor capture, serialized genealogy, work instructions, and production records.
    • Digital traveler and work instruction layer beside legacy MES. A newer system may manage operator guidance, buyoff, defect capture, and electronic records while an older MES continues to handle dispatching, labor, or WIP transactions. This is common when the legacy system is deeply integrated but weak in user experience, version control, or evidence collection.
    • Plant-local execution with enterprise visibility. Plants keep local MES instances or site-specific execution tools, while an enterprise layer aggregates status, quality signals, genealogy summaries, and performance metrics. This can reduce standardization risk, but it requires disciplined data mapping and agreement on common identifiers.
    • Cloud plus edge architecture. Cloud services may provide work instruction management, analytics, supplier collaboration, or multi-site reporting, while edge or plant-local services handle machine connectivity, offline execution needs, latency-sensitive operations, and continuity during network disruption. Suitability depends on cybersecurity, export control, customer flow-downs, and validation strategy.
    • Integration hub or event-driven architecture. Middleware, APIs, message queues, or an integration platform connect MES with ERP, PLM, QMS, metrology systems, maintenance systems, and data historians. This can reduce point-to-point fragility, but it does not solve poor master data, unclear ownership, or inconsistent process definitions.
    • Specialized quality systems alongside MES. FAI, NCR, MRB, CAPA, calibration, inspection, and supplier quality workflows may remain in dedicated QMS or quality tools. MES then exchanges inspection status, nonconformance holds, dispositions, and release signals rather than trying to own every quality process.
    • Supplier and outside-processing portals. Some architectures extend limited execution or status capture to suppliers, processors, or MRO partners. These models need careful control of technical data, revision visibility, acceptance criteria, and evidence returned to the prime or tier supplier.

    What usually determines the right pattern

    The architecture depends on where the authoritative data lives, how mature the current processes are, and how much change the plant can safely absorb. A site with stable routings, clean part and serial structures, and disciplined revision control can support tighter integration. A site with inconsistent master data or informal workarounds usually needs process cleanup before deep automation.

    Program and customer requirements also matter. Defense work, export-controlled data, customer-mandated portals, long-running contracts, and frozen baselines can limit what can be moved, where it can be hosted, and how quickly workflows can change. These constraints are not just IT preferences; they often affect validation, access control, audit evidence, and contract compliance obligations.

    Common failure modes

    • Unclear system of record decisions. If ERP, MES, PLM, and QMS all appear to own part revision, routing, inspection status, or nonconformance state, reconciliation becomes a permanent operating burden.
    • Digitizing undocumented variation. Hybrid MES projects fail when they automate local exceptions without deciding which exceptions are legitimate, controlled, and repeatable.
    • Weak integration testing. Aerospace execution depends on sequencing, holds, approvals, effectivity, and traceability. Basic interface testing is not enough if exception paths are not validated.
    • Broken genealogy or evidence chains. Moving work between systems can create gaps in serial genealogy, material traceability, operator certification records, inspection evidence, or revision history.
    • Underestimated change control. Even small changes to electronic travelers, data capture, integrations, or approval workflows may require documented review, validation, training, and controlled rollout.

    Practical boundary

    A hybrid aerospace MES architecture can be a sound approach, but only if coexistence is designed intentionally. It needs defined ownership of data, controlled integrations, tested exception handling, cybersecurity review, validation evidence, and operating procedures for outages or manual recovery. Without those controls, hybrid architecture becomes another layer of integration debt rather than a safer modernization path.

  • Production Confirmation

    Production confirmation is the recorded update that a production order, work order, or routing operation has been performed. It commonly captures what was completed, when it was completed, who performed it, and the quantities produced, scrapped, or reworked.

    In manufacturing systems, production confirmation is used to close the loop between planned work and actual shop-floor execution. It may be entered in an MES, ERP, digital traveler, or operator interface, and can update order status, labor time, machine time, inventory consumption, produced quantities, and traceability records.

    The exact data included depends on the process and system design. A confirmation may apply to a full production order, a single operation, a batch step, or a serialized unit. In regulated or quality-sensitive environments, it is often linked to operator signoffs, inspection results, material lots, equipment used, and timestamps.

    Production confirmation should not be confused with a customer order confirmation or sales order acknowledgment. In this context, it refers to confirmation of manufacturing execution, not confirmation that a customer order has been accepted.

  • Operational layer

    The operational layer commonly refers to the part of an industrial or manufacturing environment where production work is executed, monitored, coordinated, and recorded. It sits between high-level business planning and the physical process or equipment, translating production intent into day-to-day operational activity.

    In practice, the operational layer often includes manufacturing execution, shop floor coordination, work instructions, quality checks, scheduling detail, data collection, and traceability functions. It is where operators, supervisors, and plant systems interact with work orders, materials, equipment status, process data, and production records.

    It does not usually mean the physical device layer itself, such as sensors, PLCs, drives, or machines, and it does not usually mean the enterprise planning layer, such as long-range financial planning or corporate ERP processes. Instead, it commonly refers to the execution and control context that connects those layers.

    How the term is used in manufacturing systems

    In manufacturing and regulated operations, the operational layer is often associated with systems such as MES, production tracking tools, electronic batch or device history records, digital work instruction platforms, quality data collection, and related integration services. This layer is where planned work becomes actual work, and where operational events are captured as records.

    • Receiving production orders from enterprise systems
    • Dispatching or sequencing work on the shop floor
    • Managing operator tasks and work instructions
    • Collecting process, material, and labor data
    • Recording inspections, nonconformances, and traceability events
    • Exchanging status information with equipment and business systems

    In ISA-95 style discussions, this idea is broadly aligned with manufacturing operations management functions between enterprise planning and direct control, although organizations may use different layer names.

    Common confusion

    Operational layer is often confused with OT, control layer, or application layer.

    • OT is broader and can include control systems, networks, and devices used to operate industrial processes.
    • Control layer usually refers more narrowly to automation and real-time control components such as PLC, SCADA, or DCS functions.
    • Application layer is an IT architecture term and may refer to software structure rather than a manufacturing operating level.

    Because naming varies by vendor and architecture model, the term is best understood by its role: the layer that manages production execution and operational records.

  • What is ISA‑95?

    ISA‑95 is an international standard (also known as IEC 62264) that defines a common framework for integrating enterprise and control systems in manufacturing. It focuses on how business systems (for example, ERP) and operational systems (for example, MES, SCADA, DCS, PLCs) exchange information in a consistent and structured way.

    The standard provides:

    • Common terminology for equipment, materials, people, and production activities.
    • A functional hierarchy (Levels 0–4) describing where different systems and processes sit, from physical processes up to business planning and logistics.
    • Information models and interfaces that define what data is exchanged between levels, particularly between Level 3 (manufacturing operations management) and Level 4 (enterprise systems).

    ISA‑95 is not a software product, protocol, or detailed implementation guide. Instead, it is a reference model and set of standards used to:

    • Align IT (Information Technology) and OT (Operational Technology) teams on a shared architecture.
    • Reduce ambiguity and custom point‑to‑point interfaces between systems.
    • Lower integration risk by clarifying responsibilities and data flows.
    • Support vendor‑neutral system design and selection.

    Organizations typically apply ISA‑95 by mapping their existing systems and workflows to the ISA‑95 levels and models, then using those models to design interfaces, data structures, and responsibilities between business and manufacturing systems.

  • automation

    Automation commonly refers to the use of hardware, software, and control logic to perform tasks with reduced or no continuous human intervention. In industrial and manufacturing environments, this includes using control systems, sensors, and software to execute repeatable operations, enforce process rules, and coordinate equipment.

    Automation in manufacturing and regulated operations

    In manufacturing, automation typically involves:

    • Physical equipment control, such as programmable logic controllers (PLCs), distributed control systems (DCS), and robotics that run machines, valves, drives, and conveyors.
    • Procedural or batch control, where systems execute ordered sequences of operations, often modeled using standards such as ISA‑88 for batch processes.
    • Information and workflow automation, such as MES or ERP-driven workflows that generate work orders, collect data, enforce checklists, and trigger quality or maintenance actions.
    • Data collection and monitoring, including automated capture of process parameters, alarms, events, and electronic records for analysis and compliance.

    Automation can be applied at multiple levels, from a single machine or unit operation, to a production line, plant, or enterprise-wide processes. It can support production, quality, maintenance, supply chain, and regulatory recordkeeping activities.

    What automation is not

    • It is not inherently a guarantee of product quality, safety, or regulatory compliance. These depend on how automation is designed, validated, and operated.
    • It is not limited to robotics or physical equipment; business rules, approvals, and data flows can also be automated.
    • It is not the same as full autonomy. Human operators, engineers, and quality personnel typically retain responsibility for oversight, setpoints, recipes, and deviation handling.

    Operational usage

    In day-to-day operations, automation appears as:

    • Automatic execution of recipes or procedures, with control systems stepping through phases and operations.
    • Automatic enforcement of interlocks, limits, and preconditions before equipment can start or change state.
    • Automated triggering of electronic records, electronic signatures, or quality checks based on process events.
    • Scheduled or event-based jobs, such as automatic data exports, report generation, or system-to-system integration tasks.

    In regulated environments, the design and modification of automation are typically subject to change control, documented requirements, testing, and periodic review.

    Common confusion

    • Automation vs. control: “Control” often refers to the real-time regulation of process variables (such as temperature or flow). “Automation” usually includes control but also covers higher-level sequencing, interlocks, and information workflows.
    • Automation vs. digitalization: Digitalization involves converting information and processes into digital form. Automation specifically focuses on executing tasks and decisions with reduced human intervention, whether or not the broader process is fully digitalized.
    • Automation vs. autonomy: Automated systems follow defined logic and rules. Autonomous systems are designed to make higher-level decisions and adapt behavior with less predefined logic, often using advanced analytics or AI.

    Relation to ISA-88 and batch control

    Within the context of batch manufacturing and standards such as ISA‑88, automation commonly refers to implementing the standard’s procedural and equipment models in control systems and MES. This can include automated execution of unit procedures and operations, recipe management, coordination between equipment modules, and integration of batch records with higher-level IT systems.

  • human-in-the-loop

    Core meaning

    Human-in-the-loop (HITL) commonly refers to a design approach in which human operators remain actively involved in reviewing, approving, or overriding the outputs of an automated system. The system is intentionally built so that critical decisions, or the authority to enact them, pass through a human rather than being executed fully autonomously.

    In industrial and manufacturing contexts, this typically means that automated analytics, optimization engines, or AI models generate recommendations or preliminary decisions, while qualified personnel confirm, adjust, or reject those outputs before they affect production, quality disposition, or regulatory records.

    Use in industrial and regulated environments

    In operations and manufacturing systems, human-in-the-loop is often applied to:

    – **AI and advanced analytics**: Models propose setpoint changes, maintenance actions, or quality classifications, but engineers or supervisors must review and approve before implementation in MES, DCS, or ERP.
    – **Workflow and MES steps**: Systems may route exceptions, deviations, or out-of-trend results to an operator for assessment and decision, even if detection or triage is automated.
    – **Electronic records and release decisions**: Automated checks (e.g., specification limits, rule engines) can flag issues, but batch release, disposition, or corrective actions are confirmed by authorized personnel.
    – **Safety- and compliance-relevant actions**: Any action that could significantly affect product quality, patient safety, or regulatory records is kept under explicit human authority, even when automation supports the decision.

    Human-in-the-loop designs are commonly supported by:

    – Clear roles and responsibilities for who can approve or override automated outputs
    – System features that pause execution until human review is recorded
    – Audit trails documenting human decisions and rationale
    – Interfaces that present model or system outputs in a way that is understandable to the responsible user

    Boundaries and what it is not

    Human-in-the-loop:

    – **Is**: A governance and interaction pattern where humans remain accountable decision-makers while using automation as an input.
    – **Is not**: Purely manual operation without automation; by definition, there is an automated or algorithmic component being supervised.
    – **Is not**: Fully autonomous control, where a system executes actions without any human review or approval within a defined decision loop.

    It can coexist with other patterns, such as:

    – **Human-on-the-loop**: Humans monitor high-level behavior and can intervene but are not required to approve each action.
    – **Human-out-of-the-loop**: Systems operate autonomously in defined domains without real-time human oversight.

    Common confusion and related terms

    – **Automation vs. autonomy**: Human-in-the-loop systems may be highly automated but are not fully autonomous, because critical decisions still involve human review.
    – **Decision support vs. decision automation**: With HITL, automation typically provides decision support (recommendations, scores, classifications), while the final decision authority remains with a human.
    – **Explainability**: HITL does not guarantee that an AI model is explainable, but it is frequently combined with explainability techniques so humans can understand and justify their approvals.

    Application in MES and AI integration (site context)

    When AI models are integrated with MES or other production systems, human-in-the-loop commonly means:

    – AI outputs (e.g., recommended parameters, predicted quality outcomes, suggested holds) are presented as advisory information.
    – MES workflows require a human to confirm, adjust, or reject these AI suggestions before they change master data, execution parameters, or product status.
    – Change control, access control, and audit trails record both the AI recommendation and the human decision as part of the electronic record.

    This pattern is often used to maintain clear decision accountability, support investigations, and align AI-enabled operations with existing procedures and regulatory expectations.

  • control recipe

    A control recipe is the fully specified, executable instance of a recipe used to run a particular batch, lot, or production order in an automated or semi-automated manufacturing system. The term is most commonly associated with ISA‑88 (S88) batch control, but the concept also appears in other recipe-driven production environments.

    What a control recipe includes

    In an S88-style model, a control recipe typically contains:

    • Identification information, such as recipe ID, batch ID, product code, and version
    • The selected master recipe reference (the standard definition of how to make the product)
    • Specific parameter values for this run, such as quantities, target setpoints, and timing
    • Selected equipment and units, consistent with the plant’s equipment model
    • Scheduling and sequencing information for the batch or order
    • Links to required materials, intermediates, and consumables
    • Required checks, holds, or approvals, such as quality checks or signoffs
    • Reporting requirements, such as which data must be logged as batch records

    The control recipe is what the control system (for example a batch engine, DCS, or MES) actually uses to orchestrate and monitor the production run.

    Role in operations

    Operationally, a control recipe connects the product definition to the plant floor:

    • It is created from a master recipe when a specific batch, lot, or order is planned.
    • It may be instantiated or managed by a batch management system, MES, or a dedicated recipe management system.
    • It provides the control system with all necessary details to execute, monitor, and log the process.
    • It often forms part of the electronic batch record or production history for compliance and traceability.

    In regulated or highly controlled environments, version control and approval workflows are commonly applied to control recipes and the parameters they contain.

    What a control recipe is not

    • It is not the generic product definition. That is usually the domain of a master recipe or product specification.
    • It is not the low-level equipment logic (for example PLC code or DCS configuration), although it references and drives that logic.
    • It is not the long-term production plan or finite schedule, but it may be generated as part of scheduling.

    Common confusion

    Control recipe vs. master recipe: In S88, a master recipe is the generalized, approved description of how to manufacture a product. A control recipe is a specific, executable instance of that master recipe for a particular run, with concrete parameter values and equipment selections.

    Control recipe vs. formula or BOM: A formula or bill of materials usually lists materials and quantities. A control recipe includes those, but also embeds the procedural steps, setpoints, and runtime instructions needed by the control system.

    Connection to ISA‑88 (S88)

    Within the ISA‑88 framework, control recipes are one of the defined recipe types. They support the separation of:

    • What is being made (product and master recipe)
    • How the plant equipment is organized (equipment model)
    • How a given batch is actually executed in the control system (control recipe)

    In practice, this separation allows plants to maintain standard master recipes while generating many different control recipes adapted to specific batch sizes, equipment availability, and order requirements.

  • manufacturing routing

    Manufacturing routing commonly refers to the defined path a part, assembly, or batch follows through production. It describes the sequence of operations, the work centers or resources involved, and often the planned setup, run, inspection, queue, or move steps needed to complete manufacturing.

    In practice, a routing is used to translate product requirements into executable shop floor work. It may appear in ERP, MES, or related systems as a list of operations such as cutting, machining, cleaning, inspection, assembly, test, and packaging, along with associated labor standards, resource assignments, or required documentation.

    A routing is not the same as a bill of materials. The bill of materials defines what components are needed, while the routing defines how and where the item is processed. A routing also does not usually include the full operator instruction content itself, although it may link to work instructions, control plans, quality checks, or digital travelers.

    What a manufacturing routing typically includes

    • Operation sequence or step numbers

    • Work centers, machines, departments, or external processors

    • Planned labor and machine time

    • Inspection or test points

    • Move, queue, or wait steps where applicable

    • References to documents such as travelers, work instructions, or specifications

    How it is used in operations systems

    Routing data supports scheduling, capacity planning, cost estimation, labor reporting, production dispatching, and execution tracking. In ERP, it is often used for planning and standard costing. In MES, it is often used to control operation-by-operation execution, collect production data, and maintain traceability of what steps were completed and in what order.

    In regulated or quality-sensitive manufacturing, routing may also define required hold points, sign-offs, inspection operations, or evidence collection steps. The exact level of detail varies by company, product risk, and system design.

    Common confusion

    Routing vs. traveler: A routing is the structured definition of the process path. A traveler is the job-specific record or packet that follows the work order and shows execution of that path.

    Routing vs. workflow: Routing usually refers to manufacturing process steps for a product. Workflow can be broader and may include approvals, document review, engineering changes, or other business processes.

    Routing vs. recipe: In batch industries, a recipe commonly defines formulation and process parameters. Routing is more often used for discrete manufacturing step sequences, though some environments use both together.

  • work-in-process (WIP)

    Work-in-process (WIP) commonly refers to material, components, subassemblies, or products that have entered the manufacturing process but are not yet finished goods. WIP sits between raw materials and completed products and includes anything currently undergoing value-adding steps such as machining, assembly, testing, or packaging.

    In industrial and regulated environments, WIP often appears in production records, MES dashboards, ERP inventory views, and shop-floor reports. It is typically tracked by quantity, location, order or batch, status, and sometimes by quality state or hold codes.

    What work-in-process includes

    WIP generally includes:

    • Parts and assemblies on machines, in work cells, or in staging areas between operations
    • Batches or lots that have started processing but have not completed all required steps
    • Units in inspection, test, rework, or queued for the next operation
    • Material in controlled storage that is tied to an open work order or batch record

    In accounting and inventory terms, WIP often carries both material and applied labor/overhead value. Operationally, it represents current production load and flow through the plant.

    What work-in-process does not include

    WIP typically does not include:

    • Raw materials or components that have not yet been released to a production order
    • Finished goods that have completed all defined manufacturing and quality steps
    • Maintenance spare parts or consumables not tied to a production order

    WIP in OT, MES, and ERP contexts

    Across shop-floor and business systems, WIP visibility is a common requirement:

    • MES: Tracks WIP at the operation or step level, often by unit, lot, or serial number, including status (e.g., in process, on hold, under inspection).
    • ERP/MRP: Represents WIP as an inventory and cost category linked to work orders, routings, and bills of material.
    • OT and control systems: Indicate real-time WIP presence at machines, lines, or buffers, often aggregated by counts or sensors.

    In regulated manufacturing, WIP tracking is frequently tied to traceability, electronic batch records, genealogy, and evidence of process execution.

    Operational uses of WIP

    Work-in-process information is commonly used to:

    • Monitor production flow, bottlenecks, and queue lengths
    • Align scheduling, capacity planning, and material release
    • Support traceability, including where specific units or lots are in the process
    • Calculate performance indicators such as lead time and inventory turns
    • Manage holds, deviations, and rework on partially completed product

    Common confusion

    • Work-in-process vs. work-in-progress: In many manufacturing and accounting contexts, these terms are used interchangeably. Some organizations reserve “work-in-progress” for non-manufacturing projects, but practices vary.
    • WIP vs. WIP limit: A WIP limit is a management rule (often used in lean or flow-based systems) that caps the amount of WIP allowed. WIP itself is the inventory; the WIP limit is a policy applied to it.
    • WIP vs. cycle time: WIP is how much is in process; cycle or lead time is how long it takes to move through the process. They are related but not the same metric.

    Link to MES advantages context

    In discussions of MES and integrated manufacturing systems, “work-in-process visibility” usually refers to the system’s ability to show where each order, lot, or unit is in the process, its current step, status, and any holds or quality issues affecting that WIP. This visibility depends on data integration, disciplined recording of production events, and consistent use of identifiers such as lots or serial numbers.