Connect981 – Content Dev

RSC Sphere: Data Integration, Security and Trust

The Data Integration, Security and Trust Sphere establishes the governance layer that makes everything else credible. It focuses on system interoperability, data mapping, version control, audit trails, and security alignment for regulated environments. The content makes clear how execution data can move safely across ERP, MES, QMS, PLM, and supplier systems without compromising control. This sphere proves that interoperability and security can coexist in aerospace ecosystems.

  • data lake

    A data lake is a centralized storage environment that holds large volumes of data from many sources in their raw or minimally processed form. It is typically implemented on scalable file or object storage and is used as a foundation for analytics, reporting, data science, and AI.

    Key characteristics

    In industrial and manufacturing contexts, a data lake commonly:

    • Ingests data from OT systems (PLCs, historians, SCADA), MES, ERP, QMS, LIMS, and other applications
    • Stores structured, semi-structured, and unstructured data together (for example, sensor time series, batch records, PDFs, and logs)
    • Preserves data in its original format rather than enforcing a single schema on write
    • Supports multiple downstream uses, such as dashboards, advanced analytics, machine learning, and ad hoc investigations
    • Is often part of an Industry 4.0 or enterprise analytics architecture, alongside data warehouses and operational databases

    How a data lake is used operationally

    Within manufacturing operations, a data lake commonly serves as:

    • Central collection point for high-volume sources like machine telemetry, quality measurements, and event logs
    • Historical repository that retains long time horizons of data to support trend analysis, process optimization, and investigation of deviations
    • Integration layer where data from MES, ERP, maintenance, and laboratory systems can be combined for cross-functional analytics
    • Source for curated data sets that are refined and then exposed to BI tools, data warehouses, or model training pipelines

    In regulated environments, the data lake may need to support traceability, data lineage, controlled access, and retention rules, but it does not by itself constitute a validated system of record.

    What a data lake is not

    • It is not the same as a transactional database used by MES, ERP, or SCADA for day-to-day operations.
    • It is not automatically governed, curated, or quality-checked; separate data management processes are required.
    • It is not necessarily a data warehouse, although a warehouse may be built on top of or sourced from a data lake.

    Common confusion

    • Data lake vs data warehouse: A data warehouse typically stores cleaned, modeled, and structured data optimized for reporting and standardized analytics. A data lake stores raw or lightly processed data and can support many different schemas and use cases.
    • Data lake vs data lakehouse: A data lakehouse is a newer architectural pattern that combines data lake-style storage with data warehouse-like management and query features. A data lake on its own does not guarantee those warehouse characteristics.

    Relation to Industry 4.0 architectures

    In Industry 4.0 architectures, the data lake often sits above plant-floor control systems and MES, collecting data from multiple sites and systems. It provides a shared data foundation for enterprise analytics, predictive maintenance models, digital twins, and cross-plant performance analyses, while operational control and compliance records remain in their source systems.

  • data lineage

    Core meaning

    Data lineage is the documented life cycle of data, showing where it originated, how it moved between systems, and how it was transformed or aggregated at each step. It provides an end‑to‑end view of data flows from source to final use.

    In industrial and manufacturing environments, data lineage commonly refers to the traceable path of data used for production control, quality records, and KPI reporting across OT and IT systems.

    Key elements of data lineage

    Data lineage typically captures:

    – **Data sources**: originating systems or devices (e.g., PLCs, sensors, MES, LIMS, ERP).
    – **Data movements**: interfaces and integrations (batch jobs, message queues, APIs, ETL/ELT tools).
    – **Transformations and calculations**: rules applied to data (filtering, unit conversion, KPI formulas, aggregations).
    – **Storage locations**: databases, data lakes, historians, and reporting data models.
    – **Downstream uses**: dashboards, reports, regulatory submissions, and audit trails.

    The lineage may be represented as diagrams, metadata records, or automatically generated maps in data catalog or observability tools.

    Use in industrial and regulated environments

    In manufacturing operations, data lineage is commonly used to:

    – Show how **shop-floor data** (machine states, production counts, process parameters) flows into MES, historians, and analytics tools.
    – Demonstrate how **quality and batch data** are compiled from multiple sources for electronic batch records or deviation investigations.
    – Trace the origin of **KPI values** (e.g., OEE, yield, scrap rate), including which tags, transactions, and calculations produced them.
    – Support **auditability and investigations**, allowing teams to reconstruct which data and versions of logic were in effect at a given time.

    Lineage information is often maintained as part of a broader metadata, data governance, or validation framework, especially where regulations require evidence that reported data is accurate, complete, and traceable.

    Boundaries and what data lineage is not

    Data lineage:

    – **Is**: a description of the path and transformations of data.
    – **Is not**: the business meaning of the data (this is usually handled by data definitions or a data catalog).
    – **Is not**: product or material traceability, although both can be related.
    – **Is not**: a guarantee of data quality; it supports quality assessment by making sources and transformations visible.

    Lineage records may reference related concepts such as data ownership, data quality rules, or system validation, but these are distinct governance elements.

    Common confusion and related terms

    – **Data lineage vs. data provenance**: In many IT and analytics contexts, these terms are used interchangeably. Some groups use *provenance* more narrowly for proof of origin and custody at the individual record level, while *lineage* emphasizes the overall flow across systems and processes.
    – **Data lineage vs. traceability**: In manufacturing, *traceability* usually refers to tracking materials, lots, or products through the physical process. *Data lineage* tracks information objects and transformations, not physical items, though both may be linked in investigations.
    – **Data lineage vs. data logging or history**: Historians and logs store time‑series or transactional records. Lineage describes **how** those records got there and how they are later used or transformed.

    Being explicit about these distinctions helps avoid assuming that material traceability or the existence of a history automatically provides full data lineage for reporting or compliance.

    Site context: MES data and KPI trust

    When discussing trust in MES data for KPI reporting, data lineage commonly refers to:

    – Documented mapping from **source tags, events, and records** to MES objects and KPI data models.
    – Clear visibility of **all calculations and filters** applied between raw events and final KPIs.
    – Traceable **system hops** (e.g., PLC → SCADA → MES → data warehouse → BI tool).
    – Version awareness of **integration logic and KPI formulas** at the time a report was generated.

    In this context, data lineage supports the ability to demonstrate how each reported value was produced and to reconcile reported KPIs back to underlying operational and physical records.

  • physical model

    A physical model in manufacturing and industrial operations is a structured representation of real-world equipment, assets, and material flows. It is used to describe how physical resources are arranged and interact so that control systems, MES, batch systems, and planning tools can work with them in a consistent way.

    Core meaning in manufacturing and OT/IT

    In this context, a physical model typically includes:

    • Equipment and units, such as reactors, mixers, packaging lines, conveyors, tanks, and storage locations.
    • Equipment hierarchy, such as site, area, process cell, unit, equipment module, and control module, as commonly referenced in standards.
    • Physical connections, such as piping, transfer lines, and material handling systems that define how materials can move.
    • Capabilities and constraints, such as maximum batch size, cleanability, or permitted product families on a line.

    The physical model does not describe how to make a specific product step by step. Instead, it describes what physical equipment exists, how it is organized, and what it is capable of doing. Control recipes, MES routing, and scheduling rules are then mapped onto this model.

    Relation to S88 and other standards

    In S88-style batch manufacturing, the physical model usually refers to the equipment model, which structures the physical plant into levels such as process cells, units, equipment modules, and control modules. This model is distinct from the procedural model and recipe structures, but they interact closely:

    • The physical model defines where operations can run.
    • The procedural model defines how operations are executed.
    • Recipes reference the physical model when assigning specific units or equipment for a batch.

    Similar physical modeling concepts appear in other frameworks and tools, such as ISA-95 equipment hierarchies, plant models in DCS systems, and resource models in MES/ERP.

    Operational use

    Physical models are used by:

    • Control systems (DCS/PLC) to organize I/O, control modules, and interlocks according to physical equipment.
    • MES and batch systems to allocate units, enforce equipment constraints, and manage campaigns.
    • Scheduling and planning tools to understand which orders can run on which lines or units.
    • Quality and compliance workflows to associate process data, alarms, and events with specific physical assets for traceability.

    A well-defined physical model helps ensure that data from OT systems, MES, historians, and quality systems can be consistently tied back to specific equipment and locations.

    What it is not

    • It is not the same as a procedural model or recipe logic, which describes the sequence of operations.
    • It is not necessarily a 3D CAD model, although CAD systems also use the term “physical model” for geometric representations.
    • It is not a simulation model by default, although a simulation can be built on top of a physical model.

    Common confusion

    Physical model vs procedural model: In S88 and similar frameworks, the physical model addresses equipment and structure, while the procedural model addresses tasks, operations, and sequences. Both are needed for a complete manufacturing model.

    Physical model vs data model: A physical model describes assets and flows in the physical plant. A data model describes how related information is stored and related in databases or integration layers. The two should align but are conceptually different.

    Connection to the source context

    In the context of the S88 standard, the physical model typically refers to the S88 equipment model. It is used alongside procedural models and recipes to organize batch manufacturing so that equipment, control, and MES/ERP integration can be managed in a consistent and maintainable way.

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

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

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

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

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