Glossary Tag: process monitoring

  • Disposition Cycle Time

    Disposition Cycle Time commonly refers to the total elapsed time from when an item, event, or record enters a disposition process to when a documented disposition decision is completed and released for action or closure.

    In manufacturing and quality workflows, it is most often used for nonconforming material, deviations, exceptions, holds, or inspection findings that require review and a formal decision such as use-as-is, rework, repair, return to supplier, or scrap. The term measures time through the decision process itself. It does not automatically include the full time to execute the rework or repair unless an organization defines it that way.

    What it includes

    • The start point is commonly the creation of the disposition-required record, hold, or NCR.
    • The end point is commonly the approval and recording of the disposition decision.
    • The measured time may include queue time, review time, routing time, and approval time across quality, engineering, production, supplier quality, or MRB participants.

    What it does not necessarily include

    • Physical correction work such as rework, repair, or replacement.
    • Final verification or reinspection after the disposition is executed.
    • Downstream order rescheduling, shipment impact, or customer communication unless specifically defined in the metric.

    Operational meaning

    Disposition Cycle Time is used as a process metric for how quickly an organization moves exceptions to a documented decision. In MES, QMS, ERP, or NCR workflows, it may be tracked by record type, product family, site, supplier, severity, or disposition path. It is often reviewed to identify bottlenecks in review boards, engineering approvals, or cross-functional handoffs.

    Example: if a nonconformance is opened on Monday and the formal disposition is approved on Thursday, the disposition cycle time is the elapsed time between those two events according to the site’s timing rules.

    Common confusion

    Disposition Cycle Time is often confused with resolution time or closure time. Resolution or closure time may extend beyond the disposition decision and include execution, verification, and record closure. It is also different from lead time for a production order, which covers a broader manufacturing process rather than an exception-handling step.

    It may also be confused with MRB turnaround time. MRB turnaround time is a narrower term when the disposition is specifically handled through a Material Review Board. Disposition Cycle Time can be broader and may apply even when no formal MRB meeting is involved.

  • time categories

    Time categories are standardized buckets used to classify how time is spent in a manufacturing or maintenance, repair and overhaul (MRO) environment. They provide a structured way to break total calendar time into meaningful segments, so that systems and analysts can measure utilization, performance, and causes of delay in a consistent way.

    In industrial operations, time categories are commonly applied to equipment, production lines, assets, or work orders. They appear in MES, CMMS/EAM, and analytics tools as coded states or event types that describe what is happening during a given time interval.

    Typical structure of time categories

    While naming varies by organization and standard, time categories often follow a hierarchy, for example:

    • Calendar / total time: 24/7 time, including both working and non-working periods.
    • Available vs. non-available time:
      • Available time: Time when an asset or resource is scheduled or allowed to run.
      • Non-available time: Time when it is not expected to run (e.g., holidays, long-term shutdowns).
    • Within available time:
      • Operating / productive time: Time spent executing value-adding production or maintenance work.
      • Planned loss: Scheduled activities that stop normal operation, such as planned maintenance, changeovers, inspections, or training.
      • Unplanned loss: Unscheduled events that reduce output, such as breakdowns, waiting for material, rework, or quality inspections triggered by issues.

    Each high-level time category can be further split into more detailed subcategories, such as specific types of downtime, setup, quality-related delays, or logistics-related waiting time.

    Operational use in systems and KPIs

    Time categories are used to:

    • Map MES or CMMS event codes (e.g., machine state, work order status) into standardized buckets.
    • Calculate KPIs such as OEE, non-productive time (NPT), utilization, and turnaround time (TAT) components.
    • Enable cross-site comparisons by normalizing different local codes into a shared time model.
    • Support root cause and bottleneck analysis by linking delays to clear, agreed categories.

    Standards such as ISO 22400 describe reference time category models for manufacturing KPI calculation. Organizations often use these as a starting point and extend them with sector-specific categories, for example detailed MRO turnaround states.

    Use in MRO and turnaround management

    In MRO, time categories are frequently applied at the work-package or asset level to break down turnaround time into events such as induction, inspection, teardown, repair, test, rework, waiting for parts, and customer hold. These detailed events are then aligned with more generic time categories in plant-wide KPI models so that MRO performance can be compared to other manufacturing operations.

    Common confusion

    • Time categories vs. event codes: Event codes are the raw labels or status values recorded by systems (for example, “Setup”, “Waiting for QC”). Time categories are the standardized buckets those events are mapped into for analysis.
    • Time categories vs. shifts or calendars: Shifts and calendars define when work is planned. Time categories describe what actually happened during that time.
    • Time categories vs. KPIs: KPIs are metrics (for example, OEE or TAT). Time categories are an input structure that supports calculating and interpreting those metrics.
  • TEEP

    TEEP stands for Total Effective Equipment Performance. In industrial and manufacturing environments it is a utilization metric that extends OEE by including all calendar time, not just planned production time.

    Core definition

    TEEP commonly refers to the percentage of total calendar time that an asset, line, or plant actually uses to produce good product at the target rate. A typical high-level formula is:

    • TEEP = OEE × Loading

    Where, in many TPM and ISO 22400 style interpretations:

    • OEE (Overall Equipment Effectiveness) measures effectiveness during planned production time only (availability, performance, and quality losses within that window).
    • Loading (sometimes called utilization) measures what share of total calendar time is designated as planned production time.

    Under this view, TEEP expresses how close the equipment is to its theoretical maximum output if it were available and scheduled to run 24 hours a day, 7 days a week.

    Operational meaning in manufacturing

    In practice, TEEP is used to provide visibility into both:

    • How intensively equipment is scheduled (loading across shifts, weekends, holidays).
    • How effectively equipment runs when scheduled (the OEE components of availability, performance, and quality).

    On many shop floors, TEEP appears in performance dashboards, MES or operations intelligence systems as a high-level capacity and utilization indicator. Typical usage includes:

    • Comparing effective utilization across lines, plants, or assets that run on different shift patterns.
    • Assessing whether to add shifts, re-balance loading, or pursue continuous improvement on existing shifts.
    • Separating business decisions about scheduling and demand from technical or process losses inside scheduled time.

    Because TEEP is based on calendar time, it is sensitive to how an organization defines total time, planned downtime, and non-production days. These definitions need to be documented in systems and reports, especially in regulated environments.

    Relationship to OEE and ISO 22400

    In many TPM-style implementations, TEEP is described alongside OEE as part of a family of equipment-related KPIs. ISO 22400 series standards describe related concepts such as availability, utilization, and other manufacturing performance indicators, but terminology and formulas may differ from legacy TPM practices.

    Where both TPM-style OEE and ISO 22400 terminology are used, organizations commonly:

    • Map TEEP clearly to the underlying ISO 22400 metrics (for example, which time categories are included in loading and availability).
    • Document any alternate formulas or naming used locally so that system reports and audit evidence remain consistent.

    What TEEP includes and excludes

    In its typical manufacturing usage, TEEP:

    • Includes all calendar time for the measurement period (for example, 24×7 over a week or month).
    • Includes both production and non-production periods when calculating loading.
    • Excludes any notion of theoretical design limits beyond the chosen reference speed and quality assumptions already embedded in OEE.

    TEEP does not by itself distinguish between different reasons for low utilization (such as low demand, maintenance strategy, staffing limits, or technical downtime). Those factors are usually tracked in supporting loss or time models linked to OEE and scheduling.

    Common confusion

    • TEEP vs. OEE: OEE looks only at effectiveness during planned production time. TEEP extends this by considering how much of total calendar time is actually planned and used for production. High OEE with low TEEP often indicates under-loading or limited shift patterns rather than poor equipment performance.
    • TEEP vs. utilization or capacity utilization: Some plants use “utilization” to mean loading, and others use it to mean something closer to TEEP. To avoid confusion, it is helpful to specify the exact formula used for TEEP and any related utilization metric in performance reports and MES configurations.

    Derived-from context: TPM-style and ISO 22400 usage

    In TPM-style OEE environments, TEEP is often presented as a legacy or local KPI that complements OEE by revealing calendar-based capacity use. When organizations adopt ISO 22400 terminology, they frequently keep TEEP as an internal indicator while explicitly documenting how its formula maps to the standard’s time and performance definitions so that reports, system integrations, and audits remain clear.

  • First-Pass Yield (FPY)

    First-Pass Yield (FPY) is a quality and performance metric that measures the percentage of units that successfully pass through a process or operation the first time, without requiring any rework, repair, or additional processing and without being scrapped.

    In industrial and regulated manufacturing environments, FPY is commonly calculated at the operation, work center, line, or process-step level. It focuses on whether each unit meets all specified requirements and inspection criteria in its first pass through that defined scope.

    How First-Pass Yield is commonly calculated

    A typical FPY calculation is:

    • FPY = (Number of good units out of the process on first attempt) ÷ (Total units entering the process)

    “Good units” in FPY explicitly excludes any items that required rework, repair, extra processing, or concession, even if they were eventually accepted. Scrapped units are also excluded from the numerator.

    Where FPY is used in manufacturing

    • Process monitoring: Tracking FPY at key operations (e.g., machining, coating, assembly, test) to understand process performance.
    • Quality management: Using FPY to help identify processes that generate nonconformances, rework, or concessions.
    • MES and shop-floor systems: Recording pass/fail results by operation and computing FPY by part, work order, cell, shift, or supplier.
    • Continuous improvement: Trending FPY as part of yield, scrap, and cost-of-poor-quality analysis.

    What First-Pass Yield includes and excludes

    • Includes: Units that meet all requirements in their first complete pass through the specified process scope.
    • Excludes from the numerator:
      • Units that fail inspection and are reworked, repaired, or re-tested.
      • Units that are scrapped.
      • Units accepted only under deviation, waiver, or concession (depending on local definition and procedures).

    The exact treatment of units accepted under deviation or concession should be defined in internal procedures to keep FPY reporting consistent.

    FPY vs related yield metrics

    • First-Pass Yield (FPY): Focuses on a single process or operation and counts only units that pass on their first attempt.
    • Rolled Throughput Yield (RTY): Multiplies the FPY of a sequence of operations to estimate the probability that a unit passes through all those steps without any rework.
    • Overall yield: Often refers to final output versus initial input, including units recovered after rework; this is usually more generous than FPY.

    Common confusion

    • FPY vs overall yield: Overall yield can count reworked units as good, while FPY counts only those that never needed rework.
    • FPY vs defect rate: Defect rate measures the frequency of defects, while FPY measures the proportion of units that clear a process without any defects requiring correction.

    Operational context in regulated environments

    In regulated or highly documented operations, FPY is often linked to digital records in MES, QMS, or ERP systems. Pass/fail outcomes at each operation, nonconformance records, and rework transactions provide the data needed to calculate FPY and to support audits or process reviews without implying any certification or compliance status.

  • Busy Time

    Busy time commonly refers to the period during which a manufacturing resource is actively performing assigned work. It is used in production, maintenance, and capacity analysis to distinguish productive engagement from idle, waiting, or down states.

    What busy time includes

    Depending on the context and data model, busy time typically includes:

    • Active machine processing, such as cutting, molding, filling, or testing parts or batches.
    • Setup and changeover work that is planned and required to support production runs.
    • Direct operator work, such as assembly, inspection, adjustment, or supervised automated runs.
    • Planned maintenance work when the tracked resource is a maintenance team or technician.

    Busy time is usually measured at the level of a specific resource, such as a machine, production line, workstation, operator, or work center.

    What busy time excludes

    Busy time normally excludes:

    • Idle or waiting time, for example when a machine is ready but waiting for material, tooling, or instructions.
    • Unplanned downtime, such as breakdowns, IT/OT outages, or safety stops.
    • Planned downtime, such as scheduled breaks, shutdowns, or holidays, unless the model explicitly counts these separately.
    • Non-utilized capacity where a resource is available but not loaded with work.

    Operational use in manufacturing systems

    In industrial operations and regulated environments, busy time appears in several places:

    • MES and OT systems: Machine states (such as Running, Setup, or In Cycle) are aggregated into busy time for performance analysis.
    • OEE and utilization metrics: Busy time is a key input for calculating utilization, availability, and overall equipment effectiveness, by comparing it to total calendar or planned time.
    • Capacity planning: Planners compare historical busy time to available capacity to identify constraints, load balancing needs, or scheduling limits.
    • Labor tracking: In time and attendance or electronic batch records, operator busy time against specific orders, batches, or tasks is used for costing, traceability, and compliance documentation.

    Relationship to other time categories

    Busy time is often one of several standardized time categories, such as:

    • Available time: The period a resource is scheduled or technically able to run.
    • Busy (productive) time: Subset of available time when the resource is performing assigned work.
    • Idle or standby time: Available but not actively working.
    • Downtime: Not available due to faults, changeovers, or planned shutdowns, depending on how the model is defined.

    Exact boundaries between these categories depend on the site’s data model and standards but should be documented consistently in MES, SCADA, or reporting tools.

    Common confusion

    Busy time is sometimes confused with:

    • Utilization: Utilization is usually a percentage (busy time divided by available time). Busy time is the absolute time value itself.
    • Cycle time: Cycle time refers to the time to complete one unit or batch. Busy time is the aggregate period the resource is actively working, which may cover many cycles and tasks.
    • Run time: Some systems define run time as only in-cycle processing, while busy time may also include setup, adjustments, or inspections. The local definition should clarify whether these are the same or different.

    Typical example in a regulated plant

    On a filling line in a regulated facility, busy time might include the minutes the line is filling product, performing in-process checks, and running validated cleaning cycles. Time waiting for QA release, waiting for components, or under corrective maintenance would be tracked separately as waiting or downtime, not as busy time.

  • Entity binding

    Entity binding commonly refers to the act of linking one defined entity in a software or data model to another so the relationship is explicit, controlled, and usable by the system. In manufacturing and regulated operations, an entity may be a material, batch, equipment asset, document, user, work order, operation, specification, or quality record.

    The term usually describes a structured association, not just a text reference. For example, binding a work order to a routing step, a serialized unit to its genealogy record, or a quality event to the affected lot means the system recognizes that relationship as data. That allows the relationship to be queried, validated, tracked, and reused across workflows.

    What it includes

    • Linking records across MES, ERP, QMS, LIMS, PLM, or related systems

    • Associating a digital object with a master data entity, such as binding a form field to a material, equipment ID, or specification

    • Maintaining references that support workflow logic, traceability, reporting, and audit trails

    What it does not necessarily mean

    Entity binding does not by itself mean data synchronization, data replication, or full system integration. A bound relationship may exist inside one application or across multiple systems, but the term focuses on the association itself. It also does not necessarily mean a physical connection between assets or devices.

    Operational meaning

    In day-to-day operations, entity binding appears wherever systems need context. A shop-floor transaction may be bound to a specific operator, machine, and lot. An electronic batch or device history record may bind inspection results to a step, a characteristic, and the unit produced. These bindings help preserve context so records remain consistent as data moves through production, quality, and review processes.

    Common confusion

    Entity binding is often confused with data mapping, master data management, or API integration. Data mapping defines how fields correspond between structures. Integration moves or exchanges data between systems. Master data management governs authoritative business entities. Entity binding is narrower: it is the explicit relationship between entities or records, whether inside one system or across connected systems.

    In some software disciplines, binding can also refer to binding a user interface element to a data source or binding program objects at runtime. Those meanings are related, but in industrial software and manufacturing systems, the practical meaning is usually the controlled association of business or operational entities.

  • interface

    Operational meaning

    In industrial and manufacturing contexts, an **interface** is a defined point of interaction where two parties exchange data, commands, or services. Those parties can be:

    – Software systems (e.g., MES and ERP)
    – Hardware and software (e.g., PLCs and SCADA clients)
    – A system and a human user (e.g., HMI screens)

    An interface normally has agreed rules for how information is structured, transmitted, validated, and acknowledged.

    Types of interfaces in manufacturing systems

    Common interface types include:

    – **System-to-system interfaces**: Connections between applications such as MES, ERP, LIMS, WMS, historians, and quality systems. These often use APIs, message queues, file drops, or database views.
    – **Human-machine interfaces (HMI)**: Screens or panels that operators use to monitor and control equipment or processes.
    – **Hardware interfaces**: Electrical, network, or fieldbus connections that define how devices communicate (e.g., Ethernet/IP, Profibus, OPC UA transport bindings).
    – **Data interfaces**: Structured schemas, tables, messages, or tags that define which data is exposed and in what format.

    In regulated environments, interfaces are usually documented with specifications that describe data elements, triggers, error handling, and any constraints.

    Use in MES–ERP and balance reconciliation

    On this site, **interface** often refers to the technical and logical connection between MES and ERP used to exchange:

    – Material movements, consumption, and production quantities
    – Inventory balances and adjustments
    – Work order, batch, or process order status
    – Quality results and usage decisions

    Discrepancies between MES and ERP balances commonly arise from interface behavior such as:

    – Timing or latency in data transfer
    – Partial, failed, or retried messages
    – Mapping mismatches between units, locations, or material IDs
    – Differences in business rules on each side of the interface

    In this context, investigating issues typically involves reviewing the interface specification, logs, message payloads, and reconciliation rules, without assuming either system is inherently “right.”

    Boundaries and exclusions

    Within this domain, **interface** generally:

    – **Includes**: The defined connection point and rules for interaction (protocols, message formats, API contracts, HMI layouts as defined interaction surfaces).
    – **Excludes**: The entire underlying system architecture, business process design, or organizational handoffs, even though those may influence how interfaces are designed.

    When discussing integration, **interface** refers to how systems exchange information, not to the broader project governance or process ownership.

    Common confusion and related terms

    – **Interface vs. integration**: The interface is the technical connection and contract (APIs, messages, schemas). Integration is the overall solution that uses one or more interfaces plus business logic, scheduling, monitoring, and support processes.
    – **Interface vs. user interface (UI)**: A user interface is a specific type of interface focused on human interaction. In many OT/IT discussions, the unqualified term **interface** more often refers to system-to-system connections unless UI/HMI is explicitly mentioned.
    – **Interface vs. protocol**: A protocol defines how data is transmitted over a network. An interface uses one or more protocols and adds application-level structure and semantics (e.g., specific MES–ERP message types).

  • data lake

    A data lake is a centralized storage environment that holds large volumes of data from many sources in their raw or minimally processed form. It is typically implemented on scalable file or object storage and is used as a foundation for analytics, reporting, data science, and AI.

    Key characteristics

    In industrial and manufacturing contexts, a data lake commonly:

    • Ingests data from OT systems (PLCs, historians, SCADA), MES, ERP, QMS, LIMS, and other applications
    • Stores structured, semi-structured, and unstructured data together (for example, sensor time series, batch records, PDFs, and logs)
    • Preserves data in its original format rather than enforcing a single schema on write
    • Supports multiple downstream uses, such as dashboards, advanced analytics, machine learning, and ad hoc investigations
    • Is often part of an Industry 4.0 or enterprise analytics architecture, alongside data warehouses and operational databases

    How a data lake is used operationally

    Within manufacturing operations, a data lake commonly serves as:

    • Central collection point for high-volume sources like machine telemetry, quality measurements, and event logs
    • Historical repository that retains long time horizons of data to support trend analysis, process optimization, and investigation of deviations
    • Integration layer where data from MES, ERP, maintenance, and laboratory systems can be combined for cross-functional analytics
    • Source for curated data sets that are refined and then exposed to BI tools, data warehouses, or model training pipelines

    In regulated environments, the data lake may need to support traceability, data lineage, controlled access, and retention rules, but it does not by itself constitute a validated system of record.

    What a data lake is not

    • It is not the same as a transactional database used by MES, ERP, or SCADA for day-to-day operations.
    • It is not automatically governed, curated, or quality-checked; separate data management processes are required.
    • It is not necessarily a data warehouse, although a warehouse may be built on top of or sourced from a data lake.

    Common confusion

    • Data lake vs data warehouse: A data warehouse typically stores cleaned, modeled, and structured data optimized for reporting and standardized analytics. A data lake stores raw or lightly processed data and can support many different schemas and use cases.
    • Data lake vs data lakehouse: A data lakehouse is a newer architectural pattern that combines data lake-style storage with data warehouse-like management and query features. A data lake on its own does not guarantee those warehouse characteristics.

    Relation to Industry 4.0 architectures

    In Industry 4.0 architectures, the data lake often sits above plant-floor control systems and MES, collecting data from multiple sites and systems. It provides a shared data foundation for enterprise analytics, predictive maintenance models, digital twins, and cross-plant performance analyses, while operational control and compliance records remain in their source systems.

  • data lineage

    Core meaning

    Data lineage is the documented life cycle of data, showing where it originated, how it moved between systems, and how it was transformed or aggregated at each step. It provides an end‑to‑end view of data flows from source to final use.

    In industrial and manufacturing environments, data lineage commonly refers to the traceable path of data used for production control, quality records, and KPI reporting across OT and IT systems.

    Key elements of data lineage

    Data lineage typically captures:

    – **Data sources**: originating systems or devices (e.g., PLCs, sensors, MES, LIMS, ERP).
    – **Data movements**: interfaces and integrations (batch jobs, message queues, APIs, ETL/ELT tools).
    – **Transformations and calculations**: rules applied to data (filtering, unit conversion, KPI formulas, aggregations).
    – **Storage locations**: databases, data lakes, historians, and reporting data models.
    – **Downstream uses**: dashboards, reports, regulatory submissions, and audit trails.

    The lineage may be represented as diagrams, metadata records, or automatically generated maps in data catalog or observability tools.

    Use in industrial and regulated environments

    In manufacturing operations, data lineage is commonly used to:

    – Show how **shop-floor data** (machine states, production counts, process parameters) flows into MES, historians, and analytics tools.
    – Demonstrate how **quality and batch data** are compiled from multiple sources for electronic batch records or deviation investigations.
    – Trace the origin of **KPI values** (e.g., OEE, yield, scrap rate), including which tags, transactions, and calculations produced them.
    – Support **auditability and investigations**, allowing teams to reconstruct which data and versions of logic were in effect at a given time.

    Lineage information is often maintained as part of a broader metadata, data governance, or validation framework, especially where regulations require evidence that reported data is accurate, complete, and traceable.

    Boundaries and what data lineage is not

    Data lineage:

    – **Is**: a description of the path and transformations of data.
    – **Is not**: the business meaning of the data (this is usually handled by data definitions or a data catalog).
    – **Is not**: product or material traceability, although both can be related.
    – **Is not**: a guarantee of data quality; it supports quality assessment by making sources and transformations visible.

    Lineage records may reference related concepts such as data ownership, data quality rules, or system validation, but these are distinct governance elements.

    Common confusion and related terms

    – **Data lineage vs. data provenance**: In many IT and analytics contexts, these terms are used interchangeably. Some groups use *provenance* more narrowly for proof of origin and custody at the individual record level, while *lineage* emphasizes the overall flow across systems and processes.
    – **Data lineage vs. traceability**: In manufacturing, *traceability* usually refers to tracking materials, lots, or products through the physical process. *Data lineage* tracks information objects and transformations, not physical items, though both may be linked in investigations.
    – **Data lineage vs. data logging or history**: Historians and logs store time‑series or transactional records. Lineage describes **how** those records got there and how they are later used or transformed.

    Being explicit about these distinctions helps avoid assuming that material traceability or the existence of a history automatically provides full data lineage for reporting or compliance.

    Site context: MES data and KPI trust

    When discussing trust in MES data for KPI reporting, data lineage commonly refers to:

    – Documented mapping from **source tags, events, and records** to MES objects and KPI data models.
    – Clear visibility of **all calculations and filters** applied between raw events and final KPIs.
    – Traceable **system hops** (e.g., PLC → SCADA → MES → data warehouse → BI tool).
    – Version awareness of **integration logic and KPI formulas** at the time a report was generated.

    In this context, data lineage supports the ability to demonstrate how each reported value was produced and to reconcile reported KPIs back to underlying operational and physical records.