Connect981 – Content Dev

Glossary Category: Operations and Quality Signals

  • data latency

    Data latency commonly refers to the time delay between when an event happens in the real world (for example on the shop floor or in a machine) and when trustworthy data about that event is available to users, dashboards, or downstream systems. In industrial and manufacturing environments, it is the lag between a production, quality, maintenance, or inventory change and when that change is reflected in MES, ERP, historians, or reporting tools.

    How data latency shows up in manufacturing

    In regulated and complex plants, data latency can occur at several layers:

    • Acquisition latency: Delay between a physical event and the signal being captured by a sensor, PLC, or device.
    • Transmission latency: Delay while data moves over networks from OT devices to SCADA, historians, MES, or cloud services.
    • Processing latency: Time required for systems to clean, contextualize, aggregate, and store data (for example, mapping tags to equipment, products, and lots).
    • Integration latency: Delay introduced by batch interfaces between systems such as MES, ERP, QMS, LIMS, and maintenance systems.
    • Presentation latency: Delay between data being stored and when dashboards, reports, or alerts are refreshed.

    Operationally, data latency affects how “real time” production visibility dashboards, OEE calculations, quality monitors, and inventory views actually are. High latency can mean supervisors, planners, and quality teams are making decisions based on outdated data, even if dashboards appear live.

    Data latency versus related concepts

    • Data latency vs. throughput: Latency is about timing (how long a single data point takes to become visible). Throughput is about volume (how many data points per unit of time a system can handle).
    • Data latency vs. sampling rate: Sampling rate is how often data is captured. Latency is the delay before captured data becomes available to use. A high sampling rate can still have high latency if processing and integration are slow.
    • Data latency vs. data quality: Latency is about delay; data quality is about correctness and completeness. Low latency data can still be inaccurate if it is not validated or contextualized.

    Common confusion

    Data latency is sometimes loosely called “real-time” or “near real-time” performance. In practice, these terms are relative and depend on the process. For high-speed automated lines, seconds of latency can matter. For planning processes driven by ERP batch jobs, latency may be measured in minutes or hours. It is also sometimes confused with network latency alone, but in manufacturing environments most delay often comes from processing, integration, and refresh cycles rather than pure network transport.

    Link to production visibility dashboards

    When implementing production visibility dashboards, data latency determines whether displayed KPIs, alarms, and trends represent current operations or a delayed snapshot. Latency may come from slow queries against MES/ERP, overnight batch integrations, or manual data entry cycles. Understanding and documenting expected data latency is important so users interpret dashboards correctly and do not assume they are fully real time when they are not.

  • IT–OT convergence

    IT–OT convergence commonly refers to the intentional integration and coordination of information technology (IT) systems with operational technology (OT) systems in industrial and manufacturing environments. It focuses on treating business information systems and plant-floor control systems as a connected ecosystem rather than separate technology stacks.

    What IT–OT convergence includes

    In regulated and industrial operations, IT–OT convergence typically includes:

    • Connecting enterprise IT systems (such as ERP, PLM, LIMS, and quality systems) with plant-floor OT systems (such as PLCs, DCS, SCADA, historians, and MES).
    • Aligning data models, standards, and interfaces so production, quality, maintenance, and business data can be exchanged and used consistently.
    • Coordinating governance, cybersecurity policies, and change control across both IT and OT environments.
    • Implementing shared architectures and platforms, for example using industrial networks, edge computing, and secure gateways to bridge plant and enterprise networks.
    • Defining joint roles and responsibilities for IT and OT teams, including support, incident response, and lifecycle management for shared systems.

    IT–OT convergence is not a single product or standard. It is a combination of architecture, integration approaches, and organizational practices that connect technology and data across traditional IT and OT boundaries.

    Operational meaning in manufacturing

    At an operational level, IT–OT convergence shows up in activities such as:

    • Integrating MES and ERP so production orders, material data, and quality results flow automatically between business and shop-floor systems.
    • Streaming data from sensors, controllers, and historians into analytics, reporting, and operations-intelligence platforms managed by IT.
    • Applying unified access control, patching, backup, and monitoring practices to both servers in the data center and industrial devices on the plant floor, with appropriate OT-specific constraints.
    • Supporting traceability and genealogy requirements by combining equipment event data with batch records, electronic device history records, or electronic batch records.

    Common confusion

    IT–OT convergence is often discussed alongside related concepts:

    • Industry 4.0 / smart manufacturing: IT–OT convergence is one enabling aspect of these initiatives but is more specific, focusing on how IT and OT systems and teams connect and collaborate.
    • IIoT (Industrial Internet of Things): IIoT emphasizes connected devices and data collection. IT–OT convergence is broader and includes governance, organizational integration, and enterprise-to-plant processes, not just device connectivity.
    • Network convergence: Combining IT and OT networks is one technical element of IT–OT convergence, but the term also covers applications, data, security practices, and organizational alignment.

    Relevance in regulated and compliant environments

    In regulated manufacturing, IT–OT convergence is closely linked to topics such as:

    • Data integrity and consistent handling of electronic records across enterprise and plant-floor systems.
    • Coordinated cybersecurity controls for both IT and OT assets, often aligned with industrial security standards.
    • Change management and validation practices that span MES, ERP, control systems, and interfaces between them.
    • Audit readiness, where evidence may rely on data and logs from both IT and OT systems.

    When planned and governed appropriately, IT–OT convergence provides a structured way to treat industrial control systems and enterprise information systems as parts of a single, managed operational ecosystem.

  • Tier-1 supplier

    A Tier-1 supplier is a company that delivers products, assemblies, or services directly to an original equipment manufacturer (OEM). In industrial and regulated manufacturing environments, Tier-1 suppliers typically provide complex, production-ready components or systems that integrate parts, materials, or services from lower-tier suppliers.

    Key characteristics of a Tier-1 supplier

    In most manufacturing supply chains, a Tier-1 supplier:

    • Has a direct commercial relationship with the OEM, including contracts, purchase orders, and direct performance reporting.
    • Delivers parts, assemblies, software, or services that are installed on, or directly support, the OEM’s final product.
    • Often manages and coordinates a network of Tier-2 and lower-tier suppliers that provide subcomponents, raw materials, or specialized processing.
    • Is usually responsible for meeting defined quality, traceability, and regulatory requirements set by the OEM and applicable standards.
    • May participate in design collaboration, change management, and advanced quality planning with the OEM.

    Operational role in industrial and regulated environments

    Within industrial operations, Tier-1 suppliers are often treated as strategic partners because their performance directly affects the OEM’s production, compliance posture, and delivery schedules. Typical operational responsibilities include:

    • Maintaining process controls and quality systems that satisfy OEM and industry standards.
    • Providing required documentation, such as certificates of conformance, inspection records, and traceability data.
    • Coordinating logistics, advanced shipping notices, and packaging requirements aligned with the OEM’s receiving and MES/ERP processes.
    • Managing sub-tier suppliers and outsourced processing to ensure end-to-end material and process traceability.

    What Tier-1 supplier does and does not include

    • Includes: Direct suppliers to the OEM that provide finished parts, integrated assemblies, major subsystems, software, or critical services (such as specialized testing or overhaul) tied to the final product.
    • Excludes: Suppliers that only provide inputs to other suppliers (Tier-2, Tier-3, etc.) and do not have a direct contractual or delivery relationship with the OEM.

    Common confusion

    • Tier-1 vs Tier-2 supplier: A Tier-2 supplier typically delivers to a Tier-1, not to the OEM. Tier-1 integrates and delivers to the OEM.
    • Tier-1 vs strategic supplier: Some OEMs call high-impact suppliers “strategic” regardless of tier. A Tier-1 designation is about position in the supply chain, not necessarily strategic importance.
    • Tier-1 vs prime contractor: In defense and aerospace, the prime contractor is often the OEM. Tier-1 suppliers deliver directly to the prime but are not the prime contractor themselves.

    Examples in manufacturing

    • An aerospace structures company that delivers fully assembled wings directly to an aircraft OEM is a Tier-1 supplier, even though it buys materials and machined parts from multiple Tier-2 and Tier-3 suppliers.
    • An electronics manufacturer providing certified avionics units directly to an aircraft or defense OEM, integrating circuit boards and software from lower-tier suppliers, is also a Tier-1 supplier.

  • Baseline Measurement

    Baseline measurement commonly refers to the initial, documented value of a process, system, or performance metric that is used as a reference point to compare future results. In industrial and regulated manufacturing environments, it is the quantified starting condition captured before a change, improvement initiative, or new control is implemented.

    What a baseline measurement includes

    A baseline measurement typically includes:

    • A clearly defined metric or set of metrics (for example, cycle time, yield, scrap rate, OEE, defect rate, downtime, or on-time delivery)
    • The measurement method and data sources (such as MES data, ERP reports, manual logs, or inspection records)
    • The time window and operating conditions under which the data was collected
    • Any assumptions, filters, or exclusions applied to the data set

    Baselines may be established at different levels, such as a single machine, a line, a work center, a product family, or a plant. In regulated environments, the method of establishing and storing baseline data is often documented to support traceability and audits.

    Operational use in manufacturing

    In manufacturing operations, baseline measurements are used to:

    • Assess the impact of process changes, continuous improvement projects, or new equipment by comparing pre-change and post-change performance
    • Support root cause investigations and CAPA by clarifying what “normal” performance looked like before a deviation or nonconformance
    • Set realistic targets for KPIs, service levels, or quality metrics
    • Document initial conditions required for validation, qualification, or formal process approval

    Systems such as MES, QMS, and data historians often store baseline measurements and subsequent trend data, enabling ongoing performance comparison and reporting.

    Common confusion

    • Baseline measurement vs. control limits: A baseline is the starting performance level; control limits are statistically derived thresholds used for ongoing process control.
    • Baseline measurement vs. target: The baseline is what the process is actually achieving at the start; the target is the desired future performance level.
    • Baseline measurement vs. one-time snapshot: A robust baseline is usually based on a representative data set over time, not a single reading, so it reflects typical operating performance.

    Ties to quality and improvement workflows

    Within quality management and continuous improvement, baseline measurements provide the reference for evaluating actions such as CAPA implementation, Lean projects, or equipment upgrades. For example, a team may document baseline scrap and rework rates before changing a work instruction, then compare subsequent data to determine whether the change produced a measurable difference.

  • Critical-to-Quality (CTQ)

    Core meaning

    Critical-to-Quality (CTQ) commonly refers to a product, service, or process characteristic that must meet a defined, measurable target to satisfy customer, user, or regulatory quality requirements.

    In industrial and regulated manufacturing environments, CTQs translate high-level needs (for example, safety, efficacy, reliability, or usability) into specific, observable measures that can be designed, controlled, and monitored on the shop floor or in supporting systems.

    Typical attributes of a CTQ include:

    – It is directly traceable to a customer, patient, user, or regulatory need.
    – It is measurable with a clear unit, method, and frequency of measurement.
    – It has defined specification limits or acceptance criteria.
    – Its failure is considered significant from a quality, safety, or compliance standpoint.

    Use in manufacturing workflows

    In manufacturing operations and quality systems, CTQs are used to:

    – Define key product characteristics such as dimensions, purity, potency, or mechanical strength.
    – Identify key process parameters (KPPs) that strongly affect product quality, such as temperature profiles, line speed, fill volume, or torque.
    – Structure control plans, inspection plans, and in-process checks around the characteristics that matter most.
    – Configure MES, LIMS, SCADA, or historian tags to capture, store, and trend the data tied to CTQs.
    – Support deviation investigations, root cause analysis, and continuous improvement by focusing analysis on CTQ performance.

    CTQs are often documented in design specifications, control plans, product quality profiles, or process FMEAs, and then implemented as specific data fields, limits, or alarms within OT/IT systems.

    Boundaries and what CTQ is not

    A CTQ:

    – Is a selected subset of all possible characteristics; not every measured attribute is necessarily CTQ.
    – Is defined at a level that can be practically measured and controlled.
    – Is usually stable over time but may be revised when customer requirements, regulations, or product designs change.

    CTQ does **not** refer to:

    – General process performance metrics (for example, OEE, throughput, or uptime) unless explicitly linked to a critical quality requirement.
    – Generic quality system elements such as SOPs, training, or documentation, although these support achieving CTQs.

    Relationship to other quality concepts

    CTQs are often derived from higher-level requirements such as:

    – Voice of the customer (VOC) or user requirements.
    – Regulatory requirements, standards, or product registration dossiers.
    – Internal reliability or safety targets.

    They are closely related to, but distinct from:

    – **Critical Quality Attributes (CQAs):** Common in regulated industries, especially life sciences. CQAs are a formal subset of quality attributes that must be controlled within limits to ensure product quality. Many CQAs are CTQs, but CTQ is a broader, cross-industry term.
    – **Critical Process Parameters (CPPs) or KPPs:** Process inputs that significantly affect CTQs or CQAs. CPPs/parameters describe *how* the process runs; CTQs describe *what must be achieved* in the output.

    Common confusion and misuse

    – **”Everything is CTQ”:** Labeling too many metrics as CTQ weakens the concept. CTQs should be limited to the characteristics with the highest impact on customer or regulatory outcomes.
    – **Confusing CTQ with general KPIs:** KPIs such as cycle time or equipment utilization are important but are not CTQs unless tied directly to a critical quality requirement.
    – **Using CTQ only at design time:** In practice, CTQs should remain visible in daily operations through control charts, alarms, and reports, not just in design documents.

    Site context application

    Within industrial operations and manufacturing systems, CTQs are a bridge between requirements and execution:

    – Product and process CTQs are captured in specifications and quality risk assessments.
    – MES and quality systems implement CTQs as data fields, required checks, interlocks, and limits.
    – Operations intelligence tools monitor CTQ data to detect trends, support investigations, and inform improvement projects.

    This usage ensures that OT/IT systems focus on monitoring and controlling the characteristics that are most critical to compliant, reliable manufacturing outcomes.

  • Containment

    Core meaning

    Containment commonly refers to temporary actions taken to isolate, control, or limit the impact of a detected problem, nonconformance, or risk. In industrial and manufacturing environments this usually involves preventing suspect product, data, or processes from progressing further in the value stream until the issue is understood and longer‑term corrective actions are defined.

    Containment may apply to:
    – Physical product (e.g., batches, lots, units, materials)
    – Digital records (e.g., electronic batch records, MES transactions, quality data)
    – Processes or equipment (e.g., temporarily stopping, bypassing, or restricting use)

    It is generally time‑bound and scoped, and it does not by itself eliminate the underlying root cause.

    Use in manufacturing and regulated operations

    In regulated and quality‑critical manufacturing, containment is used when a deviation, defect, or process failure is detected or suspected. Typical activities include:

    – **Identifying scope of impact**: Determining which lots, batches, orders, time windows, or equipment may be affected.
    – **Isolating product**: Quarantining or blocking release of in‑process or finished goods, often through inventory holds in MES or ERP.
    – **Controlling process flow**: Stopping production, disabling specific routes or recipes, or adding additional checks at certain operations.
    – **Protecting downstream operations and customers**: Preventing suspect material from reaching subsequent process steps, customers, or patients.

    Containment is typically documented in deviation reports, nonconformance records, or CAPA workflows in quality systems.

    Containment in OT/IT and MES contexts

    In operations technology (OT) and manufacturing execution systems (MES), containment often appears as system‑enforced controls, for example:

    – **Hold statuses and quarantine**: Automatically putting lots, batches, or work orders on hold based on alarms, test failures, or operator input.
    – **Electronic segregation**: Routing suspect material to dedicated inspection or rework operations instead of normal processing.
    – **Access and usage restrictions**: Temporarily disabling recipes, equipment, or test plans in MES or related systems until an investigation is complete.
    – **Data containment**: Flagging or excluding suspect measurement data from release decisions, analytics, or compliance reports.

    Integration with ERP and quality management systems allows containment actions in one system (e.g., a quality hold) to propagate and block related transactions elsewhere.

    Boundaries and what containment is not

    Containment:
    – **Is**: A short‑term control to prevent further impact while an issue is being investigated.
    – **Is not**: The same as corrective action or preventive action; it does not remove the root cause.
    – **Is**: Often the first step after a problem is detected.
    – **Is not**: A permanent process change, redesign, or improvement strategy.

    In many formal problem‑solving methods, containment is required before root cause analysis proceeds, to ensure ongoing production does not worsen the situation.

    Common confusion and related terms

    – **Containment vs. correction**: Correction is the act of fixing a specific detected nonconforming item (e.g., reworking a defective unit). Containment is broader and focuses on controlling all potentially affected items or processes, including those not directly inspected.
    – **Containment vs. corrective action (CA)**: Corrective action addresses the root cause so the problem does not recur. Containment only limits immediate risk and may be removed once effective corrective actions are in place.
    – **Containment vs. preventive action (PA)**: Preventive action addresses potential problems that have not yet occurred. Containment reacts to a problem that is already known or suspected.

    Recognizing these distinctions is important for accurate use of quality system terminology and for structuring investigations and documentation.

    Use in risk and safety management

    In a broader risk and safety context, containment can also describe:

    – **Physical containment**: Using barriers, enclosures, or zones to confine hazards (e.g., chemicals, biologics, energized equipment) to controlled areas.
    – **Procedural containment**: Implementing temporary work instructions, access controls, or emergency measures to prevent hazard propagation.

    In regulated environments, such measures are often linked to formal risk assessments and incident management processes.

  • Entity model

    An entity model is a structured representation of the key business objects in a domain, the data each object holds, and how those objects relate to one another. In manufacturing and industrial software, it commonly describes items such as materials, equipment, work orders, operations, batches, personnel, suppliers, and quality records.

    The purpose of an entity model is to define what the system treats as distinct entities and how information is organized around them. It is used in databases, application design, integrations, analytics, and reporting. A well-defined entity model helps different systems refer to the same real-world objects in a consistent way.

    An entity model usually includes:

    • Entities: the core objects being tracked, such as a part, machine, lot, or production order

    • Attributes: the properties of each entity, such as part number, revision, status, timestamp, or serial number

    • Relationships: how entities connect, such as a work order consuming materials, or a batch being produced on a specific line

    How it appears in operations systems

    In MES, ERP, PLM, QMS, and related platforms, the entity model shapes how data is stored and exchanged. For example, if a system defines product, routing, operation, and inspection result as separate entities, integrations and reports can link those records more clearly. This matters for traceability, genealogy, scheduling, deviation handling, and audit evidence assembly.

    Entity models are also important in system integration. When two systems use different entity models, mapping is needed so that one system’s object structure can be interpreted correctly by the other. For example, one platform may treat a batch as the main production entity, while another centers on serial numbers or work orders.

    What it includes and excludes

    An entity model includes the logical structure of business data and relationships. It does not by itself define screen layouts, process steps, user permissions, or physical database performance tuning, although those may be built on top of it.

    It also does not necessarily specify every rule for how data changes over time. Those rules may be handled separately in workflows, state models, business rules, or application logic.

    Common confusion

    Entity model vs. data model: An entity model is often a type of conceptual or logical data model focused on business objects and their relationships. In practice, some teams use the terms interchangeably, but a full data model may go further into technical structures such as keys, data types, and normalization.

    Entity model vs. object model: In software engineering, an object model may include behavior and methods as well as structure. An entity model usually focuses on the data entities themselves.

    Entity model vs. process model: A process model describes workflow, sequence, or activity flow. An entity model describes the things the process acts on.

    Manufacturing example

    A simple manufacturing entity model might define material, lot, work order, operation, equipment, operator, nonconformance, and inspection record as separate entities, with relationships showing which lot was used on which work order, on what equipment, and with which resulting quality records.

  • corrigendum

    A corrigendum is an officially published correction to an existing document, such as an international standard, regulation, technical report, or specification. In industrial and regulated environments, it commonly refers to a correction issued by a standards body or publisher to fix identified errors without republishing the entire document as a new edition.

    What a corrigendum includes

    A corrigendum typically addresses issues such as:

    • Typographical or formatting errors that may affect interpretation
    • Incorrect references, figures, tables, or cross-references
    • Minor technical errors, such as mis-stated parameter values, variable names, or units
    • Clarifications where the original wording is misleading or internally inconsistent

    The corrigendum is normally published as a short stand-alone document that specifies exactly what text, figure, or reference is replaced, deleted, or inserted in the original document.

    What a corrigendum does not usually cover

    A corrigendum generally does not introduce major new requirements, restructure the document, or change the overall scope or concept of the standard or procedure. Substantive changes of that kind are more often handled in separate amendments or full revisions.

    Operational meaning in industrial and regulated environments

    In manufacturing, OT/IT, and quality-managed environments, corrigenda are part of document control and standards management. Typical impacts include:

    • Tracking which standards and technical documents are in use, including their edition and any corrigenda applied
    • Updating internal procedures, specifications, or system configurations when a corrigendum corrects a value or requirement that affects operations
    • Adjusting validation, verification, or test documentation if a corrected requirement changes acceptance criteria or calculations
    • Maintaining evidence that the organization is aware of and has evaluated relevant corrigenda as part of change control

    For example, if a cybersecurity standard used for OT system design issues a corrigendum that corrects a misprinted network security parameter, engineering and compliance teams may need to review configurations, risk assessments, and related work instructions.

    Relationship to amendments and revisions

    Standards and formal documents may evolve through several mechanisms:

    • Corrigendum: Corrects identified errors or inconsistencies, usually without changing the overall technical intent.
    • Amendment: Adds, removes, or modifies specific requirements or sections, often to address new technology, practices, or interpretations.
    • Revision (new edition): Replaces the previous edition and may significantly restructure or expand the content.

    Organizations that rely on external standards for MES/ERP integration, automation, safety, or quality should track all three types of changes as part of formal document control.

    Common confusion

    • Corrigendum vs. errata: In some publishing contexts, errata are informal or publisher-level error lists, while a corrigendum is an official, controlled correction issued under the same governance as the original document. Usage can vary by organization.
    • Corrigendum vs. amendment: A corrigendum focuses on corrections to what should have been in the original document. An amendment intentionally changes or adds content after publication.

    Link to standards such as IEC 62443

    For standards like IEC 62443, individual parts may remain in force for many years while receiving targeted corrigenda and amendments. Plants and system integrators that reference specific parts of such standards in their OT cybersecurity, validation, or quality systems often need to:

    • Record the exact part, edition, and any associated corrigenda or amendments
    • Assess whether corrections affect existing designs, risk assessments, or controls
    • Apply change control and revalidation processes when necessary

    In this context, a corrigendum is treated as an official change record that must be evaluated and, when relevant, incorporated into controlled documentation and systems.