Connect981 – Content Dev

Glossary Tag: process monitoring

  • Reconciliation

    Core meaning

    In industrial and manufacturing contexts, **reconciliation** is the systematic process of comparing two or more sets of related records and aligning them so that:

    – all differences are identified,
    – discrepancies are understood and documented, and
    – the resulting, agreed data set is internally consistent.

    The data sets being reconciled usually represent the same events or quantities from different sources (for example, system-of-record vs. local records, planned vs. actual, or IT vs. OT data).

    Typical uses in manufacturing and regulated operations

    Reconciliation commonly appears in several areas:

    – **Inventory reconciliation**: Matching physical stock counts to inventory records in an ERP, WMS, or MES. Differences are investigated and adjustments are recorded.
    – **Material and batch reconciliation**: Comparing material consumption and yield data from shop-floor systems or equipment with MES/ERP batch records and production orders.
    – **Production data reconciliation**: Aligning OT data (PLC/SCADA counters, historian tags) with MES or ERP production quantities, timestamps, and statuses.
    – **Quality and deviation reconciliation**: Matching inspection results, deviations, and nonconformances across LIMS, QMS, and MES so that each unit, lot, or batch has a consistent history.
    – **Financial and cost reconciliation**: Aligning production, scrap, and rework quantities with cost-accounting records, often bridging MES/ERP and finance systems.

    In regulated environments, reconciliation is often a documented activity, with evidence of what was compared, what was found, and how mismatches were resolved.

    What reconciliation typically includes and excludes

    **Includes:**

    – Comparing two or more data sources that should represent the same reality
    – Identifying mismatches in quantities, statuses, timestamps, or identifiers
    – Investigating and explaining causes (e.g., late data, manual error, system integration gaps)
    – Updating records or creating adjustments so that a final, consistent view is established
    – Logging the outcome for traceability and audit purposes

    **Excludes:**

    – General problem solving or root cause analysis that does not involve comparing data sets
    – Data cleansing done without reference to an authoritative counterpart data set
    – System integration itself (reconciliation uses data produced by integrations but is not the integration mechanism)

    Data and systems context

    Reconciliation is often performed at boundaries between:

    – **OT and IT systems** (e.g., historian vs. MES or ERP)
    – **Execution and planning systems** (e.g., MES vs. APS/MRP/ERP)
    – **Source and consuming systems** in data pipelines (e.g., shop-floor data vs. data warehouse or operations-intelligence tools)

    It may be executed:

    – manually (spreadsheet-based comparisons, reports),
    – semi-automatically (scheduled jobs generating discrepancy lists), or
    – automatically (rules-based matching and exception handling in MES/ERP or data platforms).

    Common confusion and related terms

    Reconciliation is often confused with:

    – **Data validation**: Validation checks whether data meets defined rules or formats; reconciliation compares data from different sources to each other.
    – **Data harmonization or standardization**: Harmonization aligns formats, units, or codes; reconciliation aligns records and quantities across systems after they are harmonized.
    – **Balancing or mass balance**: Mass balance focuses on conservation of mass or energy in a process; reconciliation may use mass balance as one method but is broader and data-centric.

    Understanding these distinctions helps specify whether a workflow needs validation rules, reconciliation procedures, or both.

  • Information model

    An information model is a structured representation of information, including the types of data that exist in a domain, the relationships between those data elements, and the rules or constraints that govern them. In industrial and manufacturing environments, information models are used to describe how equipment, processes, materials, batches, quality records, and business objects are represented and exchanged across OT and IT systems.

    Key characteristics

    In this context, an information model typically:

    • Defines entities and attributes, such as assets, tags, lots, recipes, orders, or alarms, and their properties.
    • Specifies relationships, for example how a batch relates to raw material lots, equipment units, and test results.
    • Provides structure for interoperability, enabling different systems (PLC/SCADA, MES, LIMS, ERP, historians) to interpret exchanged data consistently.
    • Includes rules and constraints, such as allowed value ranges, units of measure, or mandatory fields for regulatory records.

    An information model can be formalized in many ways, including OPC UA address spaces, ISA-95 object hierarchies, database schemas, XML or JSON schemas, or model-based integration frameworks. The core idea is to create a common, machine-readable understanding of what the data represents, not just how it is formatted.

    Role in industrial and regulated environments

    In manufacturing systems, information models commonly:

    • Bridge OT and IT by mapping control-level tags and signals to higher-level concepts like equipment units, production runs, or KPIs.
    • Support compliance and traceability by explicitly modeling genealogy, batch relationships, and links between process data and quality records.
    • Enable standardized interfaces for MES/ERP or MES/LIMS integration by sharing a consistent definition of orders, materials, test results, and status codes.
    • Improve data governance by clarifying ownership, meaning, and permissible uses of data elements across systems.

    Information models and OPC UA

    OPC UA uses the concept of an information model to describe data exposed by devices, controllers, gateways, and applications. In OPC UA:

    • The information model defines nodes (objects, variables, methods) and references that organize data into a browseable address space.
    • Standard companion specifications add domain-specific models, such as models for machine tools, robots, or packaging lines.
    • Vendors can extend the base model with custom types, which makes it important to review and validate each implementation when integrating into a plant.

    What it is not

    An information model is not the same as:

    • Physical data storage, such as a specific database implementation or file format, even though it may influence them.
    • A communication protocol; it describes what information is represented, not the low-level mechanics of how bytes are transmitted on the network.
    • A process model; it focuses on data representation rather than on the sequencing or control logic of operations.

    Common confusion

    Several related terms are often used alongside or instead of “information model”:

    • Data model: Often used interchangeably, especially in IT. Some practitioners use “information model” for a higher-level, conceptual view and “data model” for more concrete implementation details, but the distinction is not universal.
    • Ontology: In some contexts, this refers to a more formal, semantically rich information model with explicit meaning and reasoning rules, for example using semantic web technologies.
    • Schema: Typically refers to the technical structure of data in a specific system (such as a database or message format) that is derived from or aligned with an information model.

    When specifying or reviewing integrations in manufacturing environments, it is useful to clarify whether a document or standard is describing a conceptual information model, a concrete data/schema design, or both.

  • OPC server

    An OPC server is software that makes data from industrial devices or control systems available to other applications using OPC communication standards such as OPC Classic (DA, A&E, HDA) or OPC UA. It acts as a data access layer between field equipment and higher-level systems, translating device-specific protocols into a standardized OPC information model and interface.

    In a typical manufacturing environment, an OPC server connects to PLCs, DCSs, CNCs, sensors, or other automation components and presents their tags, variables, or events to client systems. Common OPC clients include SCADA systems, MES, historians, analytics platforms, and custom OT/IT integration services.

    Key characteristics

    • Role: Acts as the data provider in the OPC client/server model, exposing data points, methods, and events.
    • Location: May run on a control system node, a dedicated gateway, or an IT/OT demilitarized zone (DMZ) server.
    • Protocol translation: Often converts proprietary or fieldbus protocols (for example Modbus, Profibus, vendor-specific PLC drivers) into OPC address spaces.
    • OPC Classic vs OPC UA: OPC Classic servers typically use COM/DCOM on Windows, while OPC UA servers use platform-independent, service-oriented protocols with built-in security features.
    • Security and governance: In regulated or critical environments, OPC servers are typically subject to access control, change management, cybersecurity controls, and validation or qualification activities.

    Operational context in manufacturing

    • Shop floor connectivity: Provides a standardized interface that MES, quality systems, and data collection tools can use to read process parameters, equipment status, and alarms.
    • Data aggregation: Aggregates data from multiple devices or lines into a single endpoint for historians, reporting, or operations intelligence systems.
    • Interoperability: Helps connect heterogeneous vendor equipment without each application implementing every device protocol.
    • Segmentation: Can be deployed at network boundaries to control how OT data is exposed to IT systems, with design and configuration impacting cybersecurity posture.

    What an OPC server is not

    • It is not a complete MES, SCADA, or historian. Those systems may use OPC servers, but provide broader application logic and data storage.
    • It is not by itself a compliance or validation solution. Compliance in regulated manufacturing depends on the surrounding processes, controls, and documented use of the OPC-based architecture.
    • It is not limited to a specific industry. OPC servers are used across discrete, batch, and continuous manufacturing and in other industrial sectors.

    Common confusion

    • OPC vs OPC server: “OPC” generally refers to the family of interoperability standards, while an “OPC server” is a specific software component that implements the server side of those standards.
    • OPC server vs OPC client: The server exposes and manages the data; the client consumes it. MES, SCADA, and analytics tools are usually OPC clients, even when they embed their own server capabilities.
    • OPC server vs gateway: Some products described as gateways include an OPC server plus other protocol conversion or routing functions. An OPC server, strictly defined, focuses on providing an OPC interface.

    Relation to the OPC standards in manufacturing

    In manufacturing environments, an OPC server is the primary way OPC standards are realized in practice. It operationalizes the OPC information model and services so that equipment data, alarms, and events can be accessed in a consistent way by higher-level systems. The reliability, security configuration, and validation of the OPC server and its interfaces are often important considerations in regulated or safety-critical operations.

  • RAMI 4.0

    RAMI 4.0 (Reference Architectural Model Industrie 4.0) is a three-dimensional reference architecture used to describe, structure, and align Industry 4.0 concepts, components, and systems. It provides a common map for how industrial assets, data, functions, and business processes relate to each other across different levels of an industrial operation.

    Core concept

    RAMI 4.0 combines three dimensions into one model:

    • Layers: From the physical asset and integration level up through communication, information, functional, and business layers.
    • Lifecycle & value stream: From idea and development through production, operation, and end of life of a product or asset.
    • Hierarchy levels: From physical product and field device up through station, work center, enterprise, and connected world, consistent with traditional automation pyramids.

    In industrial and regulated environments, RAMI 4.0 is commonly used as a planning and communication tool when designing or assessing digitalization initiatives, OT/IT integration, and Industry 4.0 projects. It offers a structured way to place MES, ERP, PLCs, SCADA, IIoT platforms, and quality or compliance systems within a unified architectural view.

    Operational meaning in manufacturing

    In practice, RAMI 4.0 is used to:

    • Map existing systems (“brownfield” plants) across layers and hierarchy levels to understand overlaps and gaps.
    • Plan new capabilities such as connectivity, data models, and digital twins in a consistent reference frame.
    • Align stakeholders from operations, IT, engineering, and quality on where specific functions should reside.
    • Support interoperability discussions around standards, interfaces, and information models for Industry 4.0 components.

    RAMI 4.0 itself is not a software product, not a protocol, and not a standard that can be installed. It does not, by itself, establish regulatory compliance or quality certification. Instead, it structures how technologies and standards are considered in an Industry 4.0 setting.

    Relationship to other standards and models

    RAMI 4.0 is often used alongside other industrial frameworks and standards such as:

    • ISA-95 style hierarchy models for enterprise-to-control system integration.
    • Information models and standards for Industrie 4.0 components and administration shells.
    • OT and IT architecture patterns for MES, SCADA, historians, and ERP integration.

    While RAMI 4.0 provides a reference structure, individual organizations adapt it to their own system landscape and regulatory requirements.

    Common confusion

    • RAMI 4.0 vs. Industry 4.0: Industry 4.0 is a broad concept describing the digital transformation of manufacturing. RAMI 4.0 is a specific reference architecture used to describe and structure that transformation.
    • RAMI 4.0 vs. implementation: RAMI 4.0 is a conceptual model. It does not prescribe particular products, vendors, or detailed implementation steps.
    • RAMI 4.0 vs. compliance: Using RAMI 4.0 does not by itself demonstrate regulatory, quality, or cybersecurity compliance. It can, however, help organize systems and responsibilities in a way that supports compliance activities.

    Connection to the FAQ context

    In many discussions, RAMI 4.0 is presented as a way to structure Industry 4.0 implementations across layers, lifecycle, and hierarchy. In brownfield manufacturing environments, it is typically tailored to reflect existing assets and systems, then used as a planning and alignment tool for future changes.

  • Use Case

    Core meaning

    A **use case** is a structured description of how a user, role, or external system interacts with a system to achieve a specific goal in a defined context. It typically captures:

    – The actor (person, role, or external system) initiating the interaction
    – The goal or outcome the actor wants to achieve
    – The main sequence of interactions between actor and system
    – Alternate or exception paths when things do not follow the main flow
    – Preconditions and postconditions that define when the use case starts and ends

    Use cases are widely used in requirements analysis, system design, and solution evaluation.

    Use in industrial and manufacturing environments

    In industrial operations and regulated manufacturing, a use case commonly refers to a concrete operational or information flow scenario, such as:

    – A quality engineer recording a nonconformance in a QMS and triggering a corrective action workflow
    – An operator starting a production order in an MES and reporting material consumption and downtime
    – An automated test bench sending test results to an SPC or data historian system
    – An ERP system requesting real-time WIP status from an MES for ATP (available-to-promise) calculations

    These use cases may be documented at different levels of detail, ranging from high-level business scenarios (e.g., “Release a batch record for production”) to detailed system interactions (e.g., message exchanges between MES and PLCs).

    Structure and documentation

    Use cases in this domain are often represented using:

    – **Textual descriptions**: Narrative or table-based format listing actor, triggers, main flow, alternate flows.
    – **Diagrams**: UML use case diagrams or system context diagrams to show actors and their relationships to systems.
    – **Scenarios or stories**: Concrete examples of how a shift, batch, or order is run using specific systems.

    They may be grouped into use case catalogues for an MES, QMS, LIMS, historian, or other OT/IT platform.

    Boundaries and exclusions

    A use case:

    – **Is not** the same as a process map, although a process map may contain multiple use cases.
    – **Is not** a full functional specification; it describes interactions and goals, but not all technical details.
    – **Is not** limited to software; it can cover interactions with equipment, manual steps, and paper artifacts, as long as they relate to a defined goal.

    In regulated environments, use cases may inform but do not replace validation documentation, test cases, or formal procedures.

    Common confusion and related terms

    – **Use case vs. user story**: A user story is a brief, informal requirements statement (e.g., “As a line supervisor, I want to see OEE by shift…”). A use case is more structured and details interaction flows.
    – **Use case vs. business case**: A business case explains why an initiative is undertaken (costs, risks, expected value). A use case explains how the solution will be used to achieve specific operational goals.
    – **Use case vs. test case**: A test case is a specific, step-by-step test to verify a requirement. A use case provides the scenario from which many test cases can be derived.

    Site-context application

    On this site, use cases are generally discussed in relation to:

    – Designing and selecting MES, QMS, LIMS, historian, and other OT/IT systems
    – Describing interactions across ISA-95 style levels (ERP, MES, control, equipment)
    – Clarifying how manufacturing, quality, maintenance, and regulatory workflows are supported by integrated systems

    Use cases serve as a neutral way to describe these interactions without prescribing a specific product or implementation approach.

  • historian

    Core meaning

    In industrial and manufacturing environments, a **historian** is a specialized time‑series database and software system used to collect, store, compress, and retrieve time‑stamped operational data. It typically ingests high‑frequency data from control systems, field devices, and sensors, and makes this data available for analysis, reporting, and integration with other systems.

    A historian commonly stores:

    – Process values (flows, temperatures, pressures, levels, speeds)
    – Equipment and asset status signals (run/stop, modes, alarms)
    – Calculated or aggregated metrics (averages, totals, KPI trends)
    – Event time stamps associated with process changes or states

    Role in manufacturing and operations

    In manufacturing, a historian is used to:

    – Capture continuous and batch process data from PLCs, DCS, SCADA, and IoT gateways
    – Provide trend and replay views for engineers, operators, and maintenance
    – Supply historical signals to analytics, predictive maintenance models, and reporting tools
    – Support investigations of deviations, quality issues, and equipment problems through historical traces

    Data in the historian is usually organized by tags or points, each representing a specific signal from a device or system. The system often provides compression, buffering, and backfilling to manage large volumes of time‑series data while maintaining performance.

    Boundaries and what a historian is not

    A historian:

    – **Is** a time‑series data infrastructure component focused on time‑stamped operational values
    – **Is not** a full Manufacturing Execution System (MES) or ERP and typically does not manage orders, routes, or operators
    – **Is not** a general relational database for transactional business data
    – **May integrate with** MES, CMMS, LIMS, quality systems, and analytics platforms but does not replace their workflow or business logic

    Historians usually store data with minimal business context (for example, “Tag 101: reactor temperature”), while systems like MES or ERP add product, batch, order, and schedule context on top of that raw data.

    Common confusion and related terms

    – **Historian vs. MES**: A historian stores time‑series signals; MES manages production execution, work orders, and contextual information such as product, route, and operator.
    – **Historian vs. SCADA**: SCADA focuses on real‑time monitoring and control; a historian focuses on long‑term storage and retrieval of time‑stamped data. Many SCADA systems embed or connect to a historian.
    – **Historian vs. CMMS**: CMMS manages maintenance work, assets, and records; a historian provides operational data that maintenance teams may use for diagnostics or analytics.

    Use in predictive maintenance (site context)

    For predictive maintenance, historians commonly serve as a primary data source. Models can be trained on and run from historical process and equipment signals (vibration, temperature, current, throughput, etc.) without requiring MES data. However, when historian data is combined with MES or other context sources, organizations can link predicted failures or anomalies to specific products, lots, routes, and schedules, which supports more precise root cause analysis and traceability in regulated environments.