Connect981 – Content Dev

Glossary Tag: process monitoring

  • bill of materials

    Core meaning

    A **bill of materials** (BOM) is a structured list that specifies all components, raw materials, subassemblies, and sometimes services required to manufacture a defined product or execute a defined batch, including their quantities and basic identifying information.

    In industrial and regulated manufacturing environments, the BOM commonly:

    – Is defined and maintained in ERP, PLM, or product definition systems
    – Includes material identifiers, descriptions, units of measure, and required quantities
    – References engineering or product revisions to tie materials to a specific version of the product
    – Serves as a reference for planning, procurement, inventory management, and production execution

    A BOM describes **what** is needed to build a product, not **how** or **when** work is performed.

    Typical structure and levels

    BOMs are often hierarchical and may include:

    – **Top-level (finished good) BOM**: Lists main subassemblies and key materials that make up the final product
    – **Subassembly BOMs**: Define components for intermediate assemblies used within the top-level product
    – **Phantom or logical BOMs**: Groupings used for planning or design that may not exist as separate stocked items

    Depending on system and practice, BOMs may also identify alternates or substitutes, packaging materials, and labeling components when they are explicitly required to produce or release the product.

    Use in manufacturing workflows

    In integrated manufacturing environments, BOMs are used to:

    – Drive **material requirements planning** (MRP) and procurement in ERP systems
    – Define expected material consumption for **costing** and financial tracking
    – Inform **MES** or other shop-floor systems of required components for an order or batch
    – Support **traceability** by providing the expected structure against which actual material lots or serials are recorded

    During production, the BOM is typically linked to:

    – A **routing** or process definition (how work is done)
    – **Work orders**, production orders, or batch records (what is executed and when)
    – **Material master** data for each item listed

    Site context: BOM in MES–ERP integration and costing

    For program or product cost tracking across MES and ERP, the BOM commonly:

    – Resides and is maintained in ERP or PLM as the **authoritative product structure**
    – Provides the expected component list and standard quantities used to calculate standard or planned costs
    – Acts as the reference against which MES reports **summarized actual consumption** (by material ID and quantity) back to ERP at defined intervals

    In this context, MES usually does not author the BOM but uses it to validate material usage and ensure that recorded consumption aligns with the qualified product definition.

    Boundaries and exclusions

    A bill of materials **includes**:

    – Physical components, raw materials, and subassemblies
    – Sometimes non-stock items when they are integral to product composition (e.g., labels, certain consumables)

    A bill of materials **does not inherently include**:

    – Detailed work instructions, sequence of operations, or cycle times (these belong to routings or manufacturing instructions)
    – Real-time production data or yield results
    – Quality tests and acceptance criteria (these are typically defined in specifications or control plans)

    Some organizations maintain separate BOM types, such as **engineering BOM (EBOM)** and **manufacturing BOM (MBOM)**, to distinguish design intent from the structure used for actual manufacturing and sourcing.

    Common confusion and related terms

    – **BOM vs. recipe/formula**: In process industries, a *recipe* or *formula* includes process parameters and instructions in addition to material quantities. The BOM portion is the structured list of materials and quantities.
    – **BOM vs. routing**: A BOM defines *what materials* are required; a routing defines *how and in what sequence* operations are performed.
    – **BOM vs. product specification**: Specifications describe properties and performance requirements; the BOM lists the materials that make up the product.

    Understanding these distinctions helps ensure that BOMs are used consistently for planning, costing, and execution across ERP, MES, and quality systems.

  • control family

    A control family is a grouped set of related security, privacy, quality, or safety controls that share a common objective or topic within a formal framework or standard. Control families provide a structured way to organize individual controls so that organizations can plan, implement, and assess them systematically.

    What a control family includes

    In practice, a control family typically includes:

    • A collection of individual controls that address a similar risk area, process, or function, such as access control, configuration management, or incident response.
    • Sometimes, control enhancements or sub-controls that refine or strengthen a base control.
    • Framework-specific identifiers and labels that help with documentation, traceability, and audits.

    Control families appear in many frameworks used in industrial and regulated environments, including cybersecurity, information security, and quality management standards. They are used to organize requirements across OT and IT systems, MES/ERP integrations, data integrity, and other operational processes.

    Examples in common frameworks

    Examples of control families include:

    • NIST SP 800-53: Families such as Access Control (AC), Configuration Management (CM), System and Information Integrity (SI), and Audit and Accountability (AU). Each family contains multiple numbered controls and enhancements.
    • Other security and privacy frameworks: Similar groupings like identity and access management, change management, business continuity, or vendor management.
    • Quality and operational frameworks: Groupings such as document control, nonconformance and CAPA, equipment maintenance, or training and competence, even if they are not always labeled explicitly as “families.”

    How control families are used operationally

    In industrial and manufacturing contexts, control families are used to:

    • Structure policies and procedures (for example, a set of OT access control procedures aligned to an Access Control family).
    • Map technical and procedural controls in MES, ERP, QMS, and OT systems to specific framework requirements.
    • Plan assessments and audits by reviewing each family to confirm that required controls are defined, implemented, and evidenced.
    • Support risk analysis by viewing gaps and treatment plans by family (for example, all gaps in configuration management).

    Common confusion

    • Control family vs. control: A control is a single requirement or safeguard. A control family is a group of such controls organized around a shared topic.
    • Control family vs. baseline: A baseline is a selected set or level of controls (often across many families) for a given risk profile. A family is a topic-based grouping within the overall catalog of controls.
    • Control family vs. process area or domain: Some standards use terms like “domains” or “process areas” instead of “families.” These often serve the same organizational purpose but may be defined differently by each framework.

    NIST SP 800-53 context

    In NIST SP 800-53, a control family is a labeled group of security and privacy controls (for example, AC, AU, CM) that organizes the catalog. When counting or scoping controls for an implementation, organizations often determine which control families and corresponding baselines apply to their environment, including IT and OT systems that support manufacturing operations.

  • technical data

    Technical data commonly refers to detailed information that describes the design, manufacture, operation, maintenance, or testing of a product, system, or process. In industrial and regulated environments, it often has specific handling, export control, and information security implications.

    What technical data typically includes

    In manufacturing and industrial operations, technical data often covers:

    • Engineering designs and drawings, including CAD models and schematics
    • Manufacturing process instructions, routings, and control plans
    • Bill of materials (BOM) details beyond commercial part descriptions
    • Test methods, qualification procedures, and acceptance criteria
    • Product performance characteristics and tolerance data
    • Software source code or configuration details for embedded or control systems
    • Maintenance manuals, repair instructions, and overhaul procedures

    This information may exist in PLM, MES, ERP, document management, and quality systems, or as files exchanged with suppliers and customers.

    What technical data usually excludes

    Depending on the regulatory regime, technical data typically does not include:

    • Purely commercial or marketing materials (price lists, brochures, sales quotes)
    • Basic product descriptions that do not reveal detailed design or manufacturing know-how
    • General engineering knowledge that is widely taught or publicly available

    However, the exact boundary between technical data and non-technical information is defined by the applicable regulations, contracts, or internal policies.

    Technical data in regulated environments

    In many jurisdictions, technical data is a defined term in export control and defense-related regulations. In those contexts it can trigger specific obligations for:

    • Access control and user authorization within OT/IT systems
    • Cross-border transfers (email, file sharing, cloud storage, supplier portals)
    • Use of external service providers for design, analysis, or manufacturing
    • Recordkeeping and traceability of who accessed or shared certain documents

    Manufacturers often classify technical data to align with export control regimes or customer contract requirements and configure MES, PLM, and document control systems to enforce those classifications.

    Operational handling in manufacturing systems

    In day-to-day operations, technical data appears as:

    • Digital work instructions and standard operating procedures on the shop floor
    • Controlled drawings and specifications linked to part numbers and revisions
    • NC/CNC programs, control logic, and machine parameter sets
    • Test limits and calibration data used in inspection or automated testing

    Organizations typically govern technical data through document control, configuration management, and access control workflows. These workflows may integrate across MES, ERP, PLM, QMS, and content management systems to ensure that only authorized users can access specific technical data and that correct revisions are used in production.

    Information security and data loss considerations

    Because technical data can contain sensitive intellectual property or controlled information, it is often a focus area for information security and data loss prevention. Controls can include:

    • Role-based access control and segregation of duties
    • Network segmentation between OT and IT systems that store or process technical data
    • Monitoring and restrictions on file transfer, removable media, and printing
    • Encryption of repositories and communication channels where technical data is stored or transmitted

    Standards-based information security programs often require organizations to identify and classify technical data, assess risks related to its transfer and storage, and implement appropriate technical and procedural controls.

    Common confusion

    • Technical data vs. personal data: Technical data describes products and processes, while personal data relates to identifiable individuals. Both can be sensitive but are governed by different rules.
    • Technical data vs. trade secrets: Some technical data may qualify as trade secrets, but not all. Trade secret status depends on legal criteria and protection measures, not only on the type of information.
    • Technical data vs. operational data: Operational data (for example, machine telemetry or production counts) describes performance and events. Technical data describes how products are designed and manufactured. In some systems, both are stored together but are conceptually different.

    Link to data loss prevention and security standards

    In information security standards and risk assessments, technical data is often treated as a sensitive information category that requires controls on transfer, storage, and access. Data loss prevention tools, secure collaboration platforms, and controlled document workflows are examples of mechanisms that may be used to reduce the risk of unauthorized disclosure or leakage of technical data, especially when that data is subject to export controls or customer-imposed restrictions.

  • GRC

    GRC stands for governance, risk, and compliance. It commonly refers to a coordinated approach, set of processes, and supporting tools used by an organization to direct and control operations, manage risks, and meet regulatory and internal policy requirements in a consistent and traceable way.

    Core components of GRC

    In industrial and manufacturing environments, GRC typically includes:

    • Governance: How decisions are made and overseen. This covers roles, responsibilities, policies, standards, and escalation paths that direct how OT, IT, quality, safety, and security are managed.
    • Risk: Identification, assessment, treatment, and monitoring of risks, such as cyber risks in OT/ICS, safety risks, supply chain risks, and quality or compliance risks.
    • Compliance: Processes to interpret and implement external requirements (laws, regulations, standards) and internal policies, along with evidence management to show that required controls and procedures are followed.

    Operational meaning in manufacturing and OT

    In regulated manufacturing and industrial operations, GRC activities commonly include:

    • Defining and maintaining policies and standards for OT and IT systems, including security baselines and change control.
    • Maintaining control frameworks mapped to regulations and standards (for example mapping NIST SP 800-53 controls to the NIST Cybersecurity Framework for OT/ICS environments).
    • Conducting risk assessments for production systems, MES/ERP integrations, data flows, and third-party services.
    • Tracking issues, exceptions, and remediation actions (for example for cyber findings, audit findings, or quality deviations that have compliance impact).
    • Collecting and organizing audit-ready evidence from shop-floor systems, quality systems, and enterprise platforms.
    • Reporting risk posture, control coverage, and compliance status to leadership and regulators.

    Organizations may use dedicated GRC platforms or integrate GRC practices with existing tools such as ticketing systems, document control systems, MES, and cybersecurity monitoring solutions.

    Common confusion

    • GRC vs. cybersecurity: Cybersecurity is one risk domain managed within GRC. GRC is broader and also includes financial, operational, safety, and compliance risks.
    • GRC vs. quality management: Quality management focuses on product and process quality. GRC focuses on organizational governance, risk, and compliance. In regulated manufacturing, quality systems often feed evidence and risk data into the broader GRC framework.
    • GRC as a tool vs. a discipline: GRC is a management discipline and set of processes. GRC software tools support these processes but do not define them by themselves.

    Relation to the source context

    In the context of using NIST SP 800-53 to show NIST Cybersecurity Framework posture for OT/ICS, GRC provides the structure to map controls, aggregate risk and maturity information, maintain evidence for assessments, and report cybersecurity posture to leadership as part of an overall risk and compliance program.

  • Model validation

    Model validation commonly refers to the documented process of evaluating whether a model is suitable for its intended use, based on defined requirements, evidence, and acceptance criteria. In industrial and regulated environments, the term is often used for analytical, statistical, simulation, or machine learning models that support decisions, predictions, classifications, or process understanding.

    It includes checking that the model performs acceptably for the use case it is meant to support, using representative data, test methods, and review records. It does not mean the model is universally correct, permanently approved, or guaranteed to remain valid under all conditions. Validation is tied to scope, assumptions, inputs, data quality, and the environment in which the model is used.

    What it typically includes

    • Definition of intended use, scope, and decision impact

    • Assessment of input data quality and relevance

    • Testing against predefined performance or acceptance criteria

    • Review of assumptions, limitations, and failure modes

    • Documentation of methods, results, approvals, and changes

    • Periodic re-evaluation when the model, process, or data changes

    In manufacturing operations, model validation may apply to forecasting models, inspection algorithms, predictive maintenance models, yield or scrap prediction, scheduling logic, or quality risk scoring. For example, a machine learning model that flags potential nonconformances may be validated by testing how reliably it identifies relevant cases on representative production data.

    Common confusion

    Model validation is often confused with model verification. Validation asks whether the model is fit for its intended operational purpose. Verification focuses on whether the model was implemented correctly according to its specification or design. Both may be needed, but they are not the same.

    It can also be confused with process validation or equipment qualification. Process validation concerns whether a manufacturing process consistently performs as intended. Equipment qualification concerns whether systems or equipment are installed and operating as expected. Model validation is narrower and applies to the model itself and its intended decision context.

    Operational meaning in systems and workflows

    Within MES, QMS, analytics, or integrated IT/OT environments, model validation usually appears as controlled documentation, test evidence, approval workflows, version tracking, and change management. When a model is updated, retrained, or moved to a new production context, organizations commonly reassess the validation status rather than assuming prior results still apply.

  • Subgroup discovery

    Subgroup discovery is a data analysis method used to identify subsets of records that show a pattern, behavior, or outcome that differs meaningfully from the overall population. It is commonly used when a team wants to know not just what is happening on average, but which combinations of conditions are associated with unusually high scrap, low yield, delayed cycle time, quality escapes, or other operational signals.

    In manufacturing and regulated operations, subgroup discovery often works on production, quality, maintenance, or process data. A subgroup might be defined by a combination of attributes such as product family, machine, shift, material lot, supplier, operator qualification, environmental condition, or routing step. The result is not a single forecast or control limit, but a description of a subset that stands out statistically or operationally.

    What it includes and excludes

    Subgroup discovery generally includes:

    • Searching for data subsets with unusually high or low target values
    • Using interpretable conditions to describe those subsets
    • Comparing subgroup behavior against the full dataset or a baseline population
    • Ranking findings by measures such as significance, lift, coverage, or effect size

    It does not usually mean:

    • General clustering without a defined target outcome
    • Root cause confirmation on its own
    • Statistical process control charts or rational subgrouping in SPC
    • A complete causal model of the process

    How it appears in operations

    In practice, subgroup discovery may be used to scan MES, QMS, historian, LIMS, ERP, or maintenance data for combinations linked to specific outcomes. For example, an analysis might show that one subgroup of parts processed on a certain line, during a certain shift, with a specific supplier lot, has a much higher nonconformance rate than the plant average. That result can then be reviewed as a candidate signal for investigation.

    This makes subgroup discovery useful for surfacing localized issues that averages can hide, especially in high-mix production, multi-step processes, and environments where traceability data is available across systems.

    Common confusion

    Subgroup discovery is often confused with clustering and with SPC subgrouping.

    • Clustering groups records by similarity, usually without a predefined target variable. Subgroup discovery looks for subsets that are unusual with respect to a chosen outcome.

    • In SPC, a subgroup usually means a small set of observations collected under similar conditions for control charting. That is a different concept from subgroup discovery in data mining and analytics.

    • Association rule mining finds co-occurring conditions or events. Subgroup discovery is more focused on subsets that show a distinct target behavior or performance level.

    Why the term matters

    The term commonly appears in advanced analytics, process mining, and machine learning discussions where teams need interpretable findings rather than only black-box predictions. In regulated manufacturing, that interpretability can matter because discovered subgroups can be reviewed against process context, traceability records, and quality evidence before any operational conclusion is drawn.

  • Explainability (XAI)

    Explainability (XAI) commonly refers to methods, tools, and documentation used to help people understand how an artificial intelligence or machine learning system produced a result. In industrial and regulated environments, this usually means making model behavior more interpretable for operators, engineers, quality teams, and reviewers.

    XAI is not the same as the model being simple. A model can be complex and still have supporting explanations, such as feature importance, rule traces, confidence indicators, decision pathways, or example-based reasoning. XAI is also not a guarantee that a model is correct, unbiased, safe, or compliant. It only helps make the model’s logic, inputs, or output drivers more understandable.

    How it appears in operations

    In manufacturing and operational systems, XAI often appears where AI supports decisions that people need to review or act on. Examples include anomaly detection, predictive maintenance, visual inspection, process optimization, scheduling recommendations, and quality risk scoring. An explanation may show which sensor patterns, process variables, image regions, or historical factors most influenced the output.

    Operationally, XAI is often used alongside model monitoring, data lineage, audit trails, and human review workflows. For example, if a quality model flags a batch as high risk, the system may also show the variables that most influenced that score so a user can assess whether the result is reasonable.

    What XAI can include

    • Feature importance or contribution scores

    • Decision rules or surrogate rules for local explanations

    • Visualization of influential regions in images or signals

    • Confidence, uncertainty, or similar output qualifiers

    • Model cards, documentation, and explanation logs

    • Traceability between inputs, model version, and output

    Common confusion

    Explainability vs interpretability: These terms are often used interchangeably, but some teams use interpretability for models that are inherently understandable, such as simple rules or linear models, and explainability for techniques that help explain more complex models after the fact.

    Explainability vs transparency: Transparency usually refers to visibility into how a system is built, documented, and governed. Explainability focuses more specifically on understanding why a particular model output occurred.

    Explainability vs validation: An explanation helps users understand a result, but it does not by itself validate model performance or suitability for a given use.

    In regulated and quality-sensitive contexts

    In regulated operations, explainability is commonly relevant when AI outputs affect review, release, inspection, maintenance, or exception handling decisions. The practical goal is usually to support human understanding, reproducibility, and evidence gathering around model-driven outputs, especially when those outputs influence quality or operational actions.

  • evidence capture

    Evidence capture commonly refers to the collection, recording, and preservation of information that shows an activity, decision, check, or result occurred and can be verified later. In manufacturing and regulated operations, that evidence may support product traceability, quality records, training records, process adherence, maintenance history, or audit preparation.

    The term includes both the act of collecting evidence and the records created from that activity. Evidence can be digital or paper-based, but in operational systems it often includes time-stamped entries, user actions, electronic signatures where used, inspection results, photographs, machine data, approvals, exceptions, and links to related documents or batch and serial records.

    What it includes and what it does not

    Evidence capture includes gathering objective records from a process as work happens or immediately after a defined event. It may be manual, automated, or a combination of both.

    • Manual examples: operator checks, reason codes, defect notes, and supervisor approvals
    • Automated examples: equipment readings, system timestamps, barcode scans, and transaction logs
    • Connected examples: attaching photos, drawings, certificates, or test results to a work order, lot, or unit record

    It does not mean analysis by itself. Capturing evidence is different from reviewing, approving, trending, or investigating the evidence later. It also does not guarantee that the underlying process was compliant or correct. It only creates a record that can be examined.

    How it appears in operations and systems

    In practice, evidence capture appears in MES, QMS, ERP-connected workflows, digital work instructions, maintenance systems, and audit support processes. A system may require certain records before allowing a routing step to close, a nonconformance to progress, or a batch record to be completed.

    Common manufacturing examples include recording in-process inspection results, capturing first article measurements, logging equipment calibration status, documenting deviations, storing training acknowledgments, or preserving as-built and as-maintained history for a serialized item.

    Common confusion

    Evidence capture is often confused with document control, traceability, and audit trails.

    • Document control focuses on managing approved versions of documents and changes to them.

    • Traceability focuses on linking materials, parts, lots, serial numbers, and process history across the product lifecycle.

    • Audit trail commonly refers to the system-generated history of who changed what and when.

    Evidence capture can include parts of all three, but it is broader as an operational concept. It is about collecting proof relevant to a process or requirement, whether that proof comes from people, machines, or systems.

    Why the term matters in regulated manufacturing

    In regulated or high-accountability environments, evidence capture helps organizations retain objective records that support reviews, investigations, and demonstrations of process execution. The emphasis is usually on completeness, integrity, context, and retrievability of records rather than on storing data for its own sake.

  • Data imputation

    Data imputation is the process of replacing missing data values with estimated, inferred, or rule-based values so a dataset can still be analyzed, reported, or processed by software. It is commonly used in analytics, machine learning, quality reporting, and operational data pipelines when sensor readings, inspection results, timestamps, or transaction fields are incomplete.

    In manufacturing and regulated operations, data imputation usually refers to a data handling method, not to creating original evidence. It can help maintain continuity in calculations, dashboards, and models, but the imputed value is still a substitute for an observed value. For that reason, imputation should be distinguishable from actual recorded shop floor, lab, maintenance, or quality data.

    What it includes

    Data imputation can include simple or advanced approaches, such as:

    • Replacing blanks with a fixed value such as zero, a default code, or a known status

    • Using the mean, median, or most frequent value from similar records

    • Carrying forward the last known reading in time-series data

    • Estimating a value from related variables, historical patterns, or statistical models

    Example: if a production dataset is missing a temperature reading for one interval, an analytics workflow might estimate it from nearby timestamps so trend analysis can continue.

    What it does not mean

    Data imputation does not mean the missing value was actually measured, observed, or verified. It also does not mean source records have been corrected. In quality, traceability, or compliance-sensitive contexts, the original missingness often still matters even if an imputed value is used downstream for analysis.

    Common confusion

    Data imputation is often confused with data cleansing, data correction, and interpolation.

    • Data cleansing is the broader process of improving data quality, which may include standardization, deduplication, and error handling.

    • Data correction usually means fixing a known wrong value based on evidence, rather than estimating a missing one.

    • Interpolation is a specific form of estimation between known points, commonly used in time-series or process data.

    In some disciplines, imputation is discussed mainly as a statistical technique, while in operational systems it may appear as part of ETL, reporting logic, or analytics preprocessing.

    Why it matters in operations systems

    In MES, ERP, historians, and quality systems, missing data can affect KPI calculations, exception reporting, model outputs, and cross-system reconciliation. Data imputation is one way to keep those processes functioning, but it should be handled transparently so users can tell which values were observed and which were estimated.