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.

  • Who should own the ISMS in an aerospace or industrial organization?

    In aerospace and industrial organizations, the Information Security Management System (ISMS) cannot be effectively owned by a single person or function acting in isolation. Formal accountability should sit at the executive level, but day-to-day ownership is usually assigned to a designated security leader and supported by a cross-functional governance structure.

    Formal accountability: senior leadership

    Ultimate accountability for the ISMS should sit with executive management, typically:

    • CEO, GM, or business unit leader for the regulated operation, with
    • Formal delegation to a CISO, CIO, or VP responsible for risk and compliance.

    This is important because ISMS decisions affect capital allocation, production risk, contractual obligations (e.g., defense and aerospace primes), and regulatory exposure. Executive ownership is also what makes cross-functional enforcement credible when security controls conflict with schedule or cost pressures.

    Operational ownership: ISMS lead or CISO

    Day-to-day ISMS ownership is typically assigned to one clear role, for example:

    • CISO (or equivalent security leader) in larger organizations.
    • Information Security Manager or ISMS Manager in mid-size plants or business units.
    • IT/OT Security Lead in smaller organizations where a formal CISO role does not exist.

    This role is usually responsible for:

    • Maintaining the ISMS scope, Statement of Applicability, and risk treatment plans.
    • Coordinating risk assessments and ensuring they cover both IT and OT assets.
    • Driving alignment with frameworks like ISO 27001 and industrial cybersecurity standards such as IEC 62443, where applicable.
    • Ensuring incident management, vulnerability management, and change control processes are defined and implemented.
    • Reporting security posture and major risks to executive management.

    In regulated industrial environments, the ISMS lead must have enough authority to slow or block high-risk changes, but also enough operational understanding to avoid impractical policies that would be ignored on the plant floor.

    Shared responsibility: IT, OT, engineering, operations, and quality

    Even with a clear ISMS owner, effective implementation in aerospace and industrial contexts requires shared responsibility, especially across IT/OT boundaries:

    • IT owns enterprise networks, identity, cloud environments, and many core business applications (ERP, PLM, email, collaboration).
    • OT / Controls engineering owns PLCs, SCADA, HMIs, DCS, and safety systems that often run on legacy platforms and cannot easily be patched or reconfigured without requalification.
    • Manufacturing engineering and operations own production processes, equipment utilization, and changeovers, and must evaluate how controls affect throughput, downtime risk, and maintenability.
    • Quality and regulatory teams own documentation, validation, deviation management, and audit readiness (including traceability and evidence that controls are followed).

    Without explicit responsibilities across these groups, ISMS controls risk becoming IT-only policies that do not adequately cover production systems, test stands, special processes, and engineering data flows.

    Governance structure: steering committee and RACI

    In brownfield aerospace and industrial environments with a mix of MES, ERP, QMS, PLM, and legacy point solutions, a structured governance model is usually necessary. Typical elements include:

    • ISMS steering committee with representation from IT, OT, operations, engineering, quality, supply chain, and legal/contract management where applicable.
    • Formal RACI (responsible, accountable, consulted, informed) for key ISMS processes such as risk assessment, change control, vendor onboarding, incident response, and audit support.
    • Plant-level security champions or site coordinators to translate global policies into workable local procedures, especially when equipment age, vendor constraints, or validation status differ by location.

    This structure helps avoid two common failure modes:

    • Security controls designed centrally that cannot be implemented on legacy production systems without unacceptable downtime or requalification cost.
    • Site-level workarounds that undermine corporate policies, leaving gaps in traceability and increasing audit and incident risk.

    Why ownership is complicated in regulated, long-lifecycle environments

    In aerospace and high-spec industrial plants, ISMS ownership is more complex than in typical IT-only organizations due to:

    • Long equipment lifecycles: CNCs, test rigs, and special process equipment may be in service for decades, often with unsupported operating systems and restricted change windows.
    • Validation and qualification burdens: Even minor system or configuration changes can trigger requalification, documentation updates, and potential customer approvals.
    • Integration debt: MES, ERP, PLM, QMS, and custom middleware are tightly coupled. A security policy that looks simple on paper can break critical data flows if not carefully analyzed.
    • Export controls and technical data handling: Design data, repair data, and test results often fall under export control or customer restrictions, creating specialized handling and evidence requirements.

    Because of these constraints, ISMS ownership must explicitly include:

    • Close coordination with change control and configuration management processes.
    • Risk-based approaches that consider both security impact and operational/qualification impact.
    • Documented justifications and compensating controls when standard measures (for example, frequent patching or aggressive network segmentation) are not feasible for certain assets.

    Practical pattern: how organizations usually assign ownership

    In practice, many aerospace and industrial organizations converge on a model like:

    1. Executive sponsor: Business unit leader or COO accountable for ISMS effectiveness.
    2. ISMS owner: CISO or Information Security Manager responsible for operating the ISMS and reporting on performance.
    3. Cross-functional governance: ISMS steering committee with IT, OT, operations, engineering, quality, and supply chain, responsible for risk acceptance decisions and prioritization of remediation work.
    4. Site and function owners: Local operations leaders, engineering managers, and system owners responsible for implementing and maintaining controls in their scope, under corporate policy.

    This model keeps accountability at the top, while making the ISMS a shared, operationally grounded responsibility instead of an IT-only initiative.

  • Can different foundational requirements have different security levels?

    Yes. Different foundational requirements can have different security levels, and in regulated industrial environments they usually should. The important point is that the security level is not arbitrary: it must be driven by risk, applied consistently, and kept under traceable change control.

    What it means in practice

    When you decompose your cybersecurity or operational requirements into foundational requirements (for example around access control, system integrity, data confidentiality, change management, or logging), you can assign different target security levels to each area. Typical drivers include:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Process safety impact (risk of injury, environmental release, or critical quality impact)
    • Regulatory exposure (GxP, export control, ITAR/EAR, aerospace/defense contracts, customer-specific security clauses)
    • Business impact (downtime cost, IP sensitivity, supply chain implications)
    • Integration surface (degree of connectivity to corporate IT, partners, cloud, or remote services)

    It is common, for example, to require a higher level of security for requirements around remote access or configuration changes on safety-related systems than for read-only viewing of non-sensitive production KPIs.

    Key constraints and dependencies

    Being able to set different security levels by foundational requirement depends on:

    • Clear requirement hierarchy: You need documented foundational requirements that are traceable up to policies/standards and down to specific controls on specific systems.
    • Defined security level criteria: Whether you use IEC 62443 concepts or an internal schema, the meaning of each level must be written, approved, and stable enough to be auditable.
    • System capability and vendor constraints: Some legacy PLCs, DCS, MES, or lab systems cannot technically meet higher levels without workarounds or compensating controls.
    • Validation and qualification burden: In regulated plants, tightening a security level on a foundational requirement may trigger revalidation, regression testing, and documentation updates.

    Common patterns in brownfield environments

    In mixed, long-lived industrial stacks, you will often see:

    • Different levels by requirement, not by asset: For example, all systems handling export-controlled technical data have higher requirements for access control and data handling, even if the underlying machines are similar to those in non-controlled areas.
    • Use of compensating controls: Where an older system cannot meet a higher security level natively, requirements may be met through network segmentation, jump hosts, procedural controls, or stricter change management.
    • Uneven implementation: Plants may declare a higher level for a requirement but apply it inconsistently across sites or vendors. This is a frequent audit and risk gap.

    Tradeoffs and failure modes

    Allowing different security levels per foundational requirement introduces both flexibility and risk:

    • Pros:
      • Lets you focus strict controls on high-risk areas without over-burdening low-risk operations.
      • Reduces friction for manufacturing teams where tighter controls are not justified by risk.
      • Improves odds of adoption in brownfield plants by aligning with technical and downtime constraints.
    • Cons:
      • Complexity: Harder to explain, audit, and maintain than a single uniform level across all requirements.
      • Drift: Over time, controls may no longer match the documented level if changes are not governed.
      • Integration issues: Interfaces between systems at different effective levels can become weak links.

    Governance expectations in regulated environments

    If you assign different security levels to foundational requirements, you should be prepared to demonstrate:

    • Documented rationale: Why a given requirement is set at that level, including risk assessment inputs.
    • Traceability: Mapping from security level to specific technical and procedural controls, and from those controls to systems, sites, and versions.
    • Change control: Evidence that any change to levels or controls went through a defined review, impact assessment, and approval workflow.
    • Verification and validation: Test or verification activities showing controls perform as intended, especially where changes could affect validated processes.

    Why this usually coexists with, not replaces, existing systems

    In most aerospace, pharma, and similar environments, you will not replace major MES, SCADA, or control systems just to standardize security levels. The qualification burden, downtime risk, integration complexity, and long equipment lifecycles make full replacement strategies brittle and expensive. Instead, plants typically:

    • Define foundational requirements and security levels at the policy/standard layer.
    • Map those requirements onto existing systems and networks.
    • Use segmentation, gateways, and compensating procedures to close gaps where replacement is not feasible.

    So yes, different foundational requirements can legitimately carry different security levels, but the benefit comes only if you anchor levels in risk, implement them consistently across your brownfield landscape, and maintain validation-grade traceability over time.

  • What are the 11 functions of ISA‑95?

    ISA‑95 does not define a single, official list of exactly 11 functions. The standard defines functional categories and models (especially at Level 3, Operations Management) and then decomposes those into many activities. Different vendors and authors sometimes group or compress these activities into a list they call the “11 ISA‑95 functions,” but that list is not canonical and varies across sources.

    What ISA‑95 actually standardizes

    ISA‑95 provides:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • A reference functional hierarchy (Levels 0–4).
    • Information models that describe what data is exchanged between business systems (e.g., ERP) and manufacturing systems (e.g., MES/SCADA).
    • Activity models for Level 3 (Operations Management) that group work into four major operations areas.

    At Level 3, ISA‑95 organizes functions into these core categories, not 11 fixed items:

    • Production Operations Management
    • Maintenance Operations Management
    • Quality Operations Management
    • Inventory Operations Management

    Each of these is then broken down into activities such as definition, dispatching, execution, data collection, tracking, and analysis. Depending on how you count or group these activities, you might end up with 8, 10, 11, or more “functions.” That counting is interpretive, not standard.

    Examples of how people arrive at “11 functions”

    To illustrate where the “11” comes from, some practitioners:

    • List the four operations areas above, then split each into 2–3 subfunctions (for example, Production Scheduling, Production Dispatching, Production Tracking), and stop when they reach 11.
    • Start from the ISA‑95 activity diagrams and pick a subset that lines up with a particular MES product’s modules, then label those as the 11 ISA‑95 functions.

    These lists can be useful for internal communication or vendor comparisons, but they are derived interpretations, not a normative part of the standard.

    How to use ISA‑95 functions in a real plant

    In a regulated, brownfield environment, it is usually more practical to work from the ISA‑95 activity models than to chase a specific “11 functions” list:

    • Map current systems (ERP, MES, historians, QMS, CMMS, LIMS, bespoke tools) to the ISA‑95 Level 3 activities. Many plants already have some production, maintenance, quality, and inventory functions split across multiple systems.
    • Identify gaps and overlaps. For example, you may discover that “Production Tracking” is duplicated between MES and a custom database, or that “Quality Analysis” is largely manual.
    • Plan incremental changes. Full replacement of existing MES or ERP modules is often high risk due to validation requirements, integration complexity, and downtime constraints. Using ISA‑95 as a reference, you can target specific functions or interfaces for upgrade or consolidation while maintaining traceability.

    Because of long equipment lifecycles and regulatory expectations for validated systems, treating ISA‑95 as a reference model for interfaces and responsibilities is usually more sustainable than attempting to reorganize all systems into a predefined “11 functions” structure.

    Key takeaway

    If a vendor or consultant references “the 11 ISA‑95 functions,” ask them to:

    • Show exactly how they derive their list from the ISA‑95 models and activities.
    • Map each of their named functions back to the standard’s Production, Maintenance, Quality, and Inventory Operations Management activity models.
    • Explain how their interpretation fits, or conflicts, with how your existing ERP, MES, QMS, CMMS, and other systems are already partitioning responsibilities.

    This approach keeps the discussion grounded in the actual standard while acknowledging that a fixed set of “11 functions” is a simplification, not a requirement of ISA‑95.

  • How can digital tools reduce configuration errors in complex programs?

    Digital tools can materially reduce configuration errors in complex programs, but only when they are tightly governed, integrated with existing systems, and aligned with a disciplined configuration management process. Tools alone do not fix weak processes or incomplete data.

    Where configuration errors typically originate

    Before choosing tools, it helps to be clear where errors usually come from in complex, regulated programs:

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    • Multiple, conflicting sources of truth for BOMs, routings, and options.
    • Manual interpretation of engineering change orders and customer specs.
    • Spreadsheet- or email-based variant/option management.
    • Poor linkage between PLM, ERP, MES, QMS, and supplier data.
    • Uncontrolled local “overrides” on the shop floor to make work happen.

    Digital tools are effective when they reduce these handoffs, interpretations, and uncontrolled edits, and when they preserve traceability from requirement to as-built configuration.

    Key digital capabilities that reduce configuration errors

    In brownfield, mixed-vendor environments, you are usually layering targeted capabilities onto existing PLM/ERP/MES, not replacing them. The most impactful capabilities are:

    1. Model-based and rules-driven configuration

    • Central configuration rules: Use a configuration model (often in PLM or a dedicated configurator) where allowable options, incompatibilities, and dependencies are defined once and reused across ERP, MES, and work instructions.
    • Automated variant/BOM generation: Generate configuration-specific BOMs and routings from rules, instead of hand-editing base structures for each order.
    • Constraint checking: Block or flag non-permissible option combinations at order-entry or planning, instead of discovering them at assembly or test.

    Dependencies: This only works if you have disciplined ownership of rules, change approval, and a validated integration path so that downstream systems always use current rules.

    2. PLM, ERP, and MES interoperability with strong version control

    • Single source of truth for product definition: Use PLM (or equivalent) as the master for BOM, drawings, 3D models, and effectivity, then propagate controlled snapshots to ERP/MES.
    • Effectivity and baseline control: Manage configuration by serial/lot, date, and revision, so each unit can be tied back to the exact spec and change package that applied when it was built.
    • Digital as-built traceability: Use MES or digital travelers to record what parts, operations, and deviations were applied to each unit, closing the loop to the as-planned configuration.

    Tradeoffs: Tight integration reduces configuration drift but increases dependence on stable interfaces and strict change control. In long-lifecycle programs, every integration change carries validation and requalification overhead.

    3. Digital work instructions linked to configuration

    • Configuration-specific instructions: Present work instructions that are automatically filtered by part number, revision, option set, and deviation list for that work order or serial.
    • Embedded visual/3D content: Reduce mis-interpretation of complex assemblies by linking directly to the correct drawing or 3D view for that configuration, rather than generic paper packets.
    • Step-level checks: Enforce mandatory verifications, signoffs, and data capture when configuration-critical steps are performed.

    Dependencies: This requires a maintained mapping between product structure and work instruction content. If revision management for instructions is weak, digital delivery can actually multiply configuration confusion.

    4. Digital travelers and routing control

    • Route enforcement: Ensure each configuration follows the correct routing, operations, and inspection points. Disallow ad-hoc skipping or reordering unless formally authorized through deviation workflows.
    • Automatic attachment of relevant data: Attach required specs, test limits, and configuration-specific settings directly to the operation rather than expecting operators to interpret generalized documentation.
    • In-line validation: For configurable products, validate key attributes (e.g., software load, calibration range, torque values) against the intended configuration during execution.

    Tradeoffs: Strong route enforcement can be perceived as rigid and may slow recovery from unplanned issues if deviation workflows are not streamlined.

    5. Integrated change management with impact analysis

    • Linked changes: Tie engineering changes to affected BOMs, routings, software loads, work instructions, FAI/AS9102 packages, and test procedures.
    • Configuration-aware impact analysis: Use tools that can report which programs, configurations, lots, and suppliers are impacted by a proposed change.
    • Guardrails at release: Block release of changes unless associated downstream artifacts (e.g., digital travelers, WI, test limits) are updated and approved.

    Dependencies: Effective impact analysis depends on disciplined linking of data objects across systems. If legacy data has poor linkage, you will need cleanup and master-data governance before tools can be trusted.

    6. Automated validation and checks at the point of use

    • Parameter and software validation: Automatically validate programmed parameters, CNC programs, or embedded software versions against the authorized configuration before operation runs.
    • Part and tooling checks: Use scanning (barcodes/2D/RFID) to confirm the correct part revision, kit, fixture, and calibrated tool are used for the current configuration.
    • Interlocks for critical characteristics: For configuration-critical steps, require successful digital checks before allowing progress or completion.

    Tradeoffs: Interlocks and additional scans reduce error risk but can increase cycle time if not designed into the workflow carefully. Operator adoption can suffer if they feel surveilled or slowed without visible benefit.

    7. Data integrity, audit trails, and evidence

    • Immutable audit trails: Ensure that changes to configuration data (BOMs, routings, options, test limits) and overrides are logged with who/what/when/why.
    • Configuration deviation management: Route off-nominal configuration changes (e.g., part substitutions, out-of-spec but usable conditions) through controlled MRB/deviation workflows.
    • Evidence packaging: Support audits and customer reviews by being able to show exactly which configuration definition, instruction revision, and deviation set applied to a given serial number.

    Dependencies: Audit trails require validated systems and clear SOPs for user account management, e-signatures, and record retention that align with your regulatory obligations.

    Coexistence with existing systems (brownfield reality)

    In complex aerospace or defense programs, attempt to avoid “rip-and-replace” of PLM/ERP/MES for configuration control alone. Full replacement strategies often fail or stall because of:

    • Requalification and validation burden for safety-critical and regulated processes.
    • High downtime and cutover risk across many active programs and configurations.
    • Interdependencies with legacy test rigs, custom interfaces, and supplier portals.
    • Long asset and program lifecycles where multiple IT generations must coexist.

    More realistic approaches include:

    • Using PLM as the product master and enhancing integration and effectivity handling into ERP/MES.
    • Layering a digital work instruction / traveler solution that reads from existing masters and enforces configuration at the point of execution.
    • Incrementally adding rule-based configuration for new programs, then back-propagating to legacy programs where ROI justifies the migration and validation cost.

    Practical preconditions for success

    Digital tools only reduce configuration errors if a few foundations are in place:

    • Clear configuration ownership: Defined roles for who owns product definition, routing, options, and rules.
    • Governed master data: BOMs, routings, and option codes are complete, consistently coded, and subject to change control.
    • Validated integrations: Interfaces between PLM, ERP, MES, and QMS are tested, versioned, and monitored.
    • Operator-centric design: Screens and workflows are designed so the “right configuration” path is easier than workarounds.
    • Training and WI alignment: Users understand how configuration is controlled and what is expected when something does not match.

    When these elements are addressed, digital tools can significantly lower the risk and frequency of configuration errors in complex programs by constraining variation, reducing manual interpretation, and improving traceability from requirements through to as-built units.

  • What does OPC mean in manufacturing?

    In manufacturing, “OPC” most commonly refers to a family of industrial communication standards defined by the OPC Foundation. These standards provide a vendor-neutral way to move data between shop-floor devices (PLCs, DCS, CNCs, sensors) and higher-level systems (SCADA, MES, historians, analytics, LIMS, ERP).

    Key meanings of OPC in this context

    • OPC Classic (OLE for Process Control): The original Windows-centric specifications that use COM/DCOM. Often found in legacy SCADA and data historian integrations.
    • OPC UA (OPC Unified Architecture): The modern, platform-independent standard that supports richer data modeling, built-in security features, and operation over various transports (TCP, HTTPS, etc.). It is the current strategic direction for most new deployments.

    When people in plants say “we have OPC” or “we use OPC,” they typically mean:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • They are using OPC servers to expose data from PLCs, DCS, or other devices.
    • They are using OPC clients in SCADA, MES, data historians, or analytics platforms to subscribe to and read that data.
    • In newer projects, they may specifically mean OPC UA for standardized, secure connectivity across equipment and systems.

    How OPC fits into a regulated manufacturing environment

    In regulated or safety-critical manufacturing, OPC is typically one part of a broader architecture:

    • Interoperability layer: OPC provides a common interface to many different vendor devices and control systems, which is valuable in brownfield environments with mixed generations of equipment.
    • Data acquisition: OPC is often used to collect process parameters, alarms, and events for historians, batch records, deviation analysis, and OEE calculations.
    • Integration with MES/QMS: OPC can feed real-time data to MES, LIMS, or QMS workflows (for example, automatic capture of critical process parameters), but it must be integrated carefully and validated where those systems are used for regulated records.

    By itself, OPC does not provide:

    • Compliance guarantees: OPC is a communication standard, not a quality or regulatory system. It does not ensure data integrity, audit trails, or electronic signature compliance without additional application-layer controls.
    • Automatic traceability: Traceability and genealogy depend on how data is modeled, stored, and linked in MES, historians, or other systems that consume OPC data.
    • Validation: Each specific implementation (server, client, integration, configurations) must be assessed and validated according to your own quality system and regulatory expectations.

    OPC in brownfield plants

    Most regulated plants are brownfield environments where OPC is used to connect legacy and modern systems instead of replacing everything:

    • Mixed generations: You may see OPC Classic used to connect older SCADA and historians, while new projects adopt OPC UA. Gateways often bridge between fieldbuses or proprietary protocols and OPC.
    • Incremental rollout: Plants rarely replace existing control systems solely to standardize on OPC UA due to downtime risk, validation burden, and qualification costs. Instead, they add OPC connectivity at boundaries and migrate over time.
    • Integration debt: Poorly documented OPC tag structures, ad-hoc naming, and point-to-point integrations can create long-term maintenance and validation overhead.

    Tradeoffs and risks when using OPC

    Organizations typically weigh several tradeoffs when deciding how to use OPC:

    • Standardization vs. legacy compatibility
      OPC UA offers better long-term interoperability and security, but many installed systems only support OPC Classic or proprietary protocols. Gateways can help, but add complexity and single points of failure.
    • Security vs. ease of access
      OPC UA supports encryption, authentication, and authorization, but only improves security if it is configured correctly and integrated with plant cybersecurity controls. Exposing OPC endpoints across network zones without proper design introduces real risk.
    • Rich models vs. simple tags
      OPC UA can model complex assets and relationships, but many plants still expose “flat” tag lists that are easy to configure but hard to govern and validate over time.
    • Centralized vs. local servers
      Central OPC servers are easier to administer and validate, but failures have broader impact. Local servers limit blast radius but increase the number of nodes to maintain and control.

    What OPC does and does not solve

    OPC can be very useful, but it is important to be clear about its role:

    • OPC is good for:
      • Standardizing how devices and systems exchange real-time process and alarm data.
      • Reducing vendor lock-in at the communication layer.
      • Providing a common mechanism to feed historians, analytics, and MES from multiple control systems.
    • OPC is not a substitute for:
      • A validated MES, historian, or QMS that manages records, workflows, and traceability.
      • A cybersecurity program, including network segmentation, hardening, and monitoring.
      • Change control over tag definitions, mappings, and interface behavior.

    In practice, how much value OPC delivers depends on how well it is integrated into your existing stack, how consistently data is modeled and governed, and how carefully the endpoints and configurations are validated and controlled over the lifecycle of the equipment.

  • What is the primary purpose of ISA-95?

    The primary purpose of ISA-95 is to provide a standardized model and common language for integrating business systems (such as ERP and planning) with manufacturing operations and control systems (such as MES, SCADA, DCS, and equipment controllers). It focuses on what information needs to be exchanged between levels of the manufacturing stack, and how to structure that information consistently, so that interfaces can be designed, implemented, and maintained more reliably over long equipment lifecycles.

    What ISA-95 is trying to solve

    In most plants, especially brownfield environments, business and shop-floor systems come from different vendors, generations, and integration styles. Each tends to use its own naming, data models, and message formats. ISA-95 addresses this by:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • Defining clear functional boundaries between enterprise planning, manufacturing operations, and control systems.
    • Standardizing core information objects (such as material, equipment, personnel, production schedule, production performance, and quality information).
    • Providing consistent models for manufacturing operations management (production, maintenance, quality, inventory) to reduce ambiguity in integration specifications.

    The intent is not to replace your ERP, MES, or control systems, but to make their interactions more predictable, traceable, and easier to maintain under change control.

    What ISA-95 is not

    • It is not a turnkey integration or a software product. It is a set of models and standards that must be interpreted and implemented.
    • It does not guarantee compliance, audit success, or data integrity by itself. Those outcomes depend on system configuration, validation, and procedures.
    • It does not define every detail of message formats for all vendors. Many implementations still require mapping and compromises.

    Why it matters in regulated, long-lifecycle environments

    In regulated manufacturing, integration changes are expensive to validate and risky to deploy. ISA-95 helps by:

    • Providing a stable reference model that can be reused across lines, plants, and vendors, reducing one-off integration designs.
    • Improving traceability of what data is exchanged and why, which supports change impact assessment and documentation.
    • Reducing the tendency to do full system replacement just to fix integration problems, which often fails due to qualification burden, downtime risk, and integration complexity.

    However, actual benefits depend heavily on how consistently the standard is applied across projects and suppliers, and on the maturity of your integration governance.

    Coexistence with existing systems

    Most plants use ISA-95 selectively rather than as a complete, pure implementation. Common patterns include:

    • Using ISA-95 models to design new ERP-to-MES or MES-to-L2 interfaces while leaving legacy point-to-point integrations in place.
    • Adopting ISA-95 terminology and object structures in integration specifications, even when underlying systems keep their native data models.
    • Incrementally refactoring existing interfaces toward ISA-95-aligned objects (for example, standardizing how production orders and equipment states are represented) instead of a big-bang rearchitecture.

    This incremental approach is usually more realistic in regulated environments, where any interface change can trigger revalidation, documentation updates, and retraining.

    Key takeaway

    The primary purpose of ISA-95 is to provide a common, structured framework for integrating enterprise and manufacturing systems. It reduces ambiguity and integration risk by standardizing how manufacturing information is modeled and exchanged, but it does not remove the need for careful design, mapping, validation, and long-term change control in real plants.

  • Should we calculate manufacturing KPIs in ERP, MES, or a data warehouse?

    No. In most plants, you should not calculate all manufacturing KPIs in only ERP, only MES, or only a data warehouse.

    The practical answer is to calculate KPIs in the system that has the right source data, event timing, and operational context for that metric, then publish governed results for broader reporting. In brownfield environments, that usually means a split model:

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    • MES for execution-level KPIs that depend on detailed production events, machine states, labor transactions, route steps, quality checkpoints, or genealogy context.
    • ERP for financial, order, inventory valuation, procurement, and enterprise planning metrics.
    • Data warehouse for cross-system KPIs, trend analysis, plant-to-plant comparisons, and executive reporting where data must be reconciled across MES, ERP, QMS, CMMS, and other sources.

    What belongs where

    MES is usually the better calculation point for metrics such as throughput by operation, cycle time by routing step, queue time, WIP aging at execution points, first pass yield at the work center, detailed scrap and rework by operation, and some forms of OEE or downtime analysis. Those KPIs break down quickly if you try to reconstruct them later from ERP transactions that were never designed to capture shop floor event timing with enough precision.

    ERP is usually the better calculation point for measures such as order fulfillment, shipment performance, purchase price variance, inventory turns, standard versus actual cost, and other metrics tied to financial posting logic or enterprise master data. ERP can also be the system of record for planned quantities, due dates, and customer or supplier commitments, even when the manufacturing events come from somewhere else.

    A data warehouse is usually the better calculation point when the KPI requires multiple systems, historical normalization, common calendar logic, enterprise dimensions, or a canonical definition across sites. Examples include end-to-end lead time, schedule adherence that depends on both plan and execution, COPQ rollups, supplier-to-production latency, and corporate dashboards that combine production, quality, and financial context.

    Why a single-system answer often fails

    Each system has different strengths and failure modes. ERP often lacks the event granularity needed for execution KPIs. MES often does not own the enterprise financial logic or all planning assumptions. A data warehouse can standardize and compare, but it is only as good as the incoming data, timestamp quality, identity matching, and business rules.

    If you force every KPI into one layer, you usually create one or more of these problems:

    • Metrics that are technically consistent but operationally misleading.
    • Different teams recalculating the same KPI with different start and stop events.
    • Lagging dashboards that are not useful for shift-level action.
    • Executive reports that cannot be traced back to transactional evidence.
    • Validation and change control overhead whenever logic changes.

    Use system of record and system of calculation separately

    A useful pattern is to define, for each KPI, both the system of record and the system of calculation. They are not always the same.

    • A KPI may use MES as the record for execution events, but the warehouse as the place where the final enterprise KPI is calculated.
    • A KPI may use ERP as the record for planned completion date, but MES for actual completion event.
    • A KPI may be displayed in ERP, MES, or BI tools without being calculated there.

    This separation matters in regulated environments because teams often need traceability from a dashboard number back to the underlying transactions, versions, and business rules used at that time.

    What to decide before choosing the calculation layer

    Before deciding where to calculate a KPI, clarify:

    • What exact business event starts and stops the metric.
    • Which system captures those events first and with acceptable timestamp precision.
    • Whether the KPI must drive real-time action, period close reporting, or both.
    • Whether the metric must be standardized across plants with different routings, vendors, or transaction practices.
    • Whether the source data is complete enough to support the metric without manual patching.
    • How changes to KPI logic will be versioned, approved, tested, and communicated.

    Without that governance, the technology choice will not fix KPI inconsistency.

    Brownfield reality

    In mixed MES and ERP environments, coexistence is usually the right approach. Full replacement to get “one source of truth” often looks attractive on paper but fails in practice when plants have validated processes, custom integrations, legacy equipment, long asset lifecycles, and limited downtime windows. Replacing core systems just to simplify KPI calculation can create more risk than value because of qualification burden, integration rework, retraining, and disruption to traceability and change control.

    A more durable approach is to keep calculations close to the source where necessary, then federate or reconcile results in a governed data layer.

    Recommended operating model

    For most manufacturers, the lowest-risk model is:

    1. Define KPI formulas, event boundaries, exclusions, and ownership centrally.
    2. Calculate execution KPIs in MES when real-time context and transactional fidelity matter.
    3. Calculate finance and planning KPIs in ERP where posting and master data rules are authoritative.
    4. Use a data warehouse or semantic layer for enterprise KPIs that cross systems or require historical normalization.
    5. Maintain lineage so users can trace every KPI back to source records and logic versions.

    If you cannot explain why a KPI is calculated in a given layer, and what data it depends on, the architecture is probably not stable enough yet.

  • Is there an industry standard that allows interoperability?

    There is no single, universal industry standard that automatically “allows interoperability” across all systems in industrial and regulated manufacturing environments. Interoperability typically results from a combination of standards, vendor-specific implementations, and plant-level integration work.

    What “interoperability” usually means in this context

    In brownfield manufacturing, interoperability usually means that equipment, control systems, MES, ERP, QMS, and related tools can reliably exchange data and execute workflows without manual rework or loss of traceability. Standards help, but they do not remove the need for engineering, configuration, and validation.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    Key standards that support interoperability

    Depending on your stack and sector, several standards are commonly used to improve interoperability:

    • OPC UA / OPC Classic: Widely used for machine-to-system and system-to-system connectivity at the control and supervisory layers. Support and quality vary by vendor and version.
    • ISA-95: A reference model and terminology for integrating enterprise (Level 4) and control systems (Levels 0–3). Often used as the basis for MES–ERP integration. It is a model, not a plug-and-play interface.
    • B2MML: An XML implementation of ISA-95 used to standardize data exchange between MES, ERP, and related systems. Interoperability still depends on consistent interpretation and mapping.
    • ISA-88: Batch control models and terminology that help structure recipes, phases, and equipment modules across batch systems.
    • ISA-99 / IEC 62443: Cybersecurity and network segmentation standards that influence how interoperable systems are architected and secured, especially in regulated environments.
    • Automation and fieldbus/protocol standards (e.g., Modbus, PROFINET, EtherNet/IP, MQTT): These provide transport and basic data structures, but do not ensure semantic consistency.
    • Data exchange formats and APIs (e.g., JSON/REST, XML, standardized EDI for supply chain): These make integration feasible but do not guarantee consistent meaning without alignment on data definitions.

    Why no single standard “solves” interoperability

    In real plants, several factors limit what standards alone can do:

    • Vendor interpretation: Even when vendors claim support for the same standard (for example, OPC UA or ISA-95), they often implement different subsets, profiles, or extensions.
    • Legacy systems: Older PLCs, DCSs, MES, and custom applications may predate current standards or support them only via gateways and wrappers.
    • Semantic differences: Standards may define structure (tags, objects, messages) but not semantics (how you define a lot, batch, nonconformance, or genealogy), which must be harmonized at the plant or enterprise level.
    • Regulatory constraints: Data structures and workflows are tightly coupled to validated processes. Changing interfaces or adopting new standards can trigger revalidation and documentation effort.
    • Partial adoption: A plant might use ISA-95 as a reference model, OPC UA at the machine layer, and custom APIs to glue things together. Interoperability depends on how consistently these are applied.

    Dependencies in regulated, long-lifecycle environments

    In regulated and aerospace-grade settings, achieving interoperability through standards depends heavily on:

    • Data and model governance: Defined master data, shared definitions, and controlled change processes for tags, equipment models, materials, and quality states.
    • Validation and change control: Any new interface or standard-based integration normally requires risk assessment, testing, and documented validation to maintain compliance.
    • Integration quality: Interface specifications, mapping documents, error handling, time synchronization, and logging are as important as the chosen standard.
    • Lifecycle strategy: Standards must fit into long equipment lifecycles and existing qualification; ripping and replacing systems purely to “follow a standard” often fails due to downtime and requalification cost.

    Coexistence with existing systems (brownfield reality)

    Most regulated plants end up with a hybrid approach:

    • Use standards like OPC UA, ISA-95, and B2MML where they fit and where vendor support is mature.
    • Bridge noncompliant or legacy systems through gateways, protocol converters, or integration middleware.
    • Define plant-specific interface specifications that constrain how standards are used, to reduce ambiguity.
    • Introduce changes incrementally to avoid large, risky cutovers that would require extensive revalidation and downtime.

    Bottom line

    No single industry standard guarantees interoperability. Standards such as OPC UA, ISA-95, ISA-88, and B2MML can significantly reduce integration effort and risk, but real interoperability in regulated environments still depends on vendor implementations, configuration discipline, data governance, and validated integration design.

  • Can we normalize data without replacing legacy manufacturing systems?

    Yes. In most brownfield manufacturing environments, data can be normalized without replacing legacy MES, ERP, PLM, QMS, historians, or machine interfaces.

    The usual approach is to leave systems of record in place and add a governed integration layer, canonical data model, or semantic mapping approach that standardizes how part numbers, operations, resources, defects, statuses, timestamps, units, and identifiers are interpreted across systems.

    In practice, this connects to data mapping and system interoperability when teams need to turn the answer into repeatable execution habits.

    That said, normalization is not a shortcut around poor source data, conflicting business rules, or weak governance. If plants use different meanings for the same field, different revision practices, or inconsistent event timing, normalization can expose those issues but cannot resolve them automatically.

    What this can do

    • Create a consistent view across mixed vendors and legacy applications.

    • Support reporting, analytics, traceability, and cross-plant comparisons with less manual reconciliation.

    • Reduce duplicate mapping logic across every point-to-point integration.

    • Preserve existing validated or qualified systems while improving interoperability around them.

    What it cannot do by itself

    • It does not fix missing or unreliable source data.

    • It does not eliminate the need for master data ownership and change control.

    • It does not guarantee real-time consistency if source systems update at different intervals or with different transaction rules.

    • It does not remove the need to validate interfaces, mappings, and downstream calculations where required.

    Why replacement is often the wrong first move

    Full replacement is often not the lowest-risk path in regulated, long-lifecycle operations. Legacy systems may be deeply tied to equipment, work instructions, quality workflows, custom integrations, and evidence records. Replacing them can trigger significant qualification burden, validation cost, downtime risk, retraining effort, and traceability concerns.

    For that reason, many programs start with coexistence: normalize data around existing systems first, then retire or consolidate selected applications only where the business case and risk profile are clear.

    Key dependencies

    Whether this works well depends on a few practical conditions:

    • Data readiness: source fields must be identifiable, stable enough to map, and not dominated by free text or local shortcuts.

    • Business definitions: the organization needs agreement on what core objects and events mean across plants and functions.

    • Master data discipline: parts, revisions, routings, resources, suppliers, and defect codes need ownership.

    • Integration quality: interface reliability, latency, error handling, and reconciliation matter more than slideware architecture.

    • Change control: mappings must be versioned and maintained as upstream systems change.

    • Validation effort: in regulated environments, transformed data used for quality, release, traceability, or audit evidence needs careful verification and documented controls.

    Common failure modes

    • Trying to standardize reports before standardizing identifiers and event definitions.

    • Allowing each integration project to invent its own mappings.

    • Normalizing only field names while ignoring process semantics.

    • Assuming one plant’s process model fits all sites without exception handling.

    • Building a central model with no governance process for updates, exceptions, or source-system changes.

    So the answer is yes, but with limits. Data normalization without system replacement is usually feasible and often the more realistic path. It works best as a controlled coexistence strategy, not as a promise that legacy complexity disappears.