Connect981 – Content Dev

Glossary Tag: signal detection

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

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

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

  • Reconciliation

    Core meaning

    In industrial and manufacturing contexts, **reconciliation** is the systematic process of comparing two or more sets of related records and aligning them so that:

    – all differences are identified,
    – discrepancies are understood and documented, and
    – the resulting, agreed data set is internally consistent.

    The data sets being reconciled usually represent the same events or quantities from different sources (for example, system-of-record vs. local records, planned vs. actual, or IT vs. OT data).

    Typical uses in manufacturing and regulated operations

    Reconciliation commonly appears in several areas:

    – **Inventory reconciliation**: Matching physical stock counts to inventory records in an ERP, WMS, or MES. Differences are investigated and adjustments are recorded.
    – **Material and batch reconciliation**: Comparing material consumption and yield data from shop-floor systems or equipment with MES/ERP batch records and production orders.
    – **Production data reconciliation**: Aligning OT data (PLC/SCADA counters, historian tags) with MES or ERP production quantities, timestamps, and statuses.
    – **Quality and deviation reconciliation**: Matching inspection results, deviations, and nonconformances across LIMS, QMS, and MES so that each unit, lot, or batch has a consistent history.
    – **Financial and cost reconciliation**: Aligning production, scrap, and rework quantities with cost-accounting records, often bridging MES/ERP and finance systems.

    In regulated environments, reconciliation is often a documented activity, with evidence of what was compared, what was found, and how mismatches were resolved.

    What reconciliation typically includes and excludes

    **Includes:**

    – Comparing two or more data sources that should represent the same reality
    – Identifying mismatches in quantities, statuses, timestamps, or identifiers
    – Investigating and explaining causes (e.g., late data, manual error, system integration gaps)
    – Updating records or creating adjustments so that a final, consistent view is established
    – Logging the outcome for traceability and audit purposes

    **Excludes:**

    – General problem solving or root cause analysis that does not involve comparing data sets
    – Data cleansing done without reference to an authoritative counterpart data set
    – System integration itself (reconciliation uses data produced by integrations but is not the integration mechanism)

    Data and systems context

    Reconciliation is often performed at boundaries between:

    – **OT and IT systems** (e.g., historian vs. MES or ERP)
    – **Execution and planning systems** (e.g., MES vs. APS/MRP/ERP)
    – **Source and consuming systems** in data pipelines (e.g., shop-floor data vs. data warehouse or operations-intelligence tools)

    It may be executed:

    – manually (spreadsheet-based comparisons, reports),
    – semi-automatically (scheduled jobs generating discrepancy lists), or
    – automatically (rules-based matching and exception handling in MES/ERP or data platforms).

    Common confusion and related terms

    Reconciliation is often confused with:

    – **Data validation**: Validation checks whether data meets defined rules or formats; reconciliation compares data from different sources to each other.
    – **Data harmonization or standardization**: Harmonization aligns formats, units, or codes; reconciliation aligns records and quantities across systems after they are harmonized.
    – **Balancing or mass balance**: Mass balance focuses on conservation of mass or energy in a process; reconciliation may use mass balance as one method but is broader and data-centric.

    Understanding these distinctions helps specify whether a workflow needs validation rules, reconciliation procedures, or both.

  • Information model

    An information model is a structured representation of information, including the types of data that exist in a domain, the relationships between those data elements, and the rules or constraints that govern them. In industrial and manufacturing environments, information models are used to describe how equipment, processes, materials, batches, quality records, and business objects are represented and exchanged across OT and IT systems.

    Key characteristics

    In this context, an information model typically:

    • Defines entities and attributes, such as assets, tags, lots, recipes, orders, or alarms, and their properties.
    • Specifies relationships, for example how a batch relates to raw material lots, equipment units, and test results.
    • Provides structure for interoperability, enabling different systems (PLC/SCADA, MES, LIMS, ERP, historians) to interpret exchanged data consistently.
    • Includes rules and constraints, such as allowed value ranges, units of measure, or mandatory fields for regulatory records.

    An information model can be formalized in many ways, including OPC UA address spaces, ISA-95 object hierarchies, database schemas, XML or JSON schemas, or model-based integration frameworks. The core idea is to create a common, machine-readable understanding of what the data represents, not just how it is formatted.

    Role in industrial and regulated environments

    In manufacturing systems, information models commonly:

    • Bridge OT and IT by mapping control-level tags and signals to higher-level concepts like equipment units, production runs, or KPIs.
    • Support compliance and traceability by explicitly modeling genealogy, batch relationships, and links between process data and quality records.
    • Enable standardized interfaces for MES/ERP or MES/LIMS integration by sharing a consistent definition of orders, materials, test results, and status codes.
    • Improve data governance by clarifying ownership, meaning, and permissible uses of data elements across systems.

    Information models and OPC UA

    OPC UA uses the concept of an information model to describe data exposed by devices, controllers, gateways, and applications. In OPC UA:

    • The information model defines nodes (objects, variables, methods) and references that organize data into a browseable address space.
    • Standard companion specifications add domain-specific models, such as models for machine tools, robots, or packaging lines.
    • Vendors can extend the base model with custom types, which makes it important to review and validate each implementation when integrating into a plant.

    What it is not

    An information model is not the same as:

    • Physical data storage, such as a specific database implementation or file format, even though it may influence them.
    • A communication protocol; it describes what information is represented, not the low-level mechanics of how bytes are transmitted on the network.
    • A process model; it focuses on data representation rather than on the sequencing or control logic of operations.

    Common confusion

    Several related terms are often used alongside or instead of “information model”:

    • Data model: Often used interchangeably, especially in IT. Some practitioners use “information model” for a higher-level, conceptual view and “data model” for more concrete implementation details, but the distinction is not universal.
    • Ontology: In some contexts, this refers to a more formal, semantically rich information model with explicit meaning and reasoning rules, for example using semantic web technologies.
    • Schema: Typically refers to the technical structure of data in a specific system (such as a database or message format) that is derived from or aligned with an information model.

    When specifying or reviewing integrations in manufacturing environments, it is useful to clarify whether a document or standard is describing a conceptual information model, a concrete data/schema design, or both.

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