Connect981 – Content Dev

Glossary Tag: signal detection

  • FAIR

    A FAIR is a First Article Inspection Report, a structured document used in aerospace and other regulated manufacturing to demonstrate that a newly produced or significantly changed part meets all applicable design, drawing, and specification requirements. It captures the inspection results, traceability data, and approvals associated with a First Article Inspection (FAI) activity.

    What a FAIR includes

    In an aerospace context, a FAIR typically includes:

    • Part and assembly identification (part numbers, revisions, serial or lot numbers)
    • Customer, supplier, and purchase order information
    • Drawing and specification references, including revision levels
    • Ballooned (numbered) characteristics linked to inspection results
    • Measured values for each characteristic and pass/fail status
    • Material, special process, and test records references
    • Manufacturing process, operation, or router references
    • Signatures or electronic approvals by quality and/or customer representatives

    FAIRs are often generated to align with the AS9102 First Article Inspection standard, but the term is also used more broadly for similar reports in other regulated sectors.

    Operational use in manufacturing systems

    Operationally, FAIRs appear as controlled documents and dataset records that connect engineering, production, and quality systems. They may be:

    • Created from templates that follow AS9102 or customer-specific formats
    • Linked to bill of materials (BOM), CAD models, and ballooned drawings
    • Populated using data from MES, ERP, PLM, and measurement systems
    • Managed under document control and revision governance for repeat builds
    • Stored as part of the product or lot history for audit and customer review

    Digital FAIR forms often implement validation rules, required fields, characteristic libraries, and workflow enforcement to reduce manual errors compared with spreadsheet-based approaches.

    Common confusion

    FAIR vs. FAI: FAI (First Article Inspection) refers to the activity and process of verifying a part against design requirements. FAIR (First Article Inspection Report) refers to the documented record of that inspection. In practice, many people use FAI and FAIR interchangeably, but the report is the output of the inspection process.

    FAIR vs. general inspection report: A FAIR is specific to first article or initial production validation (for a new part, new supplier, or significant change). Routine in-process or final inspection reports are related but are not typically referred to as FAIRs unless they are fulfilling a first article requirement.

    Relationship to AS9102 and aerospace compliance

    Under common aerospace practices, a FAIR is structured to align with AS9102 requirements for First Article Inspection. This often includes standardized forms (such as separate forms for part identification, product accountability, and characteristic accountability) and consistent traceability to drawings, specifications, and manufacturing processes. Digital FAIR workflows may integrate with platforms such as MES, PLM, and customer portals to support submission, approval, and long-term retention.

  • warehouse management system

    Core meaning

    A warehouse management system (WMS) is specialized software used to control, execute, and track warehouse and distribution center operations. It manages how inventory is stored, moved, counted, and picked within one or more physical warehouse locations.

    A WMS commonly:

    – Maintains inventory records at detailed location levels (e.g., aisle, rack, bin)
    – Directs receiving, put-away, picking, packing, shipping, and internal transfers
    – Supports barcode/RFID scanning and mobile devices on the warehouse floor
    – Enforces warehouse rules such as FEFO/FIFO, lot rotation, or storage constraints
    – Records traceable stock movements (who moved what, where, when, and why)
    – Interfaces with higher-level systems such as ERP, MES, and transportation systems

    Use in manufacturing and regulated operations

    In industrial and regulated environments, a WMS is used to manage raw materials, intermediates, and finished goods across warehouses and staging areas. It typically:

    – Integrates with ERP for orders, material masters, and financial posting
    – Integrates with MES or production systems for material consumption and production receipts
    – Maintains lot/batch, serial, and sometimes status information (e.g., released, quarantined)
    – Provides transaction histories that support traceability and investigations
    – Supplies operational data for inventory accuracy KPIs and cycle counting performance

    In some plants, WMS functionality may be embedded within an ERP or MES rather than deployed as a standalone system.

    Boundaries and scope

    A WMS generally includes:

    – Physical inventory control and real-time stock visibility inside warehouses
    – Operational task management (e.g., work queues for pickers, put-away tasks)
    – Location and capacity management for storage areas

    A WMS typically does **not** include:

    – Enterprise-level planning (handled by ERP, APS, or planning tools)
    – Shop-floor process control or detailed production routing (handled by MES/SCADA)
    – Transportation planning and optimization beyond basic shipping interfaces (handled by TMS)

    Common confusion and related terms

    – **WMS vs. ERP:** An ERP system holds financial, purchasing, and high-level inventory data. A WMS handles the detailed, physical execution of warehouse operations and location-level movements. In some solutions, WMS is a module within ERP.
    – **WMS vs. inventory management:** General inventory management refers to policies, planning, and accounting for stock. A WMS is a specific software system that executes and records physical inventory movements and storage.
    – **WMS vs. MES:** MES focuses on production execution (work orders, process steps, equipment states). WMS focuses on warehouse and material storage operations, even when located near or inside the plant.

    Site-context application: inventory accuracy KPIs

    In the context of inventory accuracy and KPI reviews, the WMS is often the system of record for:

    – On-hand quantities at bin or location level
    – Historical movement transactions used to analyze discrepancies
    – Cycle count results and variance records

    Inventory accuracy KPIs (e.g., location accuracy, count accuracy, value accuracy) are usually derived from data maintained and time-stamped in the WMS and reconciled against ERP or financial systems.

  • lot tracking

    Core meaning

    Lot tracking is the practice of recording, maintaining, and querying the history of materials and products using a **lot** (or batch) identifier rather than a unique serial number for each individual unit.

    A lot typically represents a group of units that share key attributes, such as:

    – Common manufacturing or receipt event (e.g., a batch made on a specific line and date)
    – Common source (e.g., same supplier shipment)
    – Common specification or grade

    In lot tracking, all units within the lot are treated as having the same traceability record for most operational and quality purposes.

    How lot tracking is used in manufacturing

    In industrial and regulated environments, lot tracking commonly refers to:

    – **Inbound materials:** Capturing supplier lot numbers at goods receipt and mapping them to internal lot IDs.
    – **In-process manufacturing:** Recording which input lots were consumed in which work orders, batches, or process orders.
    – **Finished goods:** Assigning finished product lots and linking them to the lots of raw materials, intermediates, and packaging used.
    – **Storage and logistics:** Tracking lot IDs across warehouses, locations, and transfers, often along with quantity, status, and expiration date.
    – **Recall and investigation:** Querying which lots were used in which products, and which customers or destinations received specific lots.

    Lot tracking data is often managed and synchronized across systems such as MES, ERP, WMS, LIMS, and quality systems.

    Relationship to serialization and traceability

    Lot tracking is one form of product and material traceability:

    – **Lot-level traceability:** Identifies and traces groups of units via a lot ID.
    – **Serial-level traceability:** Identifies and traces each individual unit via a unique serial number.

    In many plants, both are used together, for example:

    – Components tracked by lot
    – High-risk or regulated components tracked by serial number
    – Finished goods tracked by lot, with optional serials on specific devices

    Lot tracking usually provides coarser traceability than full serialization, but is simpler to manage and is widely used where regulatory or business requirements do not mandate unit-level tracking.

    Boundaries and exclusions

    Lot tracking **includes**:

    – Assignment and control of lot identifiers for materials and products
    – Recording material movements, consumption, and transformations at the lot/batch level
    – Maintaining the genealogy (upstream inputs and downstream outputs) of lots

    Lot tracking **does not necessarily include**:

    – Individual unit-level tracking (that is serialization, though it may coexist with lots)
    – Process parameter tracking by equipment or sensor (though these parameters may be linked to specific lots)
    – Formal certification that traceability meets any particular regulatory standard

    Lot tracking also should not be confused with **inventory valuation methods** (e.g., FIFO/LIFO), though inventory costing rules may use lot dates and attributes.

    Common confusion and terminology

    Common related terms and points of confusion:

    – **Lot vs. batch:** In many industries these are used interchangeably. Some sites use *batch* for the process event and *lot* for the commercial or inventory grouping.
    – **Lot tracking vs. batch record:** Batch records (or electronic batch records) contain detailed process and quality data. Lot tracking refers more broadly to the identification and tracing of material groups through the flow.
    – **Lot tracking vs. traceability:** Lot tracking is one implementation approach within overall product and material traceability.

    When configuring systems, it is important to distinguish whether a field or procedure is intended to capture **lot identity**, **batch execution details**, or **individual serial numbers**.

    Site context: lot tracking in MES and mixed tracking environments

    In the context of MES and integrated manufacturing systems, lot tracking commonly refers to how the MES:

    – Models and stores lot identifiers and their attributes
    – Links consumed material lots (raws, components, intermediates) to produced lots
    – Supports mixed environments where some materials are tracked by lot and others by serial number
    – Exposes genealogy queries (“which lots went into this product?” and “where did this lot go?”) for investigations and regulatory reporting

    Designing lot tracking in MES and ERP involves decisions about data granularity, integration with shop-floor data collection, and alignment with quality and regulatory requirements, especially when both serialized and non-serialized materials coexist.

  • source of record

    Core meaning

    A **source of record** is the formally designated system, application, or repository that holds the authoritative version of a specific data set or data element. It is the place an organization agrees to treat as the final, controlling reference when there are discrepancies between systems.

    In industrial and manufacturing environments, a source of record is usually defined for key operational, quality, and business data so that everyone knows which system’s values must be used and maintained as correct.

    How it is used in manufacturing and industrial systems

    Organizations commonly assign a source of record for:

    – **Master data** – e.g., product definitions, bills of material, recipes, routing (often in ERP or PLM).
    – **Manufacturing execution data** – e.g., work order execution status, equipment states, material genealogy (often in MES or specialized OT systems).
    – **Quality data** – e.g., test results, batch dispositions, nonconformance records (often in LIMS, QMS, or MES).
    – **Asset and maintenance data** – e.g., equipment master, maintenance history (often in EAM/CMMS systems).
    – **Regulatory-relevant records** – e.g., electronic batch records, electronic device history records (often in MES, EBR systems, or document control systems).

    In day-to-day workflows, a source of record:

    – Defines **where data must be corrected** if errors are found, so downstream systems can be updated via integration or refresh.
    – Guides **integration design**, because interfaces should consume data from the agreed source of record and treat other instances as copies.
    – Acts as the **reference in reconciliations**, audits, and investigations when numbers do not match across systems.

    Boundaries and what it is not

    A source of record:

    – **Is about authority, not physical origin.** The data may have been first generated elsewhere (e.g., a sensor), but a different system may be chosen as the authoritative source of record after validation or enrichment.
    – **Is not necessarily the only place the data lives.** The same data may be replicated into data warehouses, reporting tools, or other applications, which are then treated as secondary copies.
    – **Is not automatically a regulatory record.** Some sources of record are regulatory-relevant, others are purely operational or commercial; this depends on the data type and applicable regulations.

    Relation to data trust and KPI reporting (site context)

    When organizations build KPI reporting for manufacturing or quality, they typically:

    – Designate a **source of record** for each data element used in the KPI (e.g., production quantity, scrap quantity, equipment state, batch release status).
    – Ensure that KPI calculations consistently pull from that source of record, or from controlled derivatives of it (e.g., a governed analytics layer fed from the source of record).
    – Use the source of record as the **reference point for data lineage and reconciliation**, particularly when there are discrepancies between MES, ERP, historians, or reporting tools.

    Without a clearly defined source of record, different reports can compute the same KPI from different systems, leading to conflicting numbers and reduced confidence in MES and enterprise reporting.

    Common confusion and related terms

    – **Source of truth**: Often used interchangeably with source of record. In many organizations, “system of record” or “source of record” is the more specific term for the particular system that holds authoritative data for a defined domain.
    – **Data origin**: The system or device where data is first generated (e.g., a PLC or sensor). The source of record may be different if the organization designates a higher-level system (such as MES or historian) as the authoritative holder after validation, aggregation, or contextualization.
    – **Reporting or analytics layer**: Dashboards and data warehouses often consume data from the source of record but are not always designated as the source of record themselves, unless the organization explicitly defines them as such for certain derived metrics.

    Clear terminology and governance typically require explicitly naming the **system of record** for each data domain, documenting how other systems depend on it, and distinguishing it from both raw data origins and downstream reporting copies.

  • unit of measure

    Core meaning

    A **unit of measure** (often abbreviated as UoM or UOM) is a defined quantity used to express and record the magnitude of a measurement, such as length, mass, volume, time, energy, or count. It provides a common scale so values can be interpreted, compared, calculated, and exchanged consistently across systems and organizations.

    In industrial and manufacturing contexts, units of measure are applied to materials, products, resources, capacities, and production quantities (for example, kilograms of raw material, liters of solvent, hours of machine time, or number of finished pieces).

    Use in manufacturing and industrial systems

    In regulated and large-scale manufacturing environments, units of measure commonly appear in:

    – **Master data**: Defined for materials, intermediate products, finished goods, and packaging (e.g., base unit “EA” for each, purchasing unit “BOX”, production unit “KG”).
    – **Bills of materials (BOMs)**: Quantities of components are expressed with specific units (e.g., 0.5 KG resin per EA of product).
    – **Routings and recipes**: Process times and resource usage often use time and capacity units (e.g., 30 MIN mixing, 5 H machine setup).
    – **Inventory and warehouse records**: Stock levels, minimum/maximum quantities, and batch sizes are tracked in consistent units.
    – **ERP, MES, and LIMS transactions**: Goods movements, production confirmations, quality results, and batch records rely on agreed units to avoid ambiguity.
    – **Regulatory and quality documentation**: Specifications, control limits, and test results must clearly state units to support traceability and interpretation.

    Master data and integration considerations

    In integrated OT/IT landscapes, especially ERP–MES integration, units of measure are treated as a shared, governed master data domain. Typical aspects include:

    – **Base unit of measure**: The canonical unit for a given material or resource used for storage and reporting (e.g., KG, L, EA).
    – **Alternative or conversion units**: Additional units linked by defined conversion factors (e.g., 1 PAL = 48 EA; 1 BAG = 25 KG).
    – **Consistent coding**: Use of standardized codes (e.g., “KG” vs “kg”) to avoid mismatches between systems.
    – **Rounding and precision rules**: How quantities are rounded or truncated when converted between units.

    Misaligned or undefined units of measure across systems can lead to incorrect quantities, inconsistent inventory, and difficulties in traceability and validation.

    Site context: MES and ERP alignment

    Within the context of aligning MES and ERP before integration, “unit of measure” refers to the standardized definitions and codes used to quantify materials, products, and activities across both systems. Alignment activities typically address:

    – Harmonizing base and alternative units for shared materials.
    – Ensuring identical UOM codes and conversion factors in ERP and MES.
    – Resolving duplicate or conflicting UOM definitions (e.g., two different “BOX” sizes).
    – Defining governance so new units and conversions are centrally controlled.

    Boundaries and exclusions

    A unit of measure:

    – **Includes**: Physical units (e.g., m, kg, L), time units (e.g., s, min, h), count units (e.g., EA, PCS), and other quantitative units used for industrial data (e.g., kWh).
    – **May include**: Derived units (e.g., kg/m³, m/s) where systems record calculated or specification data.
    – **Excludes**: The numeric value itself (e.g., “10” is not a unit; “10 KG” combines a value with a unit), and informal descriptors without defined quantity (e.g., “some”, “batch” when not quantitatively specified).

    Common confusion and misuse

    – **Unit of measure vs. measurement**: The unit is the scale (e.g., KG), while the measurement is the numeric value plus unit (e.g., 10 KG).
    – **Unit of measure vs. packaging unit**: Packaging units (e.g., box, pallet) can be modeled as units of measure, but they must have defined relationships to base units (e.g., 1 BOX = 12 EA). Using packaging descriptions without defined conversions leads to ambiguity.
    – **Unit of measure vs. specification range**: Specification ranges (e.g., 5.0–5.5 pH) depend on units, but the range itself is not a unit; pH is a scale, and the numbers express allowed values on that scale.

    Clear differentiation helps prevent data quality issues and misinterpretation across production, quality, and supply chain systems.

  • equipment historian

    Core meaning

    An **equipment historian** is a time-series data system that continuously collects, stores, and serves equipment-related data from industrial assets such as production machines, utilities, and process lines.

    It typically records:
    – Process values (e.g., temperatures, pressures, speeds, flows)
    – Equipment states and modes (e.g., running, idle, faulted, setup)
    – Setpoints and recipe parameters downloaded to equipment
    – Alarms, events, and operator interventions
    – Selected calculated or aggregated values (e.g., averages, maxima, counts)

    Data is usually stored with high time resolution, compressed for volume, and indexed by timestamp, tag name, and sometimes asset hierarchy.

    How it is used in manufacturing environments

    In regulated and industrial operations, an equipment historian commonly:
    – Acts as the primary repository for high-frequency equipment and process data
    – Feeds MES, quality systems, and reporting tools with historical values
    – Supports root cause and deviation investigations by reconstructing equipment behavior
    – Provides evidence of equipment conditions during specific lots, batches, or work orders
    – Enables long-term trending, process capability analysis, and maintenance analytics

    Access is typically through:
    – Tag- or asset-based queries (e.g., all values of a temperature tag over a time range)
    – Time-window queries aligned to production events (e.g., batch start/stop times)
    – Visualization tools such as trending clients, dashboards, and OSIsoft PI–style tools

    Boundaries and what it is not

    An equipment historian:
    – **Is** a specialized database for time-series and event data from equipment
    – **Is not** a full Manufacturing Execution System (MES) or ERP system
    – **Is not** a document repository for procedures, certificates, or specifications
    – **Does not usually** manage workflows, work instructions, or electronic batch records

    Key distinctions:
    – **Equipment historian vs. MES**: MES coordinates production operations and records contextual production data (orders, materials, operators, electronic records). The historian focuses on continuous equipment and process values.
    – **Equipment historian vs. SCADA/HMI**: SCADA/HMI provides real-time control and visualization; the historian stores historical data that SCADA/HMI often uses for trends and analysis.
    – **Equipment historian vs. general-purpose database**: A historian is optimized for high-volume, time-stamped data with compression and fast time-series queries, rather than general relational workloads.

    Typical data model and integration

    An equipment historian commonly organizes data as:
    – **Tags (points)**: Named signals mapped to sensors, PLC registers, or equipment parameters
    – **Time-stamped samples**: Value plus quality/status flags at specific timestamps
    – **Events**: Discrete state changes, alarms, or mode transitions
    – **Asset hierarchy**: Optional structure that groups tags by machine, line, or area

    It is usually integrated with:
    – PLCs, DCS, and embedded controllers via industrial protocols
    – SCADA or DCS systems as a data source and consumer
    – MES, quality, and analytics platforms, often through APIs or connectors

    Site context: relation to MES and special process evidence

    On this site, an equipment historian is often referenced in the context of:
    – Providing high-frequency parameter traces (e.g., temperatures, pressures, spindle speeds) that complement MES records
    – Acting as one of multiple systems that together support evidence for special process qualification or certification
    – Storing parameters that may not be fully modeled or retained in MES (for example, sub-second values or auxiliary machine conditions)

    MES may log key parameters and production context, while the equipment historian retains the full time-series record. During audits or investigations, evidence may be drawn from both systems.

    Common confusion and misuse

    The term **equipment historian** is sometimes used interchangeably with:
    – **Process historian** or **plant historian**: These often cover a broader scope, including utilities and environmental data, not just production equipment.

    In many plants, the same historian platform serves both roles; the distinction is mainly in scope and configuration. When precision is important, “equipment historian” should refer specifically to the subset of historian data tied to production or test equipment.