Connect981 – Content Dev

Glossary Tag: process monitoring

  • OT security

    OT security refers to the practices, technologies, and processes used to protect operational technology systems and assets in industrial, infrastructure, and manufacturing environments. It focuses on the digital and physical security of equipment that monitors or controls physical processes, such as PLCs, DCS, SCADA systems, safety instrumented systems, and industrial networks.

    OT security commonly includes:

    • Identifying and managing OT assets, network segments, and communication paths
    • Controlling access to control systems and engineering workstations
    • Monitoring OT networks for abnormal activity, malware, or unauthorized changes
    • Protecting system configuration, firmware, logic, and recipes from tampering or loss
    • Coordinating with IT security to manage interfaces between enterprise IT and plant-floor OT
    • Supporting incident detection, response, and recovery in a way that preserves process safety and availability

    Scope in industrial and regulated environments

    In manufacturing and other regulated industries, OT security applies to production equipment, building and utility controls, and supporting infrastructure that directly affects product quality, safety, or regulatory compliance. It covers:

    • Control networks and fieldbuses connecting controllers, HMIs, and sensors
    • Engineering, maintenance, and historian systems that interact with control logic and process data
    • Interfaces between MES/ERP and OT systems where production orders, recipes, or quality data are exchanged
    • Remote access arrangements used by vendors, integrators, or corporate teams to support OT assets

    OT security measures are typically designed with strong attention to process safety, equipment protection, and continuous operations, which can constrain how and when security controls are deployed or updated.

    Relationship to IT security and CTI

    OT security is closely related to IT security but has different priorities and constraints. While IT security often emphasizes data confidentiality and integrity, OT security places additional emphasis on operational continuity and safety of people, equipment, and the environment.

    Cyber threat intelligence (CTI) for OT security focuses on threats, vulnerabilities, and attacker behaviors that affect industrial control systems and related assets. It can include information about OT-specific malware, exposed control interfaces, supply chain issues affecting firmware or devices, and tactics used to disrupt physical processes.

    What OT security is not

    • It is not limited to traditional office IT systems, such as email, end-user laptops, or business applications, although these may interact with OT networks.
    • It is not only physical security, such as locks and cameras, although physical controls are often part of an overall OT security program.
    • It is not a single product or tool; it typically combines policies, procedures, technical controls, and organizational roles.

    Common confusion

    OT security vs IT security: OT security deals with systems that directly influence physical processes, where changes can affect safety and production. IT security primarily concerns information systems handling data and business processes.

    OT security vs ICS security: ICS (industrial control system) security is a closely related term. In many contexts, ICS security is used as a subset of or synonym for OT security, with a particular focus on control systems like PLCs and SCADA. OT security can be broader, covering building automation, safety systems, and other non-ICS operational technologies.

  • Induction Condition

    Induction condition commonly refers to the starting condition required for an inductive process to be valid. In formal logic and mathematics, it is the base case or initial statement that must be shown true before a rule of induction can extend that truth to later cases. More broadly in technical and operational settings, the term can also refer to the initial condition that must exist before a process, model, or state progression is evaluated step by step.

    It is not the same as the induction step itself. The induction condition establishes the starting point, while the induction step explains how validity carries from one case or state to the next.

    How the term is used in technical and operational contexts

    In engineering, manufacturing systems, and analytics, the phrase may appear when documenting logic, validation rules, or state-based workflows. For example, a sequence model may require a defined initial machine state, batch state, or process state before downstream transitions can be interpreted correctly. In that sense, an induction condition is the prerequisite starting condition for evaluating the rest of the sequence.

    • In logic or software verification, it may mean the base case for a proof or recursive rule.
    • In process modeling, it may mean the initial state that allows later states or events to be inferred consistently.
    • In workflow validation, it may describe the required first condition before a series of checks or transitions is considered complete or meaningful.

    Common confusion

    Induction condition is often confused with:

    • Induction step: the rule showing how one valid case leads to the next valid case.

    • Precondition: a broader term for something that must be true before an action occurs. An induction condition is a specific kind of starting condition used in inductive reasoning or sequential validation.

    • Initial condition: often used in physics, control systems, and simulation. This can overlap with induction condition, but initial condition does not always imply an inductive proof or stepwise logical structure.

    Manufacturing-relevant example

    If a digital workflow evaluates whether a production sequence is complete, it may need an initial released order status or first recorded operation as the induction condition before subsequent operation history can be assessed in order.

  • Serial Number Control

    Serial Number Control commonly refers to the practice of assigning, recording, and governing a unique serial number for each individual unit of a product, component, asset, or assembly. It is used when items must be tracked at the unit level rather than only by part number, batch, or lot.

    In manufacturing and regulated operations, Serial Number Control typically includes the rules and system records that determine when a serial number is created, how it is linked to a specific item, and how that identifier follows the item through production, inspection, inventory, shipment, installation, service, or return. The serial number itself identifies one specific instance of an item, not the product design as a whole.

    This term does not usually mean general labeling alone. It refers more broadly to the control of the identifier and the associated records across business and shop floor systems such as ERP, MES, quality, and service systems.

    What it usually includes

    • Assignment of a unique serial number to an individual item

    • Rules for uniqueness, format, and reuse prevention

    • Status and history tied to that serial number, such as build, test, inspection, and shipment records

    • Links between the serial number and related data such as part number, revision, lot numbers, work order, and as-built configuration

    • Controls for scanning, lookup, reconciliation, and correction when exceptions occur

    How it appears in operations

    Operationally, Serial Number Control appears anywhere a process requires unit-level identity. Examples include assigning a serial number at assembly start, recording which serialized subcomponents were installed into a higher-level assembly, blocking shipment if a required inspection record is missing for a specific serial number, or retrieving the history of one returned unit during investigation.

    In integrated environments, serial number control often supports genealogy, electronic device history records, service history, warranty tracking, and targeted containment when a problem affects only certain units.

    Common confusion

    Serial Number Control is often confused with lot control or batch control. A serial number identifies one individual unit. A lot or batch identifies a group of units produced or handled together. Some operations use both at the same time, such as a serialized finished device made from lot-controlled raw materials.

    It can also be confused with an asset tag. An asset tag usually identifies an item for ownership or maintenance purposes after deployment. A serial number is typically tied to the product or component itself and may originate during manufacturing.

  • Shift template

    A shift template is a reusable scheduling pattern used to define how work time is organized across one or more shifts. It commonly includes planned start and end times, break structure, shift names or codes, assigned roles or crews, and the recurring pattern for days on and days off.

    In manufacturing and operations, a shift template is usually a planning object, not a record of actual attendance or labor performed. It helps structure staffing and production coverage in MES, ERP, workforce management, and related scheduling systems.

    What it includes

    • Shift start and end times

    • Day, night, weekend, or rotating shift patterns

    • Breaks, handover periods, or overlap windows

    • Crew, team, line, work center, or role assignments

    • Recurrence rules such as 2-2-3, 4-on/4-off, or Monday to Friday patterns

    A shift template may also be linked to calendars, production lines, work centers, or labor pools so that downstream systems can use the same planned operating pattern.

    What it is not

    A shift template is not the same as a timesheet, time clock record, or payroll transaction. It describes the planned schedule framework rather than confirming who actually worked, when exceptions occurred, or how hours were paid. It is also different from a detailed production schedule, which typically assigns specific jobs or orders to equipment and time slots.

    How it appears in operations systems

    Operational systems commonly use shift templates to generate daily schedules, define expected production windows, support capacity planning, and align labor availability with work orders. For example, a plant may use one template for weekday first and second shift coverage and a different template for a weekend maintenance crew.

    In integrated environments, the same template can influence reporting periods, KPI rollups, dispatch timing, and supervisor handoff routines. The template itself does not guarantee execution accuracy, but it provides the planned structure that other processes reference.

    Common confusion

    Shift template is often confused with shift schedule. A shift template is the reusable pattern, while a shift schedule is usually a specific dated instance created from that pattern.

    It can also be confused with a rota or roster. Those terms often emphasize which named employees are assigned, while a shift template may exist before individual people are assigned.

  • Early warning system

    An early warning system commonly refers to a set of methods, indicators, rules, and notifications used to detect signs of a developing problem before that problem becomes severe, disruptive, or visible in final outcomes. In manufacturing and regulated operations, it is typically used to identify emerging quality, production, maintenance, supply chain, compliance, or cybersecurity risks early enough for investigation and response.

    The term includes more than a simple alarm. An early warning system usually combines monitored inputs, thresholds or logic, and some form of escalation or reporting. Inputs may come from machines, sensors, process data, inspection results, operator observations, audit findings, supplier performance, or system logs. The goal is early visibility into changing conditions, not just confirmation that a failure has already occurred.

    It does not necessarily mean a fully automated platform. An early warning system can be manual, digital, or hybrid, as long as it is designed to surface leading signals of potential issues.

    How it appears in operations

    In day-to-day operations, an early warning system may appear as dashboards, exception reports, trend rules, alerts, escalation workflows, or review routines that highlight abnormal patterns. Examples include rising defect rates on a process step, repeated parameter drift on a line, late supplier deliveries that suggest an upcoming shortage, or repeated minor deviations that may indicate a broader control issue.

    • In quality, it may flag adverse trends before a formal nonconformance rate becomes unacceptable.

    • In maintenance, it may detect vibration, temperature, or cycle-count patterns that suggest pending equipment failure.

    • In supply chain operations, it may identify lateness, shortages, or demand changes that could affect production continuity.

    • In OT or IT environments, it may detect unusual activity or configuration changes that warrant review.

    What it includes and excludes

    An early warning system commonly includes signal collection, monitoring criteria, interpretation rules, and communication of potential issues. It may also include workflows for triage and follow-up.

    It does not automatically include root cause analysis, corrective action, or incident resolution. Those activities may follow the warning, but they are separate from the warning system itself.

    Common confusion

    Early warning system is often confused with an alarm system, KPI dashboard, or predictive maintenance model.

    • An alarm system usually indicates that a limit has already been exceeded and immediate attention is needed.

    • A KPI dashboard displays performance measures, but it is not an early warning system unless it is specifically designed to detect emerging risk and trigger review.

    • A predictive model can be one component of an early warning system, but the broader system also includes monitoring, interpretation, and action pathways.

    Manufacturing context

    In manufacturing systems, early warning systems are often tied to MES, ERP, QMS, historians, maintenance systems, or analytics tools. They help connect operational data to risk detection by surfacing weak signals before they become scrap, downtime, missed shipments, audit issues, or other material business events.

  • nonconformance trend analysis

    Nonconformance trend analysis commonly refers to the systematic review of nonconformance data over time to identify patterns, recurrence, frequency changes, and possible underlying causes. In manufacturing and regulated operations, it is used to understand whether defects, deviations, or other quality events are isolated or part of a broader process signal.

    The term includes analysis of attributes such as defect type, part number, product family, work center, supplier, shift, operation, disposition, severity, and occurrence rate. It does not mean the nonconformance record itself, and it is not the same as root cause analysis or corrective action, although it often informs both.

    How it appears in operations

    In practice, nonconformance trend analysis is often performed using NCR, CAPA, MES, ERP, QMS, inspection, or supplier quality data. Teams may review trends by week, month, lot, program, or production stage to see whether a category of issue is increasing, stable, or decreasing.

    • Recurring dimensional defects on a specific machine
    • Repeated documentation errors on a given routing step
    • Supplier-related nonconformances clustered by material or source
    • Rising rework events after an engineering or process change

    The purpose is descriptive: to detect quality signals early enough to support investigation, prioritization, and monitoring. Depending on the organization, this analysis may feed dashboards, management review, continuous improvement activity, or risk review.

    What it includes and excludes

    Nonconformance trend analysis usually includes both counts and context. Useful trend review may look at raw volume, rates relative to throughput, recurrence by category, and concentration by product, process, or supplier. A simple increase in total NCRs does not always indicate worsening quality if production volume also increased.

    It generally excludes final decisions about disposition, fault, or effectiveness unless those are analyzed as separate dimensions. It also does not by itself prove causation. A trend can indicate a pattern that warrants further review, but not necessarily the reason for it.

    Common confusion

    Nonconformance trend analysis is often confused with root cause analysis. Trend analysis shows patterns in what is happening; root cause analysis investigates why it is happening.

    It may also be confused with SPC. SPC focuses on statistical behavior of process measurements during production, while nonconformance trend analysis focuses on recorded quality events such as defects, deviations, or NCRs after detection.

    Another common confusion is with CAPA effectiveness review. CAPA review evaluates whether actions worked, while trend analysis may be one of the inputs used to judge whether recurrence changed over time.

  • Local KPI

    A local KPI is a key performance indicator used to measure performance within a specific part of an operation, such as a machine, workcell, production line, department, shift, warehouse area, or quality function. It is narrower in scope than an enterprise or plant-level KPI and is usually owned by the team closest to the work.

    In manufacturing and regulated operations, a local KPI commonly refers to a metric that helps monitor day-to-day execution in a defined area. Examples include first-pass yield for one line, schedule adherence for one workcenter, changeover time for one packaging cell, or right-first-time performance for a specific process step.

    A local KPI is not simply any number visible on a dashboard. To qualify as a KPI, the metric is generally treated as an important signal tied to operational control, performance review, or escalation within that local context.

    How it is used in operations

    Local KPIs often appear in shift boards, MES screens, team huddles, visual management boards, and supervisor reviews. They are used to track conditions that operators, technicians, leads, or area managers can influence directly.

    • At the equipment or line level, a local KPI may track downtime, scrap, cycle time, or output versus plan.

    • In quality workflows, it may track defect rate, rework rate, inspection backlog, or deviation closure time for a specific area.

    • In warehousing or materials flow, it may track pick accuracy, staging delays, or replenishment response time for a zone.

    Well-defined local KPIs are often linked upward to broader site or enterprise measures, but they remain focused on a limited operational boundary.

    What it includes and excludes

    Local KPI includes metrics scoped to a specific team, process, asset group, or area of responsibility. It can be leading or lagging, depending on whether it signals conditions early or reports outcomes after the fact.

    It does not necessarily mean the metric is informal, temporary, or less important. Some local KPIs are tightly controlled because they support quality, throughput, traceability, or risk monitoring in a regulated environment.

    It also does not mean the metric is globally standardized. A local KPI may be unique to one area if it reflects that area’s process constraints or control needs.

    Common confusion

    Local KPI vs enterprise KPI: A local KPI applies to a limited operational scope, while an enterprise KPI is used across a site, business unit, or company.

    Local KPI vs metric: A metric is any measure. A KPI is a metric treated as materially important for monitoring or managing performance.

    Local KPI vs OEE: OEE is a specific composite performance measure. A local KPI can be OEE for one asset or line, but it can also be any other important area-level indicator.

    Manufacturing example

    If a plant tracks on-time delivery at the site level, a local KPI beneath it might track queue time at one bottleneck workcenter. The local KPI helps explain and manage the part of the workflow that contributes to the broader result.

  • Time grain

    Time grain is the level of time detail at which data is recorded, aggregated, displayed, or analyzed. It commonly refers to the size of the time interval used in a dataset or report, such as seconds, minutes, hours, days, weeks, or production shifts.

    In manufacturing and industrial systems, time grain affects how operational events are represented across MES, ERP, historian, SCADA, quality, and analytics workflows. For example, machine state changes may be captured at a second-level grain, while production reporting may be summarized by shift or by day.

    What it includes and excludes

    Time grain includes the temporal resolution of a record or metric. It does not, by itself, define the total time period being analyzed. A report can cover one month of data but still use an hourly or daily time grain.

    • Includes: the interval used for timestamps, aggregation, trending, and reporting
    • Excludes: the overall date range, retention period, or refresh frequency unless those are defined separately

    How it shows up in operations

    Time grain matters when comparing data across systems or deciding whether a metric is suitable for a given use. Finer grain data can show short stoppages, alarms, or process variation. Coarser grain data is more common for management reporting, scheduling, financial rollups, or longer-term quality trends.

    Examples in manufacturing include:

    • equipment downtime tracked by second or minute
    • OEE summarized by hour or shift
    • scrap trends reviewed by day or week
    • ERP production quantities posted by day or reporting period

    Common confusion

    Time grain is often confused with time range and sampling rate. Time range is the total period under review, such as the last 30 days. Sampling rate refers to how often a sensor or system captures raw observations, which may be finer than the grain used for reporting. Time grain is also different from update frequency, which describes how often a dashboard or interface refreshes.

    In analytics and data warehousing, the term may also be discussed alongside data granularity. Time grain is the time-specific part of that broader idea.

  • Process capability index (Cpk)

    Process capability index (Cpk) is a statistical measure used to indicate how well a stable process can produce output within defined specification limits. It compares the process average and variation to both the upper and lower specification limits, then reports the side where the process is performing worst.

    Cpk is commonly used in manufacturing and quality control to summarize whether a process is both centered and consistent enough to meet engineering requirements. A higher Cpk generally indicates that the process output is farther from the nearest specification limit relative to its variation.

    What it includes and what it does not

    Cpk includes two core ideas: process spread and process centering. It reflects not only how much the process varies, but also whether the process mean is shifted toward one specification limit.

    Cpk does not itself prove that a process is in statistical control, and it does not replace measurement system analysis, sampling plans, or product acceptance decisions. It is a capability indicator, not a direct statement that every part is conforming.

    How it is used in operations

    In production environments, Cpk is commonly calculated for critical dimensions, fill weights, temperatures, torque values, or other measurable characteristics with upper and lower specifications. Teams may review it during process qualification, ongoing process monitoring, supplier quality reviews, or continuous improvement work.

    In MES, QMS, SPC, or reporting systems, Cpk may appear as a quality metric tied to a part number, operation, machine, line, tool, or characteristic. It is often used alongside control charts and other process performance measures.

    Common confusion

    Cpk is often confused with Cp. Cp measures potential capability based on process variation alone and assumes the process is centered. Cpk adjusts for actual centering, so it is usually the more realistic index when the process mean is not exactly on target.

    Cpk is also sometimes confused with Ppk. While usage varies by organization, Ppk commonly refers to long-term or overall process performance using actual overall variation, whereas Cpk commonly refers to capability based on within-process variation under more controlled conditions.

    Practical interpretation notes

    • Cpk is most meaningful when the characteristic is measurable on a continuous scale and the process is reasonably stable.

    • The index depends on valid specification limits set by design or customer requirements.

    • Poor measurement quality can distort the result, so gage capability matters.

    • A single Cpk value does not explain the cause of variation or process shift.

    For example, a machining process for a bore diameter may show a lower Cpk if the average diameter drifts close to the upper tolerance, even if the overall spread has not changed.