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.

  • unit procedure

    A unit procedure is a structured part of a batch or manufacturing procedure that is executed on a specific piece of equipment, known as a unit. In ISA‑88 terminology, a unit procedure sits below the overall procedure in the recipe hierarchy and above operations and phases.

    Core meaning

    Within the ISA‑88 batch control model, a unit procedure:

    • Represents the portion of the recipe carried out on a single unit (for example, a reactor, mixer, or filling line)
    • Is composed of one or more operations, which are further broken down into phases
    • Defines the ordered set of actions, parameters, and logic needed to complete a major step on that unit, such as “Charge and react” or “Filter and wash”

    A unit procedure is typically implemented in a batch control system, DCS, PLC, or MES batch engine, and is referenced by both control recipes and equipment recipes. It is not just a narrative description or a standard operating procedure, although it is usually aligned with those documents.

    Where it is used in manufacturing systems

    In regulated and batch-oriented manufacturing environments, unit procedures commonly appear in:

    • Recipe management systems, where unit procedures are defined as reusable building blocks for different products
    • MES and batch execution systems, where they coordinate equipment phases, collect process data, and manage interlocks on a specific unit
    • Automation systems, where control logic for each unit procedure is implemented in phases and linked to recipe parameters

    Operationally, a batch procedure may call several unit procedures in sequence or in parallel, each tied to a different unit, to complete the full batch.

    What a unit procedure is not

    • It is not the entire batch procedure or master recipe.
    • It is not a generic SOP document, even if it aligns with SOP content.
    • It is not a single phase, step, or equipment command. Those are lower-level elements within operations and phases.

    Common confusion

    Unit procedure vs procedure: In ISA‑88, the procedure is the top-level ordered set of actions that defines how the batch is made. A unit procedure is a subset of that procedure tied to a specific unit. Multiple unit procedures can exist within one procedure.

    Unit procedure vs operation: An operation is the level below a unit procedure. A unit procedure may contain several operations, and each operation may contain several phases.

    Unit procedure vs equipment module or phase: Equipment modules and phases are elements of the equipment model and control logic. The unit procedure is a recipe element that orchestrates those lower-level elements for a particular unit.

    Relation to the ISA-88 model

    Within the ISA‑88 procedural model, the typical hierarchy is:

    • Procedure
    • Unit procedure
    • Operation
    • Phase

    Within this structure, the unit procedure is the level where process intent for a specific unit is expressed in a form that can be executed and version-controlled in MES and control systems, and traced during batch review.

  • Control Mapping

    Control mapping commonly refers to the structured practice of linking specific controls to the requirements, risks, and standards they are intended to address. It is used in regulated manufacturing and industrial environments to understand which technical, procedural, and organizational controls satisfy particular compliance obligations or risk scenarios.

    What control mapping includes

    In an OT/IT or manufacturing context, control mapping typically involves:

    • Identifying applicable requirements, such as cybersecurity frameworks, quality management standards, internal policies, or customer mandates.
    • Listing the implemented controls, such as access restrictions on MES systems, change control procedures, electronic signature rules, or network segmentation of OT assets.
    • Creating a traceable linkage that shows which control addresses which requirement, clause, or risk.
    • Highlighting gaps where a requirement has no corresponding control or only partial coverage.
    • Maintaining the mapping as systems, processes, and standards change.

    Control mappings can be documented in spreadsheets, GRC tools, QMS documentation, or integrated into MES/ERP governance records. In industrial settings, mappings often connect controls for data integrity, traceability, and access management to frameworks such as NIST 800-53, NIST 800-171, or internal quality and security policies.

    Operational use in manufacturing

    On the shop floor and in supporting systems, control mapping can show, for example:

    • Which user access controls, audit trails, and segregation of duties within MES and ERP are mapped to specific cybersecurity or data integrity requirements.
    • Which document control and change management procedures map to quality system clauses related to revision control and evidence trails.
    • How logging, backup, and incident response processes relate to defined risk scenarios affecting production, traceability, or export-controlled data.

    This mapping supports internal reviews, readiness checks, and evidence collection by providing a quick path from a standard requirement to the relevant procedures, system configurations, and records.

    Common confusion

    • Control mapping vs. process mapping: Process mapping focuses on visualizing workflows and material or information flow. Control mapping focuses on how specific controls align to requirements and risks within or across those processes.
    • Control mapping vs. risk mapping: Risk mapping identifies and prioritizes risks. Control mapping shows which controls mitigate those risks or satisfy related compliance obligations.

    Relationship to standards and frameworks

    Control mapping is often used to align internal controls with external frameworks, such as mapping plant-level cybersecurity measures to NIST 800-53 or NIST 800-171 control families, or mapping quality system procedures to clauses in standards like ISO 9001. In multi-standard environments, mappings can also cross-reference how one control supports multiple overlapping requirements.

  • SAP Digital Manufacturing

    SAP Digital Manufacturing commonly refers to SAP’s cloud-based portfolio for managing and monitoring manufacturing operations, including execution, quality, and shop-floor integration with SAP ERP or SAP S/4HANA.

    What it is

    SAP Digital Manufacturing is a suite of applications and services that support manufacturing operations in a plant or network of plants. In industrial contexts it typically includes:

    • Manufacturing execution capabilities, such as order dispatching, work instruction delivery, data collection, and confirmations
    • Shop-floor connectivity to machines, PLCs, and OT systems, often via connectors and integration services
    • Production monitoring, dashboards, and analytics for KPIs like OEE, throughput, and scrap
    • Quality-related functions such as inspection data capture and traceability of materials and lots
    • Integration with SAP ERP / SAP S/4HANA for master data, production orders, confirmations, and inventory

    In regulated or brownfield environments, SAP Digital Manufacturing commonly coexists with existing MES, historians, LIMS, and other shop-floor systems, rather than fully replacing them. It often sits between SAP ERP and plant-level systems, acting as an execution and integration layer.

    What it is not

    • It is not a single on-premise product, but a portfolio of cloud services and applications.
    • It is not the same as traditional SAP ECC or SAP S/4HANA; those remain higher-level business and planning systems.
    • It is not, by itself, a complete solution for all automation, control, or compliance needs. PLC/SCADA, DCS, and specialized quality or validation tools may still be required.

    Operational use in manufacturing environments

    In day-to-day operations, SAP Digital Manufacturing typically appears as:

    • A web-based operator interface at work centers, showing operations to perform, material to consume, and confirmations to record
    • An integration layer collecting machine data and events from OT systems for use in SAP processes
    • Central dashboards used by production, quality, and maintenance teams to monitor current production status
    • A repository for production and quality-related data that can support traceability, investigations, and reporting

    Common confusion

    • SAP Digital Manufacturing vs. MES in general: SAP Digital Manufacturing provides MES-like functionality, but in many plants it is deployed alongside existing MES or execution systems. It may serve as the primary MES in some deployments, but this varies by implementation.
    • SAP Digital Manufacturing vs. SAP ME / SAP MII: Earlier SAP manufacturing products such as SAP Manufacturing Execution (SAP ME) and SAP Manufacturing Integration and Intelligence (SAP MII) are separate, typically on-premise solutions. SAP Digital Manufacturing is the newer, cloud-focused portfolio. In practice, some plants use a combination of these, especially during transition periods.
    • SAP Digital Manufacturing vs. ERP: ERP manages planning, orders, materials, and finance at the enterprise level, while SAP Digital Manufacturing handles detailed execution, data capture, and shop-floor visibility.

    Relation to integration and standards

    In many architectures aligned with models such as ISA-95, SAP Digital Manufacturing operates between enterprise systems (ERP, SCM) and control systems (PLC/SCADA, DCS). It often uses standardized interfaces, message queues, or connectors to exchange data with both IT and OT systems, supporting consistent master data usage and coordinated production execution across sites.

  • model drift

    Core meaning

    Model drift commonly refers to the degradation of an AI or statistical model’s performance over time because the real-world data or operating conditions change compared with what the model saw during development.

    In industrial and manufacturing contexts, model drift is typically discussed for:

    – **Predictive models** (e.g., maintenance, quality prediction)
    – **Classification models** (e.g., defect types, root cause attribution)
    – **Optimization models** (e.g., setpoint recommendations, scheduling)

    The model’s logic may not change, but the **underlying data distribution, equipment behavior, materials, or operator practices** evolve, so the model becomes less accurate, less stable, or less trustworthy.

    Types of drift

    Model drift is often broken down into related concepts:

    – **Data drift (covariate shift)**: The statistical properties of input variables change over time (for example, new raw material supplier, different sensor calibration, new product mix), even if the relationship between inputs and outputs remains the same.
    – **Concept drift**: The relationship between inputs and the target output changes (for example, a new process step alters how temperature relates to defect rate).

    In day-to-day usage, “model drift” may refer to either or both, as long as the effect is a **progressive loss of validity** of model outputs.

    Use in industrial workflows

    Within OT/IT and MES-integrated environments, model drift is typically managed through:

    – **Continuous monitoring** of model performance metrics (e.g., prediction error, misclassification rates, stability of recommendations).
    – **Data distribution checks** comparing current production data with training and validation data.
    – **Alerts and governance** when drift indicators exceed predefined thresholds, often triggering human review.
    – **Model refresh or retraining cycles** under formal change control to re-align the model with current process conditions.

    In regulated environments, evidence of how drift is monitored and addressed is often documented in validation, lifecycle, and change-control records.

    Boundaries and exclusions

    – Model drift **does include**: gradual or sudden performance degradation caused by process, equipment, product, environment, or data-collection changes.
    – Model drift **does not require** a software bug or an error in the model’s implementation; a technically correct model can still drift out of alignment with reality.
    – Model drift **is not** the same as:
    – **Model bias** (systematic, often structural, unfairness or skew in predictions), although drift can expose or change bias patterns.
    – **Model versioning or change control**, which deal with intentional updates rather than unintended performance decay.

    Common confusion and related terms

    – **Model drift vs. data drift**: Data drift is specifically about changing input data distributions. Model drift is the broader operational effect where the model no longer reflects the current process or environment.
    – **Model drift vs. concept drift**: Concept drift refers to changes in the underlying process relationships. Model drift is often the observable degradation that may result from concept drift, data drift, or both.

    Using the terms precisely can help separate **root cause analysis** (what changed in the data or process) from **risk management** (how and when to intervene on the model.

    Site context: MES and trustworthy AI

    When AI models are integrated with MES, model drift is a key risk to explainability and trustworthiness. Typical practices include:

    – Keeping **clear use-case boundaries** so that the model is not applied outside its validated domain.
    – Logging **data lineage** so that changes in materials, equipment, or recipes can be linked to shifts in model behavior.
    – Implementing **human-in-the-loop controls**, where operators or engineers review model recommendations, especially when drift indicators are present.
    – Using **change control** to manage model updates that are made in response to detected drift.

    In this context, discussing model drift is part of demonstrating that AI outputs used by MES are being **continuously monitored and periodically revalidated**, rather than assumed to remain valid indefinitely.

  • process model

    A process model is a structured, often graphical or data-based representation of how a process operates. It describes the sequence of activities, inputs and outputs, decision points, roles, resources, and rules that together make up a process. In industrial and regulated manufacturing environments, process models are commonly used to design, document, automate, analyze, and control production and quality workflows.

    Key characteristics

    Typical elements included in a process model are:

    • Activities or steps: The tasks or operations performed, such as charging materials, mixing, heating, sampling, or inspection.
    • Flow or sequence: The order and branching logic (for example, parallel steps, conditional paths) that connect activities.
    • Inputs and outputs: Materials, data, or information consumed and produced by each step.
    • Roles and resources: People, equipment, systems, or units responsible for or required by each activity.
    • Business and control rules: Constraints, interlocks, calculations, recipes, and decision criteria that govern how the process behaves.
    • States and transitions: Defined process states (for example, idle, running, held) and the events that move the process between them.

    A process model may be expressed using diagrams (such as flowcharts, BPMN, or ISA-88 models), configuration objects in control systems, or data definitions inside MES, LIMS, or ERP platforms.

    Use in manufacturing and regulated environments

    In manufacturing, process models commonly appear in:

    • Batch control and ISA-88: Models of procedures, unit procedures, and operations that define how a batch is executed and coordinated with equipment and recipes.
    • MES workflow design: Electronic routings, operation steps, hold points, and data collection plans that represent the production process at the execution level.
    • Quality and compliance processes: Models of deviation handling, change control, release workflows, and electronic approvals.
    • Enterprise and supply chain processes: Representations of order management, planning, material flow, and logistics in ERP or planning systems.

    A process model is descriptive by nature. It can be used as a basis for system configuration, software automation, training materials, or validation documentation, but it is not in itself an executed process or a proof of how the process actually runs.

    Relationship to ISA-88

    Within the ISA-88 context, a process model usually refers to standardized models that describe how batch processes, equipment, and procedures are organized. Examples include models of the process hierarchy, the physical model of equipment, and the procedural model of how batches are run. These ISA-88 models provide a consistent way to define and communicate batch processes across DCS, MES, and ERP systems, but they do not enforce a specific implementation or guarantee compliance.

    Common confusion

    • Process model vs. process map: A process map is often a simpler, high-level visualization of steps and handoffs. A process model typically has more formal structure, logic, and data definition suitable for automation or analysis.
    • Process model vs. control algorithm: A process model describes the process and its workflow. A control algorithm (for example, a PID loop or advanced control strategy) describes how a control system manipulates variables within that process.
    • Process model vs. recipe: In batch environments, a recipe defines specific parameters, setpoints, and materials for a given product. The process model defines the generic structure of operations and procedures that recipes use.

  • How do we ensure AI models used with MES are explainable and trustworthy?

    Ensuring that AI models used with Manufacturing Execution Systems (MES) are explainable and trustworthy involves both technical practices and governance measures. In regulated manufacturing environments, these models must support traceability, auditability, and consistent decision making, rather than operate as opaque “black boxes.”

    Core elements of explainable, trustworthy AI with MES

    Typical elements include:

    • Clear use cases and boundaries: Define what the AI is allowed to do (for example, anomaly detection, parameter recommendations, predictive maintenance) and what decisions remain with humans. Document assumptions and known limitations.
    • Interpretable model choices where possible: Prefer simpler or inherently interpretable models (such as rule-based systems or linear models) when they meet performance needs. For complex models, add explanation tools that highlight key input factors and reasoning.
    • Data quality and lineage: Control and document the MES and OT/IT data used for training and inference. Record data sources, preprocessing steps, and versioning so that model behavior can be traced back to specific data sets.
    • Model documentation and version control: Maintain controlled documentation for each model version, including purpose, training data description, performance metrics, validation approach, and known risks. Treat models like regulated software artifacts within existing document control processes.
    • Human-in-the-loop workflows: Design MES interactions so that operators, planners, or quality personnel can review, override, or approve AI-generated recommendations, especially when they affect product quality, safety, or regulatory records.
    • Transparency in outputs: Present MES users with explanations alongside AI outputs, such as key drivers, confidence levels, or comparison to historical cases. Avoid presenting recommendations without context.
    • Bias and robustness checks: Evaluate models for systematic bias across products, lines, shifts, or sites. Test performance under expected variability in materials, equipment, and process conditions.
    • Monitoring and drift detection: Continuously monitor model performance against MES and quality data. Detect and investigate drift, such as changes in equipment behavior, product mix, or operator practice that degrade model reliability.
    • Access control and change management: Restrict who can modify models, data pipelines, and MES integrations. Apply formal change control, impact assessment, and approval workflows before promoting new or updated models to production.
    • Auditability and traceability: Log model inputs, outputs, version identifiers, and user actions for each MES transaction influenced by AI. Ensure that investigations, deviations, or customer inquiries can be supported with a clear record of how AI contributed.

    Considerations specific to regulated manufacturing

    In regulated or compliance-driven environments, explainable and trustworthy AI in MES typically also involves:

    • Alignment with existing quality systems: Integrate AI lifecycle activities into existing quality management, risk assessment, validation, and CAPA processes instead of running them as separate practices.
    • Risk-based validation: Tailor the depth of testing and documentation to the potential impact of AI-supported decisions on product quality and patient or end-user safety, while avoiding claims of formal certification.
    • Controlled use of generative AI: If generative models are used for things like work instruction drafts or root-cause brainstorming, keep them clearly separated from authoritative MES records and ensure human review before anything becomes part of controlled documentation.

    How this connects to MES practice

    Within MES projects, explainable and trustworthy AI is usually realized by combining technical design choices with governance:

    • Defining AI-enabled MES features (for example, automated alerts, parameter suggestions, or scheduling support) in functional specifications.
    • Implementing robust interfaces between MES, historians, quality systems, and AI services with clear data contracts and monitoring.
    • Embedding AI explanations, confidence indicators, and override paths directly into MES screens and workflows that operators and supervisors use every day.

    This approach helps organizations gain value from AI-enabled MES while preserving control, transparency, and trust in production and quality decisions.

  • organizational level

    An organizational level is a defined layer or scope within a company that is used to structure responsibilities, processes, data, and decision making. In manufacturing and industrial operations, organizational levels commonly describe how the production system is segmented, from individual equipment up to the entire enterprise.

    Typical organizational levels in manufacturing

    While every company can define its own hierarchy, the following levels are commonly used in regulated and industrial environments:

    • Machine or equipment level: A single asset, machine, cell, or workstation where production or testing occurs.
    • Line or process segment level: A production line, value stream, or defined process segment made up of multiple machines or workstations.
    • Area or department level: A functional or physical area such as a production hall, packaging area, or quality control lab.
    • Plant or site level: An entire manufacturing site, facility, or plant, including multiple areas and utilities.
    • Enterprise or corporate level: The overall company or business unit that spans multiple plants or regions.

    These levels can also be aligned with reference models such as ISA-95, which distinguish between control levels (e.g., Level 1 devices) and business levels (e.g., Level 4 planning), although the exact naming and number of levels can vary.

    Operational meaning in systems and KPIs

    In OT/IT, MES, and ERP contexts, organizational levels are used to:

    • Scope data collection (for example, an OEE value at machine level vs line or plant level).
    • Define ownership and access (who is responsible for data and actions at each level).
    • Configure systems (structuring MES, historian, or ERP master data to match the physical and logical hierarchy).
    • Aggregate metrics (rolling up events or KPIs from lower levels to higher levels).

    Standards such as ISO 22400 describe KPIs and data elements that can be applied at different organizational levels. They typically do not prescribe a single fixed hierarchy, so organizations define how machines, lines, areas, plants, and enterprises map to their own structures and governance rules.

    Common confusion

    • Organizational level vs. ISA-95 level: An organizational level describes a business or production scope (machine, line, plant). ISA-95 levels describe functional layers (physical process, control, MES, business planning). A “plant organizational level” might include activities across several ISA-95 levels.
    • Organizational level vs. organizational unit: An organizational unit is usually a specific department or team. An organizational level is a layer in the hierarchy that may contain multiple units.

    Use in regulated environments

    In regulated manufacturing, organizational levels are important for clearly defining where data is generated, how it is aggregated, and which level is used for release decisions, investigations, or reporting. When implementing standards such as ISO 22400 or ISA-95, organizations typically document how their own levels (machine, line, area, plant, enterprise) are defined and how KPIs and transactions are assigned or rolled up across those levels.

  • Multi-Factor Authentication (MFA)

    Multi-Factor Authentication (MFA) is an access control method that requires a user to provide two or more independent credentials to verify their identity before gaining access to a system, application, or data. It is widely used to protect IT and OT environments, including MES, ERP, quality systems, remote access to plant networks, and administrative portals.

    Core concept

    MFA combines credentials from at least two different categories:

    • Something you know: passwords, PINs, answers to security questions
    • Something you have: hardware tokens, smart cards, mobile authenticator apps, SMS codes, FIDO security keys
    • Something you are: biometric identifiers such as fingerprints, facial recognition, or iris scans

    If two credentials come from the same category (for example, two passwords), it is not considered MFA.

    Use in industrial and regulated environments

    In industrial operations, MFA commonly applies to:

    • Remote access to OT networks, SCADA, DCS, and plant-floor equipment
    • Access to regulated systems such as MES, QMS, PLM, and ERP handling export-controlled or sensitive technical data
    • Administrative and privileged accounts for system configuration, user management, and security settings
    • Cloud-hosted applications used for production planning, quality documentation, digital travelers, and audit records

    MFA is frequently referenced in cybersecurity frameworks and requirements for regulated manufacturing, such as controls related to remote access, privileged accounts, and protection of sensitive information. It is a technical control that can support alignment with security and defense-related standards, but it does not by itself indicate overall compliance.

    Operational considerations

    When applied to manufacturing and industrial operations, MFA typically needs to account for:

    • Shared workstations and terminals on the shop floor, where multiple operators may log into a common station
    • Usability at the line, ensuring MFA does not prevent timely access to work instructions, travelers, or quality records
    • Integration with directory services such as Active Directory or identity providers used across MES, ERP, and other systems
    • Network segmentation, where MFA may be required for crossing from corporate IT networks into OT or secure zones

    Common confusion

    • MFA vs. Two-Factor Authentication (2FA): 2FA is a specific case of MFA that uses exactly two factors. MFA is a broader term that covers two or more factors.
    • MFA vs. strong passwords: Complex passwords alone are not MFA. At least two distinct factor categories must be used.
    • MFA vs. single sign-on (SSO): SSO provides a unified login across systems, while MFA adds additional verification steps. Many deployments combine SSO with MFA.

    Relation to cybersecurity and compliance

    MFA is commonly referenced in cybersecurity and defense-related guidelines, including those addressing controlled unclassified information, export-controlled data, or access to cloud-hosted manufacturing systems. In this context, MFA is treated as one of several technical access controls that can help reduce the risk of unauthorized access to sensitive production data, engineering documents, and quality records.