Connect981 – Content Dev

Glossary Tag: leading indicators

  • 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.

  • 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.

  • 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.

  • RAMI 4.0

    RAMI 4.0 (Reference Architectural Model Industrie 4.0) is a three-dimensional reference architecture used to describe, structure, and align Industry 4.0 concepts, components, and systems. It provides a common map for how industrial assets, data, functions, and business processes relate to each other across different levels of an industrial operation.

    Core concept

    RAMI 4.0 combines three dimensions into one model:

    • Layers: From the physical asset and integration level up through communication, information, functional, and business layers.
    • Lifecycle & value stream: From idea and development through production, operation, and end of life of a product or asset.
    • Hierarchy levels: From physical product and field device up through station, work center, enterprise, and connected world, consistent with traditional automation pyramids.

    In industrial and regulated environments, RAMI 4.0 is commonly used as a planning and communication tool when designing or assessing digitalization initiatives, OT/IT integration, and Industry 4.0 projects. It offers a structured way to place MES, ERP, PLCs, SCADA, IIoT platforms, and quality or compliance systems within a unified architectural view.

    Operational meaning in manufacturing

    In practice, RAMI 4.0 is used to:

    • Map existing systems (“brownfield” plants) across layers and hierarchy levels to understand overlaps and gaps.
    • Plan new capabilities such as connectivity, data models, and digital twins in a consistent reference frame.
    • Align stakeholders from operations, IT, engineering, and quality on where specific functions should reside.
    • Support interoperability discussions around standards, interfaces, and information models for Industry 4.0 components.

    RAMI 4.0 itself is not a software product, not a protocol, and not a standard that can be installed. It does not, by itself, establish regulatory compliance or quality certification. Instead, it structures how technologies and standards are considered in an Industry 4.0 setting.

    Relationship to other standards and models

    RAMI 4.0 is often used alongside other industrial frameworks and standards such as:

    • ISA-95 style hierarchy models for enterprise-to-control system integration.
    • Information models and standards for Industrie 4.0 components and administration shells.
    • OT and IT architecture patterns for MES, SCADA, historians, and ERP integration.

    While RAMI 4.0 provides a reference structure, individual organizations adapt it to their own system landscape and regulatory requirements.

    Common confusion

    • RAMI 4.0 vs. Industry 4.0: Industry 4.0 is a broad concept describing the digital transformation of manufacturing. RAMI 4.0 is a specific reference architecture used to describe and structure that transformation.
    • RAMI 4.0 vs. implementation: RAMI 4.0 is a conceptual model. It does not prescribe particular products, vendors, or detailed implementation steps.
    • RAMI 4.0 vs. compliance: Using RAMI 4.0 does not by itself demonstrate regulatory, quality, or cybersecurity compliance. It can, however, help organize systems and responsibilities in a way that supports compliance activities.

    Connection to the FAQ context

    In many discussions, RAMI 4.0 is presented as a way to structure Industry 4.0 implementations across layers, lifecycle, and hierarchy. In brownfield manufacturing environments, it is typically tailored to reflect existing assets and systems, then used as a planning and alignment tool for future changes.

  • 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.

  • OPC server

    An OPC server is software that makes data from industrial devices or control systems available to other applications using OPC communication standards such as OPC Classic (DA, A&E, HDA) or OPC UA. It acts as a data access layer between field equipment and higher-level systems, translating device-specific protocols into a standardized OPC information model and interface.

    In a typical manufacturing environment, an OPC server connects to PLCs, DCSs, CNCs, sensors, or other automation components and presents their tags, variables, or events to client systems. Common OPC clients include SCADA systems, MES, historians, analytics platforms, and custom OT/IT integration services.

    Key characteristics

    • Role: Acts as the data provider in the OPC client/server model, exposing data points, methods, and events.
    • Location: May run on a control system node, a dedicated gateway, or an IT/OT demilitarized zone (DMZ) server.
    • Protocol translation: Often converts proprietary or fieldbus protocols (for example Modbus, Profibus, vendor-specific PLC drivers) into OPC address spaces.
    • OPC Classic vs OPC UA: OPC Classic servers typically use COM/DCOM on Windows, while OPC UA servers use platform-independent, service-oriented protocols with built-in security features.
    • Security and governance: In regulated or critical environments, OPC servers are typically subject to access control, change management, cybersecurity controls, and validation or qualification activities.

    Operational context in manufacturing

    • Shop floor connectivity: Provides a standardized interface that MES, quality systems, and data collection tools can use to read process parameters, equipment status, and alarms.
    • Data aggregation: Aggregates data from multiple devices or lines into a single endpoint for historians, reporting, or operations intelligence systems.
    • Interoperability: Helps connect heterogeneous vendor equipment without each application implementing every device protocol.
    • Segmentation: Can be deployed at network boundaries to control how OT data is exposed to IT systems, with design and configuration impacting cybersecurity posture.

    What an OPC server is not

    • It is not a complete MES, SCADA, or historian. Those systems may use OPC servers, but provide broader application logic and data storage.
    • It is not by itself a compliance or validation solution. Compliance in regulated manufacturing depends on the surrounding processes, controls, and documented use of the OPC-based architecture.
    • It is not limited to a specific industry. OPC servers are used across discrete, batch, and continuous manufacturing and in other industrial sectors.

    Common confusion

    • OPC vs OPC server: “OPC” generally refers to the family of interoperability standards, while an “OPC server” is a specific software component that implements the server side of those standards.
    • OPC server vs OPC client: The server exposes and manages the data; the client consumes it. MES, SCADA, and analytics tools are usually OPC clients, even when they embed their own server capabilities.
    • OPC server vs gateway: Some products described as gateways include an OPC server plus other protocol conversion or routing functions. An OPC server, strictly defined, focuses on providing an OPC interface.

    Relation to the OPC standards in manufacturing

    In manufacturing environments, an OPC server is the primary way OPC standards are realized in practice. It operationalizes the OPC information model and services so that equipment data, alarms, and events can be accessed in a consistent way by higher-level systems. The reliability, security configuration, and validation of the OPC server and its interfaces are often important considerations in regulated or safety-critical operations.

  • feature engineering

    Core meaning

    Feature engineering is the process of creating, selecting, and transforming input variables (features) from raw data so that machine learning (ML) models can use them effectively. It translates domain knowledge and raw signals into structured, numerical or categorical representations that algorithms can work with.

    It typically includes activities such as:

    – Selecting which raw data fields or signals to use
    – Cleaning and standardizing values (units, ranges, formats)
    – Aggregating measurements over time or batches
    – Deriving new variables from existing ones (e.g., ratios, deltas, rolling statistics)
    – Encoding categorical values into numerical form
    – Normalizing or scaling features to appropriate ranges

    Feature engineering is usually performed before model training and is often captured in a repeatable pipeline so that the same transformations can be applied consistently to new data.

    Use in industrial and regulated environments

    In manufacturing and other industrial domains, feature engineering commonly operates on:

    – Process data from PLCs, historians, and OT systems (temperatures, pressures, speeds)
    – MES data (work orders, material genealogy, routing steps, operator IDs)
    – Quality data (in-process and final test measurements, SPC statistics)
    – Maintenance data (run-time counters, alarms, failure codes)

    Examples include:

    – Converting second-by-second sensor traces into summary statistics per batch or lot
    – Calculating time since last maintenance or time-in-state per machine
    – Deriving features such as yield, scrap rate, or rework count per order
    – Encoding production route, shift, or product family as model-ready features

    In regulated environments, feature engineering steps are often:

    – Documented as part of the data pipeline design
    – Version-controlled alongside model code
    – Subject to change control and impact assessment when modified

    Role in explainable and trustworthy AI with MES

    When AI models are integrated with MES, feature engineering strongly influences how explainable and trustworthy the models are:

    – **Traceability and data lineage:** Each engineered feature should be traceable back to its raw data source (e.g., specific MES fields, historian tags) and transformation logic.
    – **Interpretability:** Using domain-meaningful features (e.g., “average oven temperature in curing step” rather than opaque encodings) supports human review of model behavior.
    – **Use-case boundaries:** Engineered features often encode assumptions about process conditions, time windows, or product families, which define where the model is appropriate to use.
    – **Validation:** The correctness and stability of feature calculations are validated along with the model, since errors in feature engineering can lead to misleading outputs.

    In this context, feature engineering is treated as part of the overall AI design, not just a technical preprocessing step.

    Boundaries and exclusions

    Feature engineering:

    – **Includes:** Data cleaning, transformation, and representation steps specifically aimed at preparing inputs for ML models.
    – **Excludes:** The training of the ML model itself (model selection, fitting, hyperparameter tuning), even though these depend on the engineered features.
    – **Excludes:** Basic ETL or integration work that does not change the informational content of the data beyond formatting, unless it directly defines input variables for a model.

    It is related to, but distinct from:

    – **Data engineering:** Focused on data storage, transport, and availability at scale.
    – **Feature selection:** Choosing a subset of features, which may be part of feature engineering but is sometimes treated as a separate modeling step.

    Common confusion

    – **Versus raw data extraction:** Simply pulling tags from a historian or columns from a MES database is not, by itself, feature engineering. The term is reserved for the deliberate design of input variables from that data.
    – **Versus automated feature learning:** Some modern ML methods (e.g., deep learning) can learn internal representations from raw data. Even then, in industrial settings, explicit feature engineering is still commonly used to capture domain-specific knowledge, ensure traceability, and support explainability.