Connect981 – Content Dev

Glossary Tag: process monitoring

  • Configuration versioning

    Configuration versioning is the practice of assigning identifiable versions to a system, application, device, process, or equipment configuration as it changes over time. It commonly refers to keeping a controlled history of settings, parameters, logic, mappings, templates, and other non-code configuration items so current and prior states can be identified and compared.

    In industrial and regulated environments, configuration versioning is used to understand what configuration was active at a given time, who changed it, when it changed, and what changed between versions. This can apply to MES rules, ERP integration mappings, PLC or SCADA parameters, electronic forms, work instruction settings, quality workflows, user-role configurations, and similar controlled setup data.

    Configuration versioning does not mean any change is automatically approved or released. It is about maintaining version identity and history. Approval workflows, change control, and document control may be related, but they are separate controls.

    What it typically includes

    • Version numbers, revision IDs, or other unique identifiers for a configuration state

    • Records of additions, removals, or edits to configuration items

    • Date, time, and user attribution for changes

    • Comparison between versions

    • Rollback or restoration to a prior known configuration, where supported

    • Linkage to deployment, release, or change records in broader governance processes

    Common confusion

    Configuration versioning is often confused with document version control and source code version control. Document version control applies to files such as SOPs, specifications, or controlled forms. Source code version control applies to software code. Configuration versioning focuses on operational settings and structured system behavior that may exist outside code files or formal documents.

    It is also distinct from a full audit trail. An audit trail may record every event or field-level change. Configuration versioning usually emphasizes named, recoverable configuration states and their revision history.

    Manufacturing context

    In manufacturing systems, configuration versioning commonly appears where system behavior must remain stable and explainable across production runs, quality events, or integration updates. Examples include versioned routing parameters in MES, revised inspection plan settings, changes to label templates, or updates to ERP-to-MES field mappings. The goal is to preserve a reliable record of which configuration was in effect for a given operation or period.

  • AI-assisted root cause analysis

    AI-assisted root cause analysis commonly refers to the use of artificial intelligence techniques to help investigate why a problem occurred in a process, system, or operation. In manufacturing and regulated environments, it is typically used to support analysis of deviations, nonconformances, downtime events, yield loss, alarm patterns, or recurring quality issues by finding patterns, correlations, sequences, or anomalies across available data.

    It is a support method, not the root cause itself and not a guarantee that the suggested cause is correct. The output is usually a ranked set of likely contributing factors, evidence links, or investigation leads that people review alongside process knowledge, documented procedures, and formal quality methods.

    What it usually includes

    • Analysis of data from MES, ERP, QMS, historians, CMMS, SCADA, LIMS, or maintenance logs

    • Pattern detection across events such as scrap spikes, machine faults, parameter drift, changeovers, or supplier-related defects

    • Use of machine learning, statistical models, rules, knowledge graphs, or generative AI to summarize evidence and propose likely causes

    • Tracing possible relationships among materials, equipment states, operators, work orders, batches, or process settings

    What it does not mean

    • It does not replace structured problem-solving methods such as 5 Whys, fishbone analysis, fault tree analysis, or formal RCCA workflows.

    • It does not prove causation simply because it finds correlation.

    • It is not the same as corrective action, CAPA execution, or verification of effectiveness.

    • It is not limited to generative AI chat tools. Many implementations use analytics models or rules engines without a conversational interface.

    How it appears in operations

    Operationally, AI-assisted root cause analysis often appears as a feature in quality, manufacturing, reliability, or analytics software. A system may ingest event records, process parameters, genealogy, maintenance history, and inspection results, then highlight common precursors or probable drivers of an issue. For example, it may associate recurring surface defects with a specific material lot, machine setting range, tool wear pattern, or sequence of alarms before failure.

    In regulated manufacturing, the value of the term usually depends on traceable inputs, retained evidence, and clear distinction between system-generated suggestions and human conclusions.

    Common confusion

    AI-assisted root cause analysis is often confused with predictive maintenance, anomaly detection, or incident summarization. Predictive maintenance focuses on forecasting failures before they occur. Anomaly detection flags unusual behavior. Incident summarization condenses records or logs. AI-assisted root cause analysis is narrower: it focuses on explaining why a specific problem likely happened.

  • Drill-down

    Drill-down commonly refers to navigating from a high-level summary into progressively more detailed information. In manufacturing and industrial software, it is used to investigate a metric, event, record, or exception by moving from dashboards or aggregated reports into the underlying data.

    The term usually applies to reporting, analytics, MES, ERP, quality, and traceability systems. For example, a user might drill down from plant-level throughput to a production line, then to a work order, and then to a specific machine event or operator entry. The core idea is structured detail navigation, not just opening another screen.

    Drill-down includes hierarchical or linked exploration of related data, such as moving from:

    • a KPI to the transactions or events behind it
    • a nonconformance count to individual NCR records
    • a batch summary to lot, material, or genealogy details
    • an equipment alarm total to time-stamped alarm history

    It does not usually mean root cause analysis by itself, although drill-down is often a step used during investigation. It also does not necessarily imply write access or workflow action; many drill-down paths are read-only views for analysis and verification.

    Common confusion

    Drill-down is often confused with filtering, sorting, and search. Filtering narrows a data set by conditions. Sorting changes display order. Search locates matching records. Drill-down specifically means moving from summary information to the lower-level details behind that information.

    It can also be confused with traceability. Traceability focuses on lineage and relationships across materials, processes, and records. Drill-down is a navigation method that may be used to access traceability data, but it is not the same concept.

    How it appears in operations systems

    In regulated and quality-sensitive environments, drill-down is commonly used to review exceptions, reconcile data between systems, and inspect evidence behind reported metrics. Typical examples include moving from an ERP production summary into MES execution records, or from a quality dashboard into inspection results, deviations, or CAPA-linked records.

  • CMMS (Computerized Maintenance Management System)

    CMMS (Computerized Maintenance Management System) commonly refers to software used to manage maintenance operations for physical assets such as machines, utilities, tools, facilities, and support equipment. It typically stores asset records and helps organizations plan, assign, track, and document preventive, corrective, and sometimes predictive maintenance work.

    A CMMS is primarily focused on maintenance execution and maintenance records. Common functions include work order management, preventive maintenance scheduling, asset hierarchies, spare parts and inventory tracking, labor assignment, downtime or failure history, and maintenance reporting. In regulated manufacturing, CMMS data may also support equipment history, calibration-related coordination, and documented evidence of maintenance activity, but the term itself does not mean a full quality system or compliance platform.

    What it includes

    • Asset and equipment master records

    • Preventive maintenance schedules and task lists

    • Corrective maintenance work orders and service logs

    • Spare parts, storeroom, and reorder tracking

    • Maintenance labor, contractor, and resource planning

    • Failure, downtime, and repair history for equipment

    What it does not necessarily include

    A CMMS does not automatically include broader manufacturing execution, production scheduling, enterprise finance, or formal quality management capabilities. Some platforms overlap with EAM, ERP, MES, or calibration systems, but those are separate concepts even when integrated in one software environment.

    How it appears in operations

    In day-to-day workflows, a CMMS is often where maintenance teams receive or create work orders, schedule recurring service, record parts used, capture technician notes, and close completed tasks. It may exchange data with ERP for purchasing and inventory valuation, with MES or SCADA for equipment events, or with quality systems when maintenance affects equipment status or production readiness.

    Common confusion

    CMMS vs. EAM: EAM, or Enterprise Asset Management, usually has a broader scope that can include lifecycle planning, capital assets, procurement, and multi-site asset governance. CMMS often refers to the maintenance-focused subset.

    CMMS vs. MES: MES manages production execution, routing, traceability, and shop-floor process control. CMMS manages maintenance work on the equipment and infrastructure used in production.

    CMMS vs. ERP: ERP manages enterprise-wide business processes such as finance, purchasing, and inventory accounting. A CMMS may connect to ERP, but it is not the same system.

  • Model card

    A model card is a structured document that summarizes what an artificial intelligence or machine learning model is, what it was designed to do, how it was evaluated, and what limits or risks should be understood before use. It commonly refers to a human-readable description that travels with the model or is linked to it in a repository, application, or governance workflow.

    In industrial and regulated environments, a model card is typically used as supporting documentation for transparency and internal review. It can help teams understand the model’s purpose, input and output expectations, training or reference data characteristics at a high level, performance measures, known constraints, and operational assumptions. It is documentation about the model, not the model itself.

    What it usually includes

    • The model’s name, version, and owner or maintaining team

    • Intended use cases and users

    • Out-of-scope or prohibited uses

    • Input data expectations and output format

    • Summary of how the model was trained or configured

    • Evaluation approach and reported performance metrics

    • Known limitations, failure modes, or bias considerations

    • Operational dependencies such as data quality, thresholds, or human review requirements

    How it appears in operations

    Model cards often appear in AI governance records, MLOps repositories, validation packages, supplier documentation, or approval workflows tied to analytics and decision-support tools. For example, a manufacturer using a machine learning model for visual inspection or maintenance prediction may keep a model card alongside version-controlled deployment records so quality, engineering, and IT stakeholders can review the model’s stated purpose and limits.

    Common confusion

    A model card is often confused with related artifacts, but they are not the same:

    • Data sheet or dataset documentation: describes the dataset rather than the model.

    • System documentation: covers the broader application, workflow, or architecture, not just the model.

    • Validation report: provides evidence from testing or qualification activities, while a model card is a summary-oriented description.

    • Algorithm specification: may describe logic or mathematics in depth, whereas a model card is usually broader and more operational.

    Boundary of the term

    The term commonly refers to documentation for AI or machine learning models, including predictive, classification, detection, or generative models. It does not by itself imply regulatory approval, production readiness, cybersecurity assurance, or fitness for a specific quality-critical decision. Those determinations depend on the surrounding governance, validation, and operational controls.

  • API-based KPI access

    API-based KPI access commonly refers to the ability to retrieve key performance indicator data through an application programming interface (API) rather than only through dashboards, spreadsheets, or manual exports. In manufacturing and regulated operations, this usually means systems such as MES, ERP, quality, historian, or analytics platforms expose KPI values, counts, rates, or trends in a machine-readable form for other software to consume.

    The term includes both direct access to calculated KPIs and access to the underlying operational data used to calculate them, depending on how a system is designed. It does not by itself mean that the KPI definitions are standardized, that the data is real-time, or that different systems calculate the same metric in the same way.

    Where it applies

    API-based KPI access appears in workflows where performance data needs to move between systems, teams, or reporting layers. Examples include pulling scrap rate from MES into an enterprise analytics tool, reading schedule attainment from ERP into a plant dashboard, or exposing quality trend data to a reporting application.

    • Operational dashboards and BI tools
    • MES and ERP integration
    • Quality and compliance reporting
    • Data lakes, analytics platforms, and custom applications
    • Cross-site or enterprise performance rollups

    What is typically exposed

    Depending on the platform, API-based KPI access may provide:

    • Current KPI values such as OEE, yield, scrap rate, downtime, or on-time completion
    • Time-series KPI history by shift, work order, line, machine, or site
    • Dimensions and filters such as product, operation, lot, or date range
    • Metadata such as units, timestamps, calculation windows, and data source references

    Common confusion

    API-based KPI access is often confused with KPI visualization. A dashboard shows KPIs to a person, while an API exposes KPI data to another system or script.

    It is also different from general data integration. Data integration may move raw transactions, events, or master data; API-based KPI access is specifically about making performance indicators available programmatically.

    Another point of confusion is real-time access. An API can expose near-real-time, batch-refreshed, or historical KPI data. The term does not guarantee update frequency.

    Operational meaning

    In practice, API-based KPI access supports automated retrieval of operational signals without relying on manual extraction. In regulated manufacturing, this matters when KPI data is reused across reporting, investigations, quality review, or performance monitoring processes, because the source system, timestamps, and calculation logic may need to be understood clearly even when the API access itself is technically simple.

  • First-Pass Containment

    First-pass containment commonly refers to the immediate actions taken to isolate, identify, and control potentially nonconforming product, material, or process output as soon as an issue is detected. Its purpose is to prevent further use, shipment, or processing of affected items while the organization verifies scope and decides on next steps.

    In manufacturing and regulated operations, first-pass containment is an initial control step, not a final disposition. It may include stopping a line or operation, segregating stock, placing inventory on hold, tagging affected units, blocking transactions in MES or ERP, or increasing inspection on suspect lots. The exact actions vary by process and quality system.

    The term generally includes short-term actions performed before full root cause analysis is complete. It does not by itself mean the issue has been corrected, that corrective action is complete, or that all affected material has been fully identified.

    What it includes

    • Immediate control of suspect product or process output

    • Temporary measures to reduce further escape or use

    • Initial scoping of affected lots, serial numbers, work orders, or time windows

    • Communication to operations, quality, and sometimes suppliers or customers when relevant

    • System-level holds or status changes to preserve traceability and prevent movement

    What it does not include

    • Formal root cause determination

    • Permanent corrective action

    • Final material review or disposition

    • Verification that recurrence risk has been eliminated

    Operational meaning

    In daily workflows, first-pass containment often appears as the first documented response after a defect, test failure, process deviation, or supplier issue is found. Quality teams may open an NCR, place affected inventory in quarantine, trigger additional inspections, and use traceability records to identify where else the issue could exist. In digital environments, containment can also involve transaction locks, alerts, genealogy review, and status changes across MES, ERP, or QMS records.

    Common confusion

    First-pass containment is often confused with correction, corrective action, and disposition.

    • Correction is the action taken to fix a detected problem or affected item.

    • Corrective action addresses the underlying cause to reduce recurrence.

    • Disposition determines what happens to the affected material, such as rework, scrap, return, or use-as-is approval where applicable.

    Containment comes earlier and is mainly about immediate control.

  • Edge Device

    An edge device is hardware located near machines, production lines, sensors, or other industrial assets that collects, processes, stores, or routes data close to where it is generated. In manufacturing, edge devices commonly connect operational technology systems to plant networks, MES, SCADA, historians, cloud services, or analytics platforms.

    Edge devices may include industrial PCs, gateways, embedded controllers, smart sensors, or ruggedized compute modules. They are often used to filter data, translate protocols, buffer records during network interruptions, run local analytics, or support real-time monitoring without sending every raw signal to a central system.

    An edge device is not necessarily the same as a PLC or a sensor, although those devices may have edge capabilities. A PLC primarily controls equipment logic, while an edge device usually focuses on data acquisition, communication, and local computing. The term is also related to edge computing, which refers to the broader architecture of processing data near the source rather than only in a centralized data center or cloud environment.

  • Sensitivity analysis

    Sensitivity analysis is a method for evaluating how much an output changes when one or more inputs, assumptions, or parameters are varied. It is commonly used in manufacturing, quality, planning, and analytics to understand which factors have the greatest influence on a result.

    In practice, the term usually refers to testing a model, calculation, forecast, or process metric by changing selected variables and observing the effect. Examples include changing demand assumptions in a planning model, adjusting process parameters in a yield model, or examining how scrap rate, cycle time, or supplier lead time affects cost or schedule performance.

    Sensitivity analysis does not by itself prove cause and effect, validate a model, or determine the single correct operating setting. It is an analytical technique for understanding responsiveness, uncertainty, and relative influence.

    Where it applies

    In industrial and regulated operations, sensitivity analysis may appear in:

    • production planning and capacity scenarios

    • cost, margin, and inventory modeling

    • quality and process-improvement studies

    • risk assessments and contingency planning

    • engineering and process development work, including design of experiments and simulation

    It can be performed with simple spreadsheet models or with more formal simulation, statistical, or optimization tools.

    Common confusion

    Sensitivity analysis is often confused with scenario analysis and design of experiments.

    • Scenario analysis usually compares a defined set of combined conditions, such as best case, expected case, and worst case.

    • Sensitivity analysis focuses on how the output responds when specific inputs are changed, often one at a time or across a defined range.

    • Design of experiments (DoE) is a structured experimental method used to study factor effects and interactions in real or simulated processes.

    It is also not the same as measurement sensitivity, which refers to how responsive an instrument or detection method is.

    Manufacturing example

    A planner may test how a 5 percent change in forecast demand, supplier lead time, or machine uptime affects required inventory and promised ship dates. A quality engineer may assess how variation in temperature, dwell time, or torque changes predicted defect rates. In both cases, the goal is to identify which inputs matter most and where tighter control or better data may be needed.