Connect981 – Content Dev

Glossary Tag: process monitoring

  • process interface

    A process interface is a defined connection point where two processes interact. It specifies how inputs, outputs, information, and responsibilities are handed off between processes so that the overall system works as an integrated whole.

    What a process interface includes

    In industrial and regulated manufacturing environments, a process interface commonly describes:

    • Inputs and outputs that move between processes (materials, information, approvals, work orders, quality records).
    • Triggers and timing for when one process hands over work and when the next process is allowed to start.
    • Roles and responsibilities for those sending and receiving the handoff (e.g., process owner, planner, quality, operator).
    • Data structures and formats used at the boundary (MES records, ERP fields, document revisions, batch IDs, serial numbers).
    • Rules and criteria that must be satisfied before handoff (inspection status, approvals, required documents, system validations).

    Process interfaces can be:

    • Organizational, such as the interface between production planning and shop-floor execution.
    • System-level, such as the interface between ERP and MES or between MES and a quality management system.
    • Physical/operational, such as the transfer of a batch from one unit operation to the next, governed by defined documentation and sign-offs.

    Operational meaning in manufacturing systems

    In practice, process interfaces are where many errors and variances occur if they are not clearly defined and controlled. Typical examples include:

    • The interface between sales order entry and production planning, where customer requirements are translated into routings and materials plans.
    • The interface between planning (ERP) and execution (MES), where work orders, BOMs, and revision data are released to the shop floor.
    • The interface between manufacturing and quality, where inspection results and nonconformances are recorded and fed back into process control.
    • The interface between manufacturing and logistics, where finished goods and as-built records move into inventory and shipping.

    Defining process interfaces typically involves documenting:

    • Which systems are involved (e.g., ERP, MES, QMS, LIMS, PLM).
    • What data elements must be consistent across those systems (e.g., part numbers, revision levels, batch numbers).
    • Who owns the interface and is accountable for issues that occur at the boundary.

    Relation to the process approach

    Within a process approach (for example in ISO 9001 based quality management systems), an organization is managed as a network of interconnected processes. Process interfaces are the defined connection points between these processes. Clearly describing them helps ensure that:

    • Inputs and outputs between processes are identified and controlled.
    • Measurements and risks at process boundaries are understood.
    • Legacy or brownfield systems exchange information in a consistent way.

    Common confusion

    • Process interface vs. system integration: A process interface is a business or operational boundary between processes. System integration is the technical implementation that may support that interface (APIs, file transfers, connectors). The process interface can exist and be documented even if the supporting systems are not yet fully integrated.
    • Process interface vs. process step: A process step is an activity within a single process. A process interface is the boundary between processes where one ends or hands off, and another begins.
    • Process interface vs. user interface: A user interface is how a person interacts with a system (screens, forms). A process interface is about how processes interact with each other, not about screen design.

    Use in OT/IT and MES/ERP contexts

    In OT and IT environments, process interfaces are often formalized as:

    • Data exchange specifications between ERP, MES, QMS, PLM, and SCADA/PLC systems.
    • Workflow definitions describing how electronic travelers, digital work instructions, or quality records move between processes.
    • Governance rules to maintain traceability and version control at each handoff point.

    Clearly defined process interfaces help maintain consistent behavior across mixed legacy and modern systems without implying any specific technology or compliance status.

  • Legacy system

    A legacy system is an existing operational or IT system that remains in use even though it is based on older technologies, architectures, or practices. In industrial and regulated manufacturing environments, the term commonly refers to production control, MES-like, SCADA, historian, quality, or ERP components that are still critical for day-to-day operations but are difficult to modify, integrate, or replace.

    Key characteristics

    Legacy systems typically exhibit one or more of the following traits:

    • Depend on outdated or unsupported hardware, operating systems, databases, or programming languages
    • Have limited or proprietary interfaces that make data integration with newer OT/IT systems difficult
    • Are heavily customized around historical business processes and regulatory expectations
    • Have incomplete documentation or rely on tribal knowledge within the organization
    • Are costly or risky to change because they are tightly coupled to production or compliance workflows

    Role in manufacturing and regulated operations

    In factories and process plants, legacy systems may manage or influence:

    • Production scheduling and dispatching
    • Equipment control, data collection, and alarm handling
    • Electronic records, batch records, or quality and deviation data
    • Traceability, genealogy, and product history information

    Organizations often continue to operate legacy systems because they are validated, deeply integrated into procedures, and familiar to the workforce. At the same time, they can constrain modernization efforts around MES, OT/IT convergence, and advanced analytics, especially when secure connectivity or structured data access is limited.

    Operational considerations

    When working with legacy systems, typical operational concerns include:

    • Maintaining reliable operation on aging hardware or operating systems
    • Managing cybersecurity exposure when security controls or patching are constrained
    • Integrating with newer systems through gateways, adapters, or manual data handling
    • Preserving validated or qualified status when changes are made
    • Planning phased migrations, coexistence strategies, or decommissioning approaches

    Common confusion

    • Legacy system vs. obsolete system: A legacy system is still in active use and often business-critical. An obsolete system is no longer used for normal operations, though data may be retained for historical or regulatory reasons.
    • Legacy system vs. technical debt: A legacy system can contribute to technical debt, but technical debt also includes design decisions in newer systems that make future changes harder.

    Context in integration and modernization

    In integration projects, a legacy system is any existing application or platform that newer solutions must interface with. This can include on-premise ERP instances, custom MES tools, or long-running SCADA deployments. The term does not imply non-compliance; it simply indicates that the technology or architecture is from an earlier generation compared with current design practices.

  • Information Technology (IT)

    Information Technology (IT) commonly refers to the systems, infrastructure, software, and services used to store, process, transmit, and secure digital information within an organization. In industrial and manufacturing environments, IT typically covers business and enterprise systems such as email, office productivity tools, ERP, corporate networks, data centers, cloud platforms, and security tooling that protect these assets.

    Scope and typical components

    IT in a manufacturing company often includes:

    • Enterprise applications such as ERP, PLM, CRM, HR systems, and financial systems
    • Corporate networks, data centers, cloud environments, and remote access services
    • End-user devices such as laptops, desktops, mobile devices, and their operating systems
    • Shared services such as email, identity and access management, directory services, and backup
    • Cybersecurity controls focused on confidentiality, integrity, and availability of business data

    IT organizations are usually responsible for architecture, procurement, configuration, support, patching, and lifecycle management of these systems. They also maintain policies for topics such as network access, account management, encryption, and change management.

    IT in relation to OT and manufacturing systems

    In industrial operations, IT is often contrasted with Operational Technology (OT). While IT focuses on information processing and business workflows, OT focuses on monitoring and controlling physical processes, such as production lines, utilities, and safety systems.

    Typical interactions between IT and OT include:

    • Integrations between ERP and MES or other plant-level systems for orders, inventory, and production data
    • Shared or segmented networks connecting enterprise systems to plants and sites
    • Security services such as identity, logging, and incident response applied to OT environments
    • Data integration and analytics platforms that combine plant data with enterprise data

    In regulated or safety-critical manufacturing, IT staff working with OT environments need awareness of constraints such as high availability requirements, long equipment lifecycles, formal change control, validation, and the impact of downtime on safety and compliance.

    Common confusion

    IT vs OT: IT deals primarily with business information systems, while OT deals with control systems and equipment that directly affect physical processes. Some technologies, such as industrial edge servers or plant historians, may involve both IT and OT responsibilities, and organizations often define clear boundaries and shared governance for these areas.

    IT vs ICS/SCADA: Industrial Control Systems (ICS) and SCADA platforms are usually considered OT, even though they run on computing hardware and networks. IT may manage underlying infrastructure, but the control logic, safety impacts, and operational policies are usually owned by engineering or operations.

    Derived-from context: IT staff in OT environments

    When IT personnel support or integrate with OT systems, effective practice commonly includes structured exposure to plant operations, an understanding of safety and availability constraints, awareness of long asset lifecycles, and adherence to change-control and validation processes. This context influences how IT policies and tools are adapted for production environments.

  • Unified Workflow

    A unified workflow is an end-to-end process model that connects and standardizes activities, data, and decision points across multiple people, departments, and systems into a single, coherent flow. In industrial and manufacturing environments, it commonly refers to orchestrating work across OT and IT systems such as MES, ERP, quality systems, maintenance, and document control tools.

    Key characteristics

    In regulated or complex operations, a unified workflow typically:

    • Spans multiple systems, such as ERP for orders, MES for execution, LIMS/QMS for testing and deviations, and CMMS for maintenance.
    • Defines a single, standard path for how work is initiated, executed, reviewed, and closed, even if many roles and tools are involved.
    • Coordinates data and handoffs so that information, approvals, and evidence move automatically or in a controlled sequence between steps.
    • Makes status visible end to end, from planning and material availability through production, inspection, release, and shipment.
    • Includes controls and traceability for who did what, when, and based on which version of instructions or specifications.

    Operational meaning in manufacturing

    Practically, a unified workflow shows up as a clearly defined, often system-supported process that operators, supervisors, quality, and planning all follow. Examples include:

    • A single, integrated flow from manufacturing order creation in ERP, to electronic work instructions in MES, to in-process checks in a QMS, and final batch disposition.
    • A unified nonconformance and CAPA workflow where issues raised on the shop floor, in incoming inspection, or by a supplier all follow the same investigation and approval steps, even if logged in different systems.
    • A standardized engineering change workflow that links document control, training updates, and shop-floor implementation so changes are released and adopted in a controlled, traceable sequence.

    What it is not

    A unified workflow is not simply:

    • A single software system. One platform may support parts of the workflow, but the term refers to the process across all involved systems and teams.
    • A detailed work instruction. Work instructions describe how to perform a task; a unified workflow describes how tasks, approvals, and data connect across the overall process.
    • A one-time project plan. It is typically a repeatable, standard operational process, not a unique project schedule.

    Common confusion

    • Unified workflow vs. integrated systems: System integration focuses on data exchange and technical connectivity. A unified workflow additionally defines the logical sequence of activities, roles, and decisions that use that data.
    • Unified workflow vs. business process mapping: Process maps document how work flows. A unified workflow usually refers to a mapped and actively executed process that is implemented in tools, monitored, and used in day-to-day operations.

    Use in regulated and high-complexity environments

    In regulated manufacturing, unified workflows are commonly used to ensure that controlled steps such as approvals, electronic signatures, document revisions, training acknowledgments, inspections, and release decisions occur in a defined order and are captured as part of the permanent record. This can apply to batch release, device history records, change control, deviation handling, and audit preparation.

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

  • multi-site architecture

    Multi-site architecture commonly refers to the overall design of systems, networks, and data models that support operations across more than one physical plant, warehouse, lab, or service facility. It describes how environments with multiple locations are structured so that applications, data, and workflows are consistent, secure, and manageable across sites.

    Core characteristics in industrial and manufacturing contexts

    In regulated and industrial operations, a multi-site architecture typically includes:

    • Multiple physical locations such as plants, repair stations, depots, contract manufacturers, or regional warehouses.
    • Coordinated OT and IT systems, for example MES, ERP, QMS, PLM, SCADA, and historians deployed in a way that supports multiple sites.
    • Shared data models and master data for items, routings, BOMs, specifications, part revisions, and customer orders, with clear rules for local versus global data.
    • Network and connectivity design covering site-to-site links, access to centralized services, and separation of site-level OT networks.
    • Governance and access control defining which users, roles, and sites can see or modify which data and workflows.

    Depending on business and regulatory needs, multi-site architectures may use:

    • Centralized deployments, where a single instance of MES/ERP/QMS serves multiple sites.
    • Hub-and-spoke models, where a central system manages reference data and consolidation, while local site systems handle execution.
    • Federated or distributed deployments, where each site has its own instance and standardized interfaces for data exchange.

    Operational relevance

    Multi-site architecture shows up in daily operations through:

    • Standardized processes, where work instructions, routings, and quality plans are shared across sites with controlled local variants.
    • Cross-site visibility of WIP, inventory, capacity, and nonconformances for planning, escalation, and audit preparation.
    • Site-to-site work orchestration, such as moving work orders, assemblies, or repair units between facilities.
    • Centralized evidence and traceability, where records from multiple sites feed a common repository for quality, compliance, and customer reporting.
    • Coordinated change control, where changes to specifications, routings, or software are managed across multiple locations in a controlled way.

    Common confusion

    Multi-site architecture vs. multi-tenant architecture: Multi-site refers to one organization operating multiple physical locations, often on a shared or coordinated system landscape. Multi-tenant architecture usually refers to one software platform serving multiple independent organizations (tenants). A system can be both multi-site and multi-tenant, but the concepts are distinct.

    Multi-site architecture vs. redundancy/disaster recovery: Multi-site architectures may include backup sites or disaster recovery environments, but the term usually focuses on day-to-day operation of multiple active locations, not only on failover or backup.

    Regulated environment considerations

    In regulated manufacturing and service environments, multi-site architecture is often discussed in relation to:

    • Consistent application of procedures and specifications across sites, while documenting approved local variations.
    • Controlled distribution of technical data to only those sites and users that are authorized to access it.
    • Clear segregation of site-level records when required by contracts, regulations, or customer agreements.
    • Evidence management, where audits or customer reviews may examine how processes and systems are architected across multiple facilities.

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

  • PMI

    In industrial and manufacturing contexts, PMI most commonly refers to Product and Manufacturing Information embedded in a 3D CAD model. It captures the information needed to manufacture and inspect a part directly within the model instead of on a separate 2D drawing.

    What PMI includes

    PMI typically covers the information required to define, produce and verify a part, such as:

    • Geometric dimensions and tolerances (GD&T)
    • Datum features and feature control frames
    • Surface finish and surface texture requirements
    • Material specifications and treatments (e.g., heat treat, coating notes)
    • Assembly instructions and fit requirements
    • Weld symbols and other fabrication symbols
    • Inspection requirements and key characteristics
    • Process notes relevant to manufacturing and quality

    In a model-based definition (MBD) workflow, this information is attached directly to 3D geometry, allowing downstream systems to interpret and extract characteristics digitally.

    Operational role in manufacturing systems

    In regulated and high-precision manufacturing, PMI is used to:

    • Drive automatic or semi-automatic extraction of characteristics for inspection planning, including first article inspection (FAI) per standards such as AS9102
    • Link PLM models to MES, QMS and ERP so that specifications, tolerances and inspection points remain consistent across systems
    • Support digital work instructions and visualizations that reference the 3D model rather than static 2D drawings
    • Enable CMM programming, CAM toolpath generation and other automated or assisted NC programming directly from the annotated 3D model
    • Provide traceable, version-controlled product definition as part of a digital thread

    PMI content quality, structure and adherence to internal standards strongly affect whether downstream tools can consume the data reliably. Poorly structured or incomplete PMI often leads to manual rework, misinterpretation or mixed use of 2D drawings and 3D models.

    Common confusion

    • Product and Manufacturing Information vs. Project Management Institute: Outside of CAD and manufacturing, PMI may refer to the Project Management Institute, a professional association. In engineering, CAD, PLM and MES discussions, PMI almost always means Product and Manufacturing Information.
    • PMI vs. MBD: Model-based definition (MBD) is an approach where the 3D model is the authoritative product definition. PMI is a key enabler of MBD, but MBD also includes practices, standards, workflows and system integrations beyond the annotations themselves.
    • PMI vs. 2D drawing annotations: Traditional drawing notes and symbols serve a similar purpose, but PMI is natively associated with 3D geometry and intended for digital consumption by downstream systems.

    Relation to FAI and aerospace workflows

    In aerospace and other regulated industries, PMI is increasingly used to support digital FAI processes. Instead of manually ballooning 2D drawings and typing characteristics into FAI forms, software can read PMI from the 3D model, identify characteristics, and map them to inspection results and quality records. This can improve traceability and alignment between PLM, MES and QMS, while still operating within existing standards such as AS9102.

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