Connect981 – Content Dev

Glossary Tag: leading indicators

  • Industrial IoT

    Industrial IoT (IIoT) commonly refers to the use of networked sensors, devices, and control systems within industrial environments to collect, transmit, and use operational data. It applies to factories, process plants, warehouses, utilities, and other production settings where physical assets and processes are monitored and controlled.

    In an IIoT setup, equipment such as machines, production lines, utilities, and environmental systems are instrumented with sensors or smart devices. These devices communicate data over wired or wireless networks to on-premise or cloud-based applications for monitoring, analysis, and integration with manufacturing and business systems.

    Key characteristics

    • Connected assets: Machines, tools, material handling systems, and utilities equipped with sensors and communication interfaces.
    • Data acquisition: Continuous or periodic collection of data such as temperature, vibration, pressure, speed, quality checks, and status signals.
    • Industrial context: Focus on production reliability, safety, regulatory needs, and integration with OT systems like PLCs, SCADA, DCS, and MES.
    • Analytics and applications: Use of dashboards, alerting, and analytic tools to support maintenance, quality, throughput, and compliance activities.
    • Secure connectivity: Network and cybersecurity controls tailored to industrial protocols and critical infrastructure constraints.

    Operational meaning in manufacturing

    In day-to-day operations, Industrial IoT often shows up as:

    • Real-time machine data feeds into MES, historian, or operations-intelligence systems.
    • Condition monitoring of assets to support planned maintenance and reduce unplanned downtime.
    • Environmental and process parameter tracking used as part of quality records or batch documentation.
    • Integration between OT signals and IT systems such as ERP for production reporting or inventory updates.
    • Remote visibility into equipment performance across multiple plants or sites.

    What Industrial IoT includes and excludes

    • Includes: Connected sensors and devices, industrial gateways, edge computing nodes, data platforms, and applications directly tied to monitoring and controlling industrial assets and processes.
    • Excludes: General consumer IoT (such as smart home devices) and purely business IT systems that do not interface with production or physical assets.

    Common confusion

    • Industrial IoT vs IoT: “IoT” is a broad term that covers any connected device. “Industrial IoT” focuses specifically on industrial and manufacturing contexts, with constraints such as real-time operation, safety, and compliance.
    • Industrial IoT vs MES/SCADA: MES and SCADA are established application layers for execution and supervisory control. IIoT is about the connected infrastructure and data flows that can feed these systems or complement them, not a replacement for them.
    • Industrial IoT vs Industry 4.0: Industry 4.0 is a broader concept that includes IIoT along with analytics, automation, and organizational practices. IIoT is one of the enabling technologies within that broader shift.

  • operational data store

    An operational data store (ODS) is a centralized data layer that consolidates current, detail-level data from multiple operational systems to support near-real-time reporting and analytics. In manufacturing environments, it commonly integrates data from MES, ERP, LIMS, historian, quality, and maintenance systems without replacing those source systems.

    Key characteristics

    An operational data store typically:

    • Collects and integrates data from multiple source systems such as MES, ERP, SCADA/PLC, historians, and quality systems.
    • Stores current or recent operational data, often at a transactional or event level, rather than long-term history.
    • Supports near-real-time or frequent updates so that reports and dashboards reflect up-to-date shop floor and business status.
    • Uses a common data model or harmonized structures to align fields such as order IDs, batch numbers, equipment IDs, and material codes.
    • Acts as a query and reporting layer so analytics and KPI calculations do not directly burden production systems.

    In regulated or long-lifecycle plants, an ODS is often implemented as a “lightweight data layer” on top of existing systems, enabling unified KPIs and cross-system analysis without major changes to validated ERP or MES platforms.

    How it is used in operations

    Within industrial operations, an operational data store commonly supports:

    • KPI and performance reporting such as OEE, cycle time, schedule adherence, and yield across multiple lines or plants.
    • Operations intelligence and dashboards that combine production, quality, maintenance, and inventory data.
    • Data validation and reconciliation between systems, for example reconciling ERP order status with MES execution data.
    • Regulatory and quality evidence gathering by centralizing relevant operational records for review and export.
    • Downstream analytics such as root-cause analysis, trend monitoring, and early warning alerts.

    An ODS usually does not drive execution logic itself. It reads from operational systems that remain the system of record for transactions, electronic batch records, and equipment control.

    What an ODS is not

    An operational data store is distinct from:

    • Transactional systems such as MES or ERP, which execute and record core business and manufacturing transactions.
    • Data warehouses, which typically hold large volumes of historical, aggregated, and often slower-changing data for strategic analytics.
    • Data lakes, which store raw, variably structured data at scale, often for data science and exploratory analysis.
    • Real-time control systems such as PLCs or DCS, which directly control equipment and processes.

    Common confusion

    The term operational data store is sometimes used loosely for any central data repository. In manufacturing and regulated operations, the term most commonly refers to a structured, integrated, and frequently refreshed store of current operational data, distinct from both the live control systems and long-term analytical warehouses.

    Relation to KPI frameworks and existing systems

    When implementing a KPI framework on top of existing ERP and MES, an ODS can act as the integration layer that:

    • Pulls and normalizes relevant fields from each source system for each KPI.
    • Supports data quality checks and validation without altering the original systems.
    • Provides a stable interface for reporting tools and dashboards, even when underlying systems evolve.

    This approach allows organizations to treat MES, ERP, and other platforms as data sources while maintaining them as the systems of record.

  • semantic model

    A semantic model is a structured representation of the meaning of data, concepts, and their relationships, designed so that different systems and stakeholders interpret information in a consistent way. It focuses on what data represents in the real world, not just how it is stored or formatted.

    What a semantic model includes

    In industrial and manufacturing contexts, a semantic model commonly defines:

    • Business and operational concepts, such as equipment, batches, shifts, work orders, lots, or KPIs like OEE or first-pass yield.
    • Attributes of those concepts, such as units, status, time intervals, and calculation windows.
    • Relationships between concepts, such as which machines belong to which line, or which events contribute to a particular KPI.
    • Constraints and rules, such as how a metric is calculated, required dimensions, or allowed value ranges.

    The goal is to provide a shared vocabulary and structure so that terms like “Downtime”, “Batch”, or “Scrap” have clearly defined and traceable meanings across MES, historians, quality systems, ERP, and partner systems.

    How semantic models are used operationally

    Operationally, semantic models are used to:

    • Map heterogeneous data sources (for example, different plant-specific tags and tables) into a shared conceptual view.
    • Harmonize KPIs and metrics so that comparisons across sites, lines, or partners are based on compatible definitions.
    • Support integration between OT and IT systems by providing a common layer between physical tags, database schemas, and business applications.
    • Enable traceability of meaning, by documenting calculation rules, versions, and the origin of definitions.

    A semantic model does not need to replace existing systems or databases. It can sit on top of them as a logical layer that interprets and standardizes their data.

    Relation to data models and ontologies

    A semantic model is related to, but distinct from:

    • Physical or logical data models, which describe how data is stored (tables, columns, tags, message schemas). A semantic model focuses on meaning, not storage details.
    • Ontologies and taxonomies, which are formal or hierarchical structures of concepts. Many semantic models in industry are practical ontologies, but they may be less formal than those used in academic knowledge representation.

    In manufacturing, semantic models are often aligned informally with standards such as ISA-95 or sector-specific reference models, without necessarily replicating them in full.

    Common confusion

    • Semantic model vs. KPI catalog: A KPI catalog lists metrics and basic formulas. A semantic model goes further by defining the underlying concepts, relationships, and conditions so the same KPI can be computed consistently across contexts.
    • Semantic model vs. master data: Master data defines specific entities and values (for example, material codes, customer IDs). A semantic model defines the meaning and structure that master data instances follow.
    • Semantic model vs. integration mappings: Point-to-point mappings convert fields between systems. A semantic model provides a shared target meaning that those mappings align to, reducing system-specific coupling.

    Context: harmonizing KPI semantics across plants and partners

    When used as a bridge across plants and external partners, a semantic model provides a shared definition layer for KPIs and operational concepts. Local systems can keep their own tag names, table structures, and calculation specifics, while mappings connect them to the central semantic model. Versioning and traceability within the model help document how definitions evolve over time and how each site or partner maps to the shared semantics.

  • BI

    BI, short for Business Intelligence, commonly refers to the practices, tools, and data models used to turn raw business and operational data into structured information for reporting, analysis, and decision-making.

    What BI includes

    In industrial and regulated manufacturing environments, BI typically includes:

    • Data extraction and integration from systems such as MES, ERP, QMS, LIMS, maintenance systems, and finance
    • Data modeling and aggregation across plants, lines, customers, products, or time periods
    • Standard and ad hoc reports, dashboards, and scorecards for KPIs and metrics (for example OEE, NPT, COPQ, schedule adherence, inventory turns)
    • Self-service analytics and query tools used by engineers, operations leaders, and quality staff
    • Visualization layers (charts, heat maps, drill-down views) that sit on top of a data warehouse, data mart, or data lake

    BI environments are usually read-focused. They consume data from transactional and execution systems (such as MES or ERP) but do not control machines, authorize work, or manage real-time workflows.

    How BI is used in operations

    Within manufacturing operations, BI is commonly used to:

    • Monitor performance against defined KPIs, including ISO 22400 metrics and site-specific indicators
    • Compare performance across shifts, lines, products, or suppliers
    • Analyze trends in quality, scrap, rework, downtime, and delivery performance
    • Support capacity planning, budgeting, and continuous improvement initiatives
    • Combine financial and operational data (for example, cost impact of downtime or scrap)

    Relationship to ISO 22400 and KPIs

    BI platforms are frequently used to calculate and present manufacturing KPIs, including those defined in ISO 22400 and additional internal metrics. A common practice is to:

    • Implement ISO 22400 KPIs as a stable, standardized core within the BI model
    • Layer custom, financial, or IT-centric metrics on top, clearly labeled so they are not confused with formal ISO indicators
    • Document KPI definitions, formulas, and data sources within the BI environment for audit and governance purposes

    Common confusion

    • BI vs. MES: MES controls and records production in real time on the shop floor. BI analyzes data (often including MES data) for reporting and long-term insights, but does not execute or enforce production workflows.
    • BI vs. operational intelligence (OI): BI often works on historical or near-real-time data with broader business context. Operational intelligence focuses more narrowly on real-time monitoring, alerts, and decisions tied directly to ongoing operations.
    • BI vs. data warehouse: A data warehouse is an underlying storage and modeling layer. BI refers to the reporting, analytics, and visualization capabilities that sit on top of such stores.

    Other use of the acronym

    Outside industrial and IT contexts, BI can also stand for Business Improvement. In the context of manufacturing systems and data, however, BI almost always refers to Business Intelligence.

  • Model-Based Definition (MBD)

    Model-Based Definition (MBD) is a product definition approach in which a 3D CAD model, including embedded annotations and product manufacturing information (PMI), serves as the primary and often sole authority for describing a part or assembly. In an MBD approach, dimensions, tolerances, surface finishes, material specifications, and other requirements are attached directly to the 3D model rather than being maintained primarily on separate 2D drawings.

    Key characteristics

    • 3D model as the authority: The 3D CAD model, with its PMI, is treated as the master reference for design, manufacturing, and quality, often replacing traditional 2D drawings.
    • Embedded product manufacturing information (PMI): Geometric dimensions and tolerances (GD&T), notes, callouts, and other attributes are applied directly within the model environment.
    • Digital interoperability: The model is intended to be consumed downstream by CAM, CMM, MES, PLM, and other systems to support NC programming, inspection planning, and automated feature extraction.
    • Configuration and change control: MBD data typically lives under formal revision control in PDM/PLM systems, similar to drawings, and must align with document control and quality procedures.

    Use in industrial and regulated environments

    In manufacturing operations, especially in aerospace, defense, and other regulated sectors, MBD commonly appears as:

    • Design authority packages: Customers or engineering groups releasing 3D models with embedded PMI as the official definition delivered to suppliers or internal manufacturing.
    • Inputs to MES and digital work instructions: MBD models referenced in digital travelers, operation instructions, or visual work instruction tools to show model views and callouts at each operation.
    • Inputs to inspection and FAI: MBD used to drive ballooning, characteristic extraction, and CMM programs for First Article Inspection and ongoing inspection plans.
    • Source for manufacturing automation: CAM, toolpath generation, and coordinate measuring routines built directly from the model to reduce re-interpretation of requirements.

    What MBD includes and excludes

    • Includes the 3D geometry and all necessary product definition details (dimensions, tolerances, GD&T, notes, references to standards, and other PMI) required to manufacture and inspect the part.
    • May include links to related specifications, materials, and process requirements managed in PLM, QMS, or document control systems.
    • Does not automatically include full process plans, routings, or work instructions, although MBD is often referenced by these artifacts.
    • Does not replace quality records, FAI reports, DHRs, or other compliance documents, but can serve as a primary data source for generating them.

    Operational considerations

    When MBD is used on the shop floor and in quality systems, typical considerations include:

    • Access and visualization: Ensuring operators, inspectors, and suppliers can view and interrogate 3D models and PMI with appropriate tools and permissions.
    • Version governance: Aligning MBD revisions with ERP/MES routings, work orders, inspection plans, and FAI baselines under controlled change processes.
    • Integration with other systems: Mapping model features and characteristics into MES, PLM, QMS, and CMM software without manual re-entry where possible.
    • Training and interpretation: Ensuring personnel understand 3D PMI, GD&T usage, and how model-based requirements translate into measurement and process controls.

    Common confusion

    • Model-Based Definition (MBD) vs Model-Based Enterprise (MBE): MBD focuses on using the 3D model as the formal product definition. Model-Based Enterprise refers to a broader organizational approach where model-based data flows through design, manufacturing, quality, and support processes.
    • MBD vs 3D CAD models without PMI: A simple 3D model used only for visualization or rough geometry is not typically considered MBD. MBD implies that the model carries the authoritative dimensions, tolerances, and other PMI required to build and verify the part.
    • MBD vs digital drawings: PDF or electronic 2D drawings are digital but are still drawing-centric. MBD shifts the source of truth to the 3D model itself rather than to a 2D representation.

  • Aggregation Level

    Aggregation level commonly refers to the degree of detail or summarization applied to data when it is collected, stored, analyzed, or reported. In industrial and manufacturing environments, it describes how information is grouped, such as per unit, batch, work order, shift, production line, plant, or enterprise.

    Core meaning

    An aggregation level is a defined layer of granularity at which data points are combined into a single record or metric. It determines:

    • What each record represents (for example, one sensor reading vs. one batch)
    • How many raw events are rolled up into that record
    • Which questions can be answered from the dataset or report

    Common aggregation levels in manufacturing and regulated operations include, for example:

    • Event or sample level: individual sensor readings, operator entries, or quality measurements
    • Unit or device level: all records tied to a specific serial number or equipment item
    • Batch or lot level: data grouped by batch ID, lot number, or work order
    • Shift or time period level: data grouped by shift, hour, day, week, or month
    • Line, area, or site level: data summarized by production line, cell, area, or plant
    • Enterprise level: consolidated data across multiple plants or business units

    How aggregation level is used in operations

    In OT, MES, ERP, and quality systems, aggregation level influences how information is:

    • Stored: time-series historians may keep fine-grained data (per second), while data warehouses store hourly or daily summaries.
    • Displayed: dashboards may present OEE per line per shift, while traceability tools retain unit- or batch-level records.
    • Integrated: interfaces between MES and ERP often define alignment by order, batch, or period-level aggregates.
    • Used for compliance: regulated environments may require specific aggregation levels (for example, batch-level records for release decisions) while still retaining underlying detailed data for investigations.

    Choosing an aggregation level is typically a trade-off between data volume, performance, and the need for detailed traceability or root-cause analysis.

    What aggregation level does not mean

    • It is not the calculation method itself (for example, average vs. maximum) but the grouping to which that method is applied.
    • It is not the data model or schema, although aggregation levels are usually embedded in those designs.
    • It is not limited to time; it can be based on product, batch, equipment, or organization hierarchy.

    Common confusion

    • Aggregation level vs. aggregation function: The level describes the grouping (per batch, per day). The function describes how values are combined within that group (sum, average, minimum, count).
    • Aggregation level vs. data resolution: Resolution usually refers to how frequently data is sampled (for example, every second). Aggregation level describes how those samples are grouped for storage or reporting (for example, one value per minute or per batch).

    Context in manufacturing systems

    Standards and reference models for manufacturing operations and integration often assume multiple aggregation levels across system layers, such as detailed event data at equipment level and aggregated production data at site or enterprise level. When designing KPIs, reports, or interfaces between OT, MES, and ERP, the required aggregation levels need to be explicitly defined to support traceability, quality investigations, and management reporting.

  • Why do digital transformation projects fail in industrial SMEs?

    In industrial small and medium-sized enterprises (SMEs), digital transformation projects often fail not because of individual technologies, but because of organizational, process, and integration issues specific to manufacturing and regulated environments.

    Typical reasons for failure in industrial SMEs

    • Unclear business problem and success criteria
      Projects start from a desire to “go digital” or “implement Industry 4.0” without a tightly defined problem statement, target metrics (such as OEE, NPT, scrap, or lead time), or a clear link to quality, compliance, or capacity goals.
    • Lack of executive sponsorship and ownership
      No accountable owner with authority across production, quality, engineering, IT, and finance. Initiatives become “side projects” that stall when priorities shift or budgets tighten.
    • Over-scoping and under-resourcing
      Trying to replace or modernize everything at once (ERP, MES, quality, maintenance, analytics) with limited internal capacity, especially in SMEs that already operate with lean staffing.
    • Technology-first rather than process-first approach
      Selecting tools (MES, IIoT platform, analytics, cloud) before mapping current processes, constraints, and regulatory requirements. This leads to systems that do not match real shop-floor workflows.
    • Poor integration with existing OT/IT landscape
      Underestimating the difficulty of connecting legacy equipment, homegrown systems, paper processes, and core systems such as ERP, LIMS, or QMS. Data ends up siloed, duplicated, or unreliable.
    • Insufficient attention to data quality and governance
      Collecting more data without defining data ownership, version control, context (such as batch, product, or equipment), and rules for change control. This is especially critical in regulated environments where records must be complete and traceable.
    • Ignoring shop-floor and quality-user needs
      Systems are designed around management dashboards instead of operators, supervisors, and quality personnel. If new workflows slow people down, users revert to spreadsheets and paper, undermining adoption.
    • Underestimating change management and training
      Limited time allocated for training, coaching, and updating procedures or work instructions. New digital workflows conflict with existing standard work, audits, or approvals, creating confusion.
    • Misalignment with regulatory and quality requirements
      Digital tools are introduced without validating that they support required records, signatures, traceability, or auditability. This can lead to parallel paper systems or rework to satisfy inspections.
    • Vendor lock-in or misfit solutions
      Choosing tools that are too complex, too generic, or overly customized for the SME’s scale. High configuration and maintenance burdens cause projects to stall after pilots.
    • Lack of staged roadmap
      Absence of a phased plan that delivers early, measurable wins (for example, digital work instructions, basic OEE, or electronic logbooks) before expanding into more advanced analytics or automation.

    How this shows up in regulated manufacturing

    In regulated industrial SMEs, failures often appear as:

    • Digital systems that cannot reliably support batch records, device history records, or traceability, so paper backups continue indefinitely.
    • MES or data-collection pilots that never progress past a single line or work cell, often because validation, change control, or integration with ERP and QMS was not planned from the start.
    • Disconnected analytics projects that generate dashboards but are not trusted for decisions during audits or customer reviews.

    Successful SMEs usually start small, focus on a few high-value use cases (such as improved shop-floor visibility, reduced manual paperwork, or better nonconformance handling), and build a practical roadmap that aligns technology choices with process requirements, integration constraints, and quality/compliance needs.

  • Object of Measurement

    An object of measurement is the specific item, process, entity, or condition that a measurement activity is intended to quantify or qualify. It defines what is being measured so that data collection is specific, consistent, and repeatable.

    In industrial and manufacturing environments, the object of measurement can be physical (for example, a batch of material, a machined part, a vessel, or a production line) or conceptual (for example, a process parameter, a quality characteristic, a downtime event, or a workflow step). Identifying the object of measurement is a prerequisite for defining metrics, setting specifications, configuring instruments, and structuring data in IT/OT systems.

    Typical objects of measurement in manufacturing

    Examples include:

    • Products and materials: individual units, lots/batches, raw materials, intermediates, or finished goods measured for dimensions, weight, potency, or other properties.
    • Processes and operations: a mixing operation, an assembly step, a curing cycle, or a cleaning procedure measured for time, temperature, pressure, or sequence adherence.
    • Equipment and assets: machines, tools, lines, utilities, and sensors measured for status, availability, speed, energy use, or calibration state.
    • Quality characteristics: defect rates, surface finish, concentration, contamination level, or label accuracy measured against defined specifications or limits.
    • Performance measures: throughput, cycle time, changeover duration, scrap rate, or OEE components (availability, performance, quality).

    Operational use in systems and workflows

    In regulated and data-driven operations, the object of measurement is used to:

    • Define data structures in MES, LIMS, SCADA, historians, and ERP (for example, linking measurements to a specific batch, work order, or equipment asset).
    • Configure instruments and forms (for example, specifying that a gauge measures the diameter of a particular feature on a part, not the entire part).
    • Support traceability by clearly associating results with the correct product, process step, or time period.
    • Enable analysis such as SPC charts, capability studies, OEE dashboards, and deviation investigations, where data must be grouped by a well-defined object.

    Common confusion

    • Object of measurement vs. measurement unit: the object of measurement is what is being measured (for example, batch temperature). The measurement unit is how the result is expressed (for example, degrees Celsius).
    • Object of measurement vs. metric or KPI: the object of measurement is the underlying entity or characteristic (for example, line speed). A metric or KPI is the calculated indicator based on measurements (for example, average line speed per shift, or performance percentage in OEE).
    • Object of measurement vs. method of measurement: the object of measurement is the target of the measurement, while the method of measurement describes how the measurement is carried out (for example, instrument type, sampling plan, and procedure).

    Relation to standards and data models

    In structured data models and manufacturing standards, the object of measurement is often represented as the entity to which a measurement or result record is attached. For example, a standard may define measurements as linked to equipment, material lots, operations, or resources, all of which act as objects of measurement. Clear definition of the object of measurement supports consistent data integration and interoperability across OT and IT systems.