Connect981 – Content Dev

Glossary Tag: process monitoring

  • organizational interoperability

    Organizational interoperability commonly refers to the ability of different organizations, business units, or functions to work together effectively toward shared objectives. It focuses on aligning processes, responsibilities, decision rights, and governance so that information and capabilities provided by technical systems can actually be used in a coordinated way.

    What organizational interoperability includes

    In industrial and manufacturing environments, organizational interoperability typically involves:

    • Aligned roles and responsibilities so that operations, quality, maintenance, IT, and OT teams know who does what when data crosses boundaries.
    • Compatible processes and workflows across departments or sites, so that handoffs (for example, between MES, ERP, and QMS users) are clear and consistent.
    • Governance and decision-making structures that define how changes to systems, data, or procedures are requested, evaluated, approved, and communicated.
    • Common objectives and KPIs that ensure different organizations or functions are optimized toward the same performance, quality, and compliance outcomes.
    • Agreements and policies such as service-level expectations, escalation paths, and data ownership rules between internal functions or external partners.

    Organizational interoperability is often described as the highest of four interoperability layers: technical, syntactic, semantic, and organizational. It builds on the lower layers by ensuring that people, teams, and institutions are structured to take advantage of interoperable data and systems.

    Operational meaning in manufacturing

    In regulated manufacturing, organizational interoperability shows up in practical ways such as:

    • Cross-functional change control boards that include IT, OT, quality, and production for system or process changes.
    • Standardized work instructions that align how operators, quality inspectors, and maintenance technicians use MES and related tools.
    • Coordinated responses to deviations or nonconformances, where responsibilities span multiple systems and departments.
    • Shared governance for master data that impacts multiple plants or business units.

    Without organizational interoperability, technical integrations between systems (for example, between ERP and MES) may exist, but handoffs between teams, ownership of tasks, and decision processes remain fragmented.

    Common confusion

    • Versus technical interoperability: Technical interoperability focuses on systems being able to connect and exchange data. Organizational interoperability focuses on people, structures, and governance using that connectivity in a coordinated way.
    • Versus semantic interoperability: Semantic interoperability ensures common meaning of data elements. Organizational interoperability ensures that, even with common meaning, the right teams know how to act on the information.

    Relation to the four interoperability layers

    Organizational interoperability depends on and extends the other interoperability types. Technical, syntactic, and semantic interoperability enable accurate data exchange, while organizational interoperability ensures that this exchange fits into clear processes, responsibilities, and governance across departments, sites, or external partners.

  • material yield

    Core meaning

    Material yield commonly refers to the proportion of input material that exits a process as conforming, saleable product rather than scrap, rework, or other losses. It is typically expressed as a percentage, ratio, or cost-based metric.

    In manufacturing and industrial operations, material yield is used to understand how efficiently raw and intermediate materials are converted into finished goods, considering process losses, quality defects, and handling losses.

    Typical calculation approaches

    Material yield can be calculated in several ways, depending on data availability and how the site defines waste:

    – **Quantity-based yield**
    – (text{Material Yield (qty)} = frac{text{Good output quantity}}{text{Input material quantity}})
    – Often used at line, work center, or batch level.

    – **Mass or volume-based yield**
    – Uses mass (kg, lb) or volume (L, m³) instead of unit counts.
    – Common in process industries where formulation and losses by weight/volume matter.

    – **Cost-based yield**
    – (text{Material Yield (cost)} = frac{text{Material cost in conforming output}}{text{Total material cost consumed}})
    – Links yield directly to material waste cost and is frequently used in KPI dashboards.

    Sites may include or exclude rework, by-products, or recoverable material depending on accounting rules and regulatory constraints. For this reason, material yield definitions are often documented explicitly in procedures or KPI definitions.

    Use in industrial and regulated workflows

    In regulated and complex manufacturing environments, material yield is:

    – **Tracked at multiple levels**: by part or SKU, work order, batch/lot, process step, line, and plant.
    – **Linked to quality data**: good vs. nonconforming units, scrap reasons, and rework routes from QMS or LIMS.
    – **Integrated across systems**: input quantities and costs from ERP or inventory, process quantities from MES/SCADA, and disposition information from QMS or serialization systems.
    – **Time-bounded**: reported per shift, day, campaign, or batch to support investigations and continuous improvement.

    Material yield is often included in KPI sets alongside scrap rate, rework rate, and overall equipment effectiveness (OEE) to provide a view of material efficiency.

    Boundaries and what it is not

    – **Includes**:
    – Conforming output compared to all material consumed for that output (including start-up, changeover, and in-process losses when so defined).
    – Losses due to scrap, overfill, spillage, evaporation or reaction losses (when material balance is modeled), and non-recoverable rework.

    – **Common exclusions (when defined separately)**:
    – Energy efficiency, labor productivity, or equipment utilization (these are distinct performance dimensions).
    – Pure yield-loss causes that are treated as separate KPIs (e.g., overfill, giveaway, or packaging damage), unless the local definition consolidates them.

    Because definitions vary, material yield figures from different plants or systems are not always directly comparable without understanding the underlying rules and data sources.

    Common confusion and related terms

    – **Yield vs. scrap rate**:
    – Material yield focuses on the proportion of material that becomes conforming product.
    – Scrap rate focuses on the proportion of material or units that are discarded.
    – They are mathematically related but framed from different perspectives.

    – **Yield vs. first pass yield (FPY)**:
    – FPY measures how many units pass a process without rework.
    – Material yield can count material that eventually becomes conforming product after rework, depending on the site definition.

    – **Yield vs. recovery**:
    – In some process industries, **recovery** is used for how much desired substance is obtained from a raw feed.
    – Material yield may be a broader metric across the full manufacturing chain, not just a single separation or reaction step.

    When reporting or comparing metrics, it is common practice to specify whether rework, by-products, and recoverable material are included in the yield calculation.

    Site-context application: material waste KPIs

    In the context of KPIs for material waste reduction:

    – Material yield is used as a **rate-based KPI** that complements scrap and rework rates.
    – Plants often derive both **quantity-based** and **cost-based** material yield, so that yield losses can be tied to actual material cost and regulatory constraints (e.g., restricted or serialized lots).
    – MES, ERP, and QMS integration enables tracking of material yield by part, routing step, and batch, supporting root-cause analysis when yield losses occur.

    In regulated environments, consistent and clearly documented definitions of material yield are important so that reported KPIs remain traceable, reproducible, and suitable for audit or review.

  • Downtime

    Downtime is any period when production equipment, a manufacturing line, or a supporting system is not performing its intended work and is unable to produce output. In an operational context, downtime is measured as elapsed time during which a resource is unavailable for planned production or processing.

    Downtime can include:

    • Unplanned downtime: unexpected stops caused by failures, breakdowns, errors, or other unanticipated events.
    • Planned downtime: scheduled stops such as preventive maintenance, changeovers, inspections, or setup activities.

    Manufacturing Execution Systems (MES) typically track downtime events with timestamps, duration, affected assets, and coded reasons so that teams can identify patterns, analyze root causes, and adjust operations or maintenance plans. Downtime data is often used in performance metrics such as Overall Equipment Effectiveness (OEE).

  • Raw Signal

    Raw signal commonly refers to unprocessed data or measurements captured directly from sensors, instruments, or equipment, before any filtering, scaling, aggregation, or interpretation has been applied.

    What a raw signal includes

    In industrial and manufacturing environments, raw signals typically include:

    • Analog readings from field devices, such as temperature, pressure, vibration, or flow sensors
    • Digital states from equipment, such as on/off, open/closed, or fault bits
    • Electrical waveforms or time-series data captured by PLCs, data historians, or condition monitoring systems
    • Unprocessed network or protocol frames captured from OT or industrial communication buses

    The raw signal is usually stored as-is, using engineering units or device counts (for example, voltage levels, ADC counts, or raw integer register values), depending on the source device and interface.

    What a raw signal is not

    A raw signal is not:

    • A calibrated, scaled, or validated measurement (for example, a temperature value adjusted for sensor drift)
    • A derived metric or KPI, such as OEE, cycle time, or scrap rate
    • A summarized or aggregated value, such as hourly averages or batch totals
    • A contextualized event record, such as a quality deviation or maintenance work order

    Operational use in manufacturing systems

    Raw signals are the starting point for many OT and IT workflows, including:

    • Real-time control in PLCs and DCS, which read raw sensor values to make control decisions
    • Condition monitoring and predictive maintenance, where vibration or current signals are analyzed for anomalies
    • Data collection in historians and IIoT platforms, storing raw time-series data for later analysis
    • Transformation layers feeding MES, quality, and ERP systems, where raw signals are converted into counts, states, or events aligned with ISA-95 style models

    In regulated or high-compliance environments, retaining or being able to reconstruct the raw signal can be important for traceability, investigations, and independent verification of derived values or decisions.

    Processing and transformation

    Raw signals often go through one or more processing steps before they are used in operations, reporting, or compliance records:

    • Filtering and cleaning: Removing noise, invalid readings, or communication artifacts
    • Scaling and calibration: Converting counts or voltages into engineering units with calibration factors
    • Feature extraction: Turning high-frequency signals into features like peaks, RMS, or frequencies
    • Contextualization: Linking processed values to equipment, products, batches, operators, and time windows

    After these steps, the signal is no longer considered raw; it becomes processed data or derived information used by MES, quality systems, or analytics tools.

    Common confusion

    • Raw signal vs raw data: Raw signal is often used when the data directly reflects a physical measurement or real-time equipment state. Raw data can be broader and may include unstructured logs, files, or text not tied to a specific physical sensor.
    • Raw signal vs event: A raw signal is continuous or sampled data over time. An event is typically a discrete occurrence derived from the signal, such as a limit exceeded, a machine start, or a fault code logged.
    • Raw signal vs KPI: KPIs (such as OEE or yield) are calculated metrics built from multiple processed data points. They never refer to raw signal values.

  • data catalog

    A data catalog is a curated, searchable inventory of data assets that describes where data lives, what it contains, how it is defined, and how it should be used. In industrial and manufacturing environments, a data catalog typically covers data from OT systems (such as PLCs, historians, MES) and IT systems (such as ERP, LIMS, QMS, and BI tools).

    Key characteristics

    In this context, a data catalog commonly includes:

    • Registered data sources: Connections to databases, historians, data lakes, message buses, files, and application APIs used in operations.
    • Data asset listings: Tables, views, tags, KPIs, reports, and datasets with basic technical metadata (names, types, locations).
    • Business and semantic definitions: Plain-language descriptions, data owners, related processes, and links to standards or models such as ISA-95 or ISO 22400.
    • Lineage and relationships: How data is transformed, aggregated, and combined across systems, including how KPIs are calculated and from which sources.
    • Quality and usage information: Optional indicators such as update frequency, typical consumers, and known data quality constraints.

    Role in industrial and regulated environments

    In regulated manufacturing, a data catalog supports consistent understanding and use of operational and quality data across sites and systems. It can help:

    • Document definitions and formulas for KPIs, including those that are not directly defined in a standard such as ISO 22400.
    • Clarify which system is the source of record for specific measurements (for example, batch genealogy, equipment state, or test results).
    • Support audits and reviews by making data origins, transformations, and meanings more transparent.
    • Align MES, ERP, QMS, and analytics tools by providing a shared reference for data element names and meanings.

    Operational usage

    Operators and engineers may use a data catalog indirectly through analytics tools that query cataloged datasets. Data stewards, system owners, and BI teams typically use the catalog directly to:

    • Register new data sources from production lines, labs, and supply chain systems.
    • Document or revise metric definitions and link them to underlying data elements.
    • Search for existing data suitable for new reports, dashboards, or models.
    • Review lineage when troubleshooting discrepancies between systems, such as differences between MES and ERP production quantities.

    Common confusion

    • Data catalog vs data dictionary: A data dictionary usually describes the structure and fields of a specific database or application. A data catalog spans many systems and focuses on discoverability, governance, and cross-system definitions.
    • Data catalog vs data lake or data warehouse: A data lake or warehouse stores data. A data catalog describes data, including data that may reside in multiple lakes, warehouses, or source systems.
    • Data catalog vs master data management (MDM): MDM manages core reference data (such as material, equipment, or supplier records). A data catalog documents where all kinds of data reside and what they mean; it may reference MDM systems but does not replace them.

    Link to KPI and standards context

    When plants use KPIs that do not map directly to standards such as ISO 22400, a data catalog can record the KPI name, intent, formula, and data sources, and explicitly note how it relates to or diverges from standard definitions. This helps avoid ambiguity in cross-site comparisons, long-term system integration, and audits.

  • data model

    A data model is a defined structure that describes how data is organized, named, related, and constrained within and across systems. It specifies the entities (such as orders, lots, serial numbers, equipment, and test results), the attributes of those entities, and the relationships between them.

    In manufacturing and regulated operations

    In industrial and regulated environments, a data model commonly refers to the way production, quality, maintenance, and business data are structured across systems such as MES, ERP, QMS, LIMS, and data historians. It typically includes:

    • Core entities, for example work orders, batches/lots, serialized units, materials, equipment, and operators
    • Key identifiers, such as order numbers, lot IDs, serial numbers, and equipment IDs
    • Relationships and genealogy, such as which components went into which finished unit, or which tests were run on which batch
    • Rules and constraints, for example one serial number per physical unit or required links between a test record and a lot
    • Logical groupings used for reporting and KPIs, such as how shift, line, and product family are associated to events and measurements

    A data model may be documented as diagrams, database schemas, or configuration in integration tools. It can exist at different levels of abstraction, such as:

    • Conceptual data model: High-level view of the main entities and relationships, often used with business and quality stakeholders.
    • Logical data model: More detailed description of attributes and relationships, independent of specific database technology.
    • Physical data model: The actual implementation in databases, message schemas, or APIs used by systems.

    Operational relevance

    In daily operations, a clear data model supports:

    • Traceability and genealogy, by defining how order, lot, and serial keys connect production events and quality records
    • System integration, by aligning identifiers and relationships across MES, ERP, QMS, historians, and analytics platforms
    • Reporting and KPIs, by specifying which data sources and joins underlie each calculation and how results map back to units, equipment, or time periods
    • Change control, by allowing controlled updates to structures and relationships when processes or systems change

    Common confusion

    • Data model vs. database: A database is the implemented storage system; the data model is the design that describes what is stored and how it is related.
    • Data model vs. data schema: A schema is often the concrete, technical representation (for example tables and columns). The data model includes the schema but also the conceptual definitions, rules, and intended use of the data.
    • Data model vs. process model: A process model describes workflow steps and sequences of activities. A data model describes the information related to those activities and how that information is linked.

    Audit and compliance context

    In audits and investigations, a well-defined data model helps show how high-level metrics and reports can be traced back to underlying records. For example, it can demonstrate how KPI values are linked to specific orders, lots, serial numbers, test results, and system-of-record transactions, and how those links are preserved through integrations and data transformations.

  • ETL

    ETL, short for Extract, Transform, Load, is a structured process used to move data from one or more source systems into another system, typically a data warehouse, analytics platform, or reporting database. It is widely used in manufacturing and industrial environments to integrate data across MES, ERP, QMS, historians, and other OT/IT systems.

    Core components of ETL

    The ETL process is commonly described in three stages:

    • Extract: Reading or pulling data from source systems such as MES, ERP, QMS, LIMS, SCADA, historians, PLC logs, or spreadsheets. Extraction focuses on reliably accessing data in its original formats and structures.
    • Transform: Cleaning, standardizing, validating, and reshaping the extracted data. This can include mapping identifiers (for example, order, lot, and serial numbers), converting units of measure, joining datasets, applying business rules, and deriving calculated fields such as KPIs.
    • Load: Writing the transformed data into a target system, such as a data warehouse, data mart, or analytics database, in a structure optimized for querying, reporting, or integration with other tools.

    Use in manufacturing and regulated operations

    In industrial and regulated environments, ETL commonly refers to the controlled logic and workflows that integrate data across production, quality, maintenance, and business systems. Typical uses include:

    • Building integrated production and quality history across MES, QMS, and ERP using shared keys like order, lot, and serial numbers.
    • Preparing clean, repeatable datasets for KPIs such as OEE, scrap, rework, cycle time, or deviation rates.
    • Linking process historian data to batch records and serialized units to support traceability and investigations.
    • Creating standardized data models for audit-ready reporting and reproducible analytics.

    In regulated settings, ETL logic is often controlled under change management, with documented mappings, validation checks, and versioning so that reported values can be reproduced and traced back to their sources.

    Operational characteristics

    ETL workflows can run in different modes:

    • Batch ETL, where data is processed on a schedule (for example, hourly or daily) and loaded in bulk.
    • Near real-time or streaming ETL, where data is continuously or frequently updated to support up-to-date dashboards and alerts.

    ETL is often implemented using dedicated ETL tools, scripting languages, or integration platforms. In modern architectures, similar functionality may be described as data pipelines, data integration flows, or ELT (Extract, Load, Transform) when transformations happen mainly inside the target data platform.

    Common confusion

    • ETL vs. ELT: ETL applies transformations before loading into the target system. ELT loads raw data first and performs most transformations within the target database or data platform. Many industrial data flows combine both patterns.
    • ETL vs. simple interfaces: A point-to-point interface that only copies fields between two systems is not always considered full ETL. ETL usually implies a more formal process with structured transformations, quality checks, and a designed data model.
    • ETL vs. MES/ERP integration: MES-to-ERP integration may use ETL techniques, but ETL itself is the data movement and transformation process, not the business application integration logic or the systems being integrated.

    Relation to KPI traceability and audits

    When KPI values must be traced back to specific orders, lots, serial numbers, or quality records, ETL plays a central role in:

    • Maintaining consistent identifiers across MES, ERP, QMS, and data historians.
    • Applying controlled, documented transformation logic used in KPI calculations.
    • Enabling reproducible data sets for audit review by preserving source data, mappings, and calculation steps.

    In this context, ETL is part of the evidence chain that shows how reported metrics are derived from original transactional and process data.

  • Reporting bucket

    A reporting bucket is a defined category, range, or grouping used to sort data for reporting and analysis. In manufacturing and industrial operations, it commonly refers to the way events, records, transactions, or measurements are grouped so they can be summarized consistently in dashboards, KPIs, scorecards, or management reports.

    A reporting bucket is not the raw data itself. It is the classification structure applied to data so that similar items are counted together. Buckets may be based on time, status, cause, product family, work center, shift, severity, or another reporting dimension.

    How it is used in operations

    Reporting buckets appear in MES, ERP, quality systems, maintenance systems, and analytics tools when organizations need a stable way to compare activity across periods or processes. Examples include:

    • downtime buckets such as planned, unplanned, and changeover
    • quality buckets such as scrap, rework, use-as-is, or pending review
    • time buckets such as hourly, daily, weekly, or monthly reporting periods
    • order or inventory buckets such as released, in process, completed, or on hold

    The exact bucket definitions matter because the same operational event can be reported differently depending on how categories are designed and maintained.

    What it includes and excludes

    A reporting bucket usually includes the label, the business rule for what belongs in that label, and the mapping logic from source data into that group.

    It usually does not mean a storage container, database bucket, or cloud object storage bucket unless the discussion is specifically about IT infrastructure. In operations reporting, the term most often refers to a reporting classification rather than a technical storage object.

    Common confusion

    Reporting bucket vs. KPI: a bucket groups data, while a KPI measures performance using data that may be grouped into buckets.

    Reporting bucket vs. data field: a data field is a raw attribute such as reason code or timestamp. A reporting bucket may be derived from one or more fields.

    Reporting bucket vs. chart bin: a chart bin is a visual grouping used in analysis tools. A reporting bucket may be similar, but it is often a defined business category used repeatedly across reports.

    Manufacturing example

    If multiple machine stop codes roll up into broader categories such as material issue, operator waiting, maintenance, or setup, those broader categories are reporting buckets. The bucket allows management to view trends without reviewing every individual stop code.