Connect981 – Content Dev

Glossary Tag: leading indicators

  • Systems integration

    Systems integration commonly refers to the practice of connecting separate software, hardware, and automation systems so they can exchange data and operate as a coordinated whole. In industrial and regulated manufacturing environments, it focuses on enabling reliable, traceable information flows across enterprise IT systems and operational technology (OT) on the shop floor.

    What systems integration includes

    In a manufacturing context, systems integration typically covers:

    • Linking enterprise systems such as ERP, PLM, and quality management systems (QMS) with manufacturing execution systems (MES) and plant-floor control systems
    • Connecting OT assets, such as PLCs, DCS, SCADA, historians, and data acquisition systems, to higher-level operations and analytics platforms
    • Defining and implementing interfaces, data models, and message formats so that systems can exchange information in a consistent and controlled way
    • Implementing middleware, integration platforms, or APIs to manage data routing, transformations, and orchestration between systems
    • Managing identity, access, and audit trails related to data exchanges, especially in regulated environments

    Systems integration addresses both the technical connectivity (networks, protocols, APIs) and the semantic alignment of data (consistent definitions for materials, equipment, batches, and process parameters).

    Operational meaning in manufacturing

    Operationally, systems integration shows up as automated workflows that span multiple systems. Examples include:

    • Transferring production orders from ERP to MES and returning actuals such as quantities, scrap, and consumption
    • Feeding process data from equipment or historians into MES or QMS for real-time monitoring, deviation management, or electronic batch records
    • Synchronizing master data such as materials, recipes, routings, and equipment hierarchies across ERP, MES, and plant control layers
    • Exchanging information between manufacturing systems and business intelligence or operations intelligence platforms for reporting and analysis

    Standards such as IEC 62264 and ISA-95 provide reference models and terminology to support systems integration between enterprise systems and manufacturing operations systems, but they do not by themselves guarantee interoperability. Each integration still requires design, mapping, and validation.

    What systems integration is not

    • It is not a single product or software application. It is a practice and result of combining multiple systems via defined interfaces and data models.
    • It is not limited to data migration. Ongoing, bidirectional data exchange and coordination of processes are usually in scope.
    • It is not the same as process reengineering, although integration projects often trigger process and data governance changes.

    Common confusion

    • Systems integration vs. interoperability: Systems integration is the project or activity of connecting specific systems in a specific environment. Interoperability is the capability of systems to work together, often leveraging standards. A plant can use standards and still require custom integration work.
    • Systems integration vs. interface development: An interface is a specific technical connection between two systems. Systems integration is broader and covers how multiple interfaces and systems work together to support end-to-end processes.

    Link to IEC 62264 context

    In the context of IEC 62264, systems integration refers to implementing the standard’s models and terminology to connect enterprise systems (such as ERP) with manufacturing operations systems (such as MES and control systems). The standard provides a common reference for structuring and naming information, which can simplify integration design and communication between IT and OT teams, but the actual integration still depends on plant-specific implementation and validation.

  • IIoT

    IIoT stands for Industrial Internet of Things. It commonly refers to the network of connected industrial assets, sensors, control systems, and software platforms that collect, transmit, and use data in manufacturing and other industrial environments.

    Core meaning

    In industrial operations, IIoT typically includes:

    • Physical devices and assets, such as machines, production lines, utilities equipment, and environmental sensors
    • Embedded or add-on sensors and edge devices that capture data like temperature, vibration, pressure, status, and production counts
    • Industrial networks and protocols used to move data between equipment, local gateways, OT systems, and higher-level IT systems
    • Software platforms that store, process, and analyze data, often integrating with MES, ERP, quality, and maintenance systems

    IIoT focuses on industrial and operational contexts. It is typically associated with OT (operational technology) environments such as factories, process plants, and warehouses, rather than consumer devices.

    How IIoT shows up in manufacturing workflows

    Within regulated and complex manufacturing, IIoT commonly appears as:

    • Connected machines streaming production and status data into MES or data historians
    • Condition monitoring and predictive maintenance solutions reading sensor data from assets
    • Energy, utilities, or environmental monitoring systems that feed compliance and performance reports
    • Edge gateways that securely connect PLCs and controllers to cloud or on-premise analytics platforms
    • Integration points that bridge OT data with quality systems, traceability tools, and ERP planning data

    IIoT is often mentioned alongside frameworks such as Industry 4.0 and reference architectures that describe how connected assets, data layers, and business processes align.

    What IIoT is not

    IIoT is not a single product or a specific standard. It is a general concept and ecosystem that can include multiple vendors, protocols, and architectures. It also does not, by itself, imply any particular level of cybersecurity, compliance, or data governance. Those aspects depend on how IIoT solutions are designed and operated.

    Common confusion

    • IIoT vs IoT: IoT (Internet of Things) is a broader term covering all connected devices, including consumer and smart home devices. IIoT refers specifically to industrial and operational environments, with stronger emphasis on reliability, integration with control systems, and alignment with industrial standards.
    • IIoT vs Industry 4.0: IIoT is one of the enabling technologies used within Industry 4.0 initiatives. Industry 4.0 is a wider concept covering digitalization of manufacturing, including IIoT, advanced analytics, digital twins, and integration across business processes.
    • IIoT vs MES/SCADA: MES and SCADA are established system categories with defined roles in production control and monitoring. IIoT platforms often complement these systems by providing additional connectivity, data aggregation, and analytics, but do not always replace them.

    Relation to reference architectures

    In architectural models used for Industry 4.0, IIoT elements typically appear at the asset and integration layers, linking physical equipment and sensors to information systems, analytics, and business processes across the production lifecycle and organizational hierarchy.

  • edge gateway

    Core meaning

    An **edge gateway** is a device or software appliance deployed at the boundary between operational technology (OT) networks and higher-level IT or cloud systems. It aggregates, normalizes, and routes data from local equipment or sensors, and exposes that data to upstream applications over standardized interfaces.

    In industrial environments, edge gateways commonly:

    – Connect to machines and instruments using OT protocols (for example, OPC UA/DA, Modbus, vendor-specific drivers)
    – Perform basic data processing, filtering, and normalization close to the source
    – Provide secure, controlled connectivity from plant-floor networks to MES, historians, analytics platforms, or cloud services
    – Enforce protocol translation between legacy equipment interfaces and modern APIs or message buses

    Use in manufacturing and regulated operations

    Within manufacturing systems, an edge gateway typically sits between shop-floor equipment and systems such as MES, data historians, or operations intelligence platforms. It is often used when:

    – Equipment is older or proprietary and does not natively support modern integration methods
    – Sites want to limit direct connections from critical OT assets to corporate networks or the internet
    – Data needs light transformation (tag mapping, unit conversion, timestamp alignment) before being consumed by higher-level systems

    In regulated environments, edge gateways are also used to help structure and segregate data flows so that production data can be captured in a consistent way for quality and compliance workflows, while keeping the actual control systems as stable as possible.

    What an edge gateway is and is not

    An edge gateway **is**:

    – A boundary device or software service that mediates traffic between OT and IT networks
    – A consolidation point for data from multiple equipment assets or controllers
    – A location for limited, well-defined edge processing (such as buffering, compression, basic analytics, or protocol translation)

    An edge gateway **is not**:

    – A full MES, DCS, or SCADA system (it does not replace production execution or control logic)
    – A general-purpose firewall, even though it may incorporate firewall-like controls
    – A complete IIoT platform; it usually acts as a connectivity component within a broader architecture

    Common confusion and terminology

    “Edge gateway” is sometimes used interchangeably with related terms such as **edge device**, **edge node**, or **IIoT gateway**. In manufacturing contexts:

    – **Edge gateway** usually implies a role as a **network and protocol intermediary** between equipment and higher-level systems
    – **Edge device/node** can be any compute device deployed at the edge (for example, an industrial PC performing analytics) and might not act as a gateway at all

    Vendors may package edge gateway functions into industrial PCs, embedded devices, or virtual appliances; the form factor varies, but the key characteristic remains the mediation between OT and IT domains.

    Site context: MES and special process equipment

    When integrating MES with special process equipment, an edge gateway is often used to:

    – Collect data from equipment with proprietary or legacy interfaces and expose it via standardized APIs or message queues to MES
    – Isolate validated control systems from frequent changes in MES or enterprise IT environments by placing protocol translation and interface logic on the gateway
    – Provide a single integration point per line or cell instead of connecting each piece of equipment directly to MES

    In such scenarios, the edge gateway acts as an integration layer that supports data integrity and interface manageability without requiring replacement or extensive modification of existing equipment.

  • How does Connect 981 improve work order control without replacing our existing ERP or MES?

    Connect 981 improves work order control by acting as an execution and orchestration layer between your existing ERP and MES and the shop floor. It does not replace planning or core transaction systems. Instead, it uses data from those systems to provide clearer, more granular control of work orders where the work is actually performed.

    How it improves work order control

    Connect 981 commonly enhances work order control in the following ways:

    • Digitized dispatch and routing: Translates ERP or MES work orders into clear, step-by-step tasks at each workstation, cell, or line without changing how orders are created in the source system.
    • Real-time status and progress: Captures start, stop, completion, and hold events directly from operators or connected equipment so supervisors see actual progress instead of waiting for batch updates or manual reporting.
    • Standard work and instructions at the point of use: Links operations in the work order to controlled work instructions, checklists, and data collection forms so each step is executed consistently and documented.
    • Integrated data capture and traceability: Records who did what, when, on which equipment, with which materials, and under which revision of instructions, then associates this information back to the originating work order.
    • Constraint and exception handling: Provides a structured way to pause, re-route, or adjust work when materials, tools, or approvals are missing, reducing ad hoc workarounds that ERP or MES do not fully capture.
    • Feedback loop to planning systems: Shares actual cycle times, yields, and issues so planning and scheduling in ERP or MES can be refined using current performance data.

    How it works with, not instead of, ERP and MES

    Connect 981 is typically implemented as a complementary layer:

    • ERP remains the system of record for customer orders, master data, MRP, costing, and financial postings.
    • MES (if present) remains the core execution backbone for routing logic, electronic batch records, or enforcement rules where it is already deployed.
    • Connect 981 focuses on usability and coverage in areas where ERP or MES are too rigid, too complex to configure for high-mix environments, or not fully deployed on the shop floor.

    This approach avoids a rip-and-replace project. Instead, Connect 981 leverages existing investments and fills practical execution gaps such as operator guidance, local work order re-prioritization, and consistent data capture across diverse lines or sites.

    Example in a regulated manufacturing environment

    In a regulated plant, ERP may issue work orders and an MES may manage certain validated processes. Connect 981 can:

    • Pull work order and routing details from ERP or MES.
    • Present operators with controlled digital instructions and required checks at each step.
    • Capture electronic signatures, inspection results, and material usage directly against the work order.
    • Return summary execution data and exceptions so ERP and MES records remain complete without redesigning those systems.

    The result is tighter work order control, improved visibility, and better evidence for audits, all achieved by integrating with existing systems rather than replacing them.

  • 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.

  • feature engineering

    Core meaning

    Feature engineering is the process of creating, selecting, and transforming input variables (features) from raw data so that machine learning (ML) models can use them effectively. It translates domain knowledge and raw signals into structured, numerical or categorical representations that algorithms can work with.

    It typically includes activities such as:

    – Selecting which raw data fields or signals to use
    – Cleaning and standardizing values (units, ranges, formats)
    – Aggregating measurements over time or batches
    – Deriving new variables from existing ones (e.g., ratios, deltas, rolling statistics)
    – Encoding categorical values into numerical form
    – Normalizing or scaling features to appropriate ranges

    Feature engineering is usually performed before model training and is often captured in a repeatable pipeline so that the same transformations can be applied consistently to new data.

    Use in industrial and regulated environments

    In manufacturing and other industrial domains, feature engineering commonly operates on:

    – Process data from PLCs, historians, and OT systems (temperatures, pressures, speeds)
    – MES data (work orders, material genealogy, routing steps, operator IDs)
    – Quality data (in-process and final test measurements, SPC statistics)
    – Maintenance data (run-time counters, alarms, failure codes)

    Examples include:

    – Converting second-by-second sensor traces into summary statistics per batch or lot
    – Calculating time since last maintenance or time-in-state per machine
    – Deriving features such as yield, scrap rate, or rework count per order
    – Encoding production route, shift, or product family as model-ready features

    In regulated environments, feature engineering steps are often:

    – Documented as part of the data pipeline design
    – Version-controlled alongside model code
    – Subject to change control and impact assessment when modified

    Role in explainable and trustworthy AI with MES

    When AI models are integrated with MES, feature engineering strongly influences how explainable and trustworthy the models are:

    – **Traceability and data lineage:** Each engineered feature should be traceable back to its raw data source (e.g., specific MES fields, historian tags) and transformation logic.
    – **Interpretability:** Using domain-meaningful features (e.g., “average oven temperature in curing step” rather than opaque encodings) supports human review of model behavior.
    – **Use-case boundaries:** Engineered features often encode assumptions about process conditions, time windows, or product families, which define where the model is appropriate to use.
    – **Validation:** The correctness and stability of feature calculations are validated along with the model, since errors in feature engineering can lead to misleading outputs.

    In this context, feature engineering is treated as part of the overall AI design, not just a technical preprocessing step.

    Boundaries and exclusions

    Feature engineering:

    – **Includes:** Data cleaning, transformation, and representation steps specifically aimed at preparing inputs for ML models.
    – **Excludes:** The training of the ML model itself (model selection, fitting, hyperparameter tuning), even though these depend on the engineered features.
    – **Excludes:** Basic ETL or integration work that does not change the informational content of the data beyond formatting, unless it directly defines input variables for a model.

    It is related to, but distinct from:

    – **Data engineering:** Focused on data storage, transport, and availability at scale.
    – **Feature selection:** Choosing a subset of features, which may be part of feature engineering but is sometimes treated as a separate modeling step.

    Common confusion

    – **Versus raw data extraction:** Simply pulling tags from a historian or columns from a MES database is not, by itself, feature engineering. The term is reserved for the deliberate design of input variables from that data.
    – **Versus automated feature learning:** Some modern ML methods (e.g., deep learning) can learn internal representations from raw data. Even then, in industrial settings, explicit feature engineering is still commonly used to capture domain-specific knowledge, ensure traceability, and support explainability.