Connect981 – Content Dev

RSC Cluster: Data Mapping and System Interoperability

The Data Mapping and System Interoperability Cluster ties execution, planning, quality, and supplier systems together without rip-and-replace projects. It explains how governed data mapping enables interoperability across ERP, MES, QMS, PLM, and external partners. The content positions execution as the truth layer that systems align around. This cluster is the connective tissue of the entire ecosystem.

  • manufacturing operating system

    A manufacturing operating system (MOS) is the integrated layer of processes, digital systems, and governance that coordinates day-to-day production across a plant or network of plants. It defines how work is planned, executed, monitored, and improved, and how information moves between people, machines, and enterprise systems.

    What it includes

    In industrial and regulated environments, a manufacturing operating system commonly includes:

    • Standardized processes and methods, such as standard work, recipes, routings, quality checks, deviation handling, and change control.
    • Digital systems that execute or support these processes, for example MES, SCADA, historians, LIMS, QMS, CMMS, PLM, and ERP.
    • Integration and data flows that connect planning, execution, quality, maintenance, and finance, including master data definitions and interfaces.
    • Governance and management routines, such as tiered daily management, KPIs and dashboards, escalation rules, and review cadences.
    • Roles and responsibilities for operations, engineering, quality, IT/OT, and leadership in running and improving the system.

    An MOS sits above individual tools. It describes how those tools work together as a coherent production system, rather than being a single software product.

    What it is not

    “Manufacturing operating system” commonly does not refer to:

    • A plant-floor PC operating system (such as Windows or Linux).
    • A single vendor platform or one specific application, even if marketed using similar language.
    • Only lean methods or only digital systems without the management and governance layer.

    How it shows up operationally

    In practice, the manufacturing operating system is visible in how:

    • Production plans flow from ERP or planning tools into MES or dispatching systems.
    • Operators receive work instructions, record data, and handle exceptions on the shop floor.
    • Quality checks, approvals, deviations, and CAPA activities are triggered and documented.
    • Equipment data from OT systems informs OEE, NPT, energy usage, and maintenance decisions.
    • Leadership reviews performance using a consistent set of metrics and standard meeting routines.

    In regulated, brownfield plants, an MOS is typically described as an architecture and management model that spans multiple legacy and modern systems. Its performance depends on process maturity, integration quality, validation status where required, and disciplined change control.

    Common confusion

    • MOS vs MES: MES is one component of the digital stack focused on production execution. The MOS defines how MES, other systems, and management routines work together.
    • MOS vs lean production system: A lean production system focuses on principles and methods (for example, flow, pull, and waste reduction). A manufacturing operating system typically includes those methods plus the supporting digital architecture and governance.
    • MOS vs IT/OT operating system: Operating system in IT/OT usually means low-level software that runs hardware. A manufacturing operating system is a business and operations construct, not firmware or a device OS.

    Link to standards and compliance

    An MOS often aligns conceptually with reference models like ISA-95 or GAMP categories, without being identical to any one standard. In regulated industries, the manufacturing operating system must be operated and changed under documented procedures, with appropriate validation or verification of the systems and workflows that form part of it.

  • data interoperability

    Data interoperability commonly refers to the ability of different systems, applications, or devices to exchange data and have that data be understood and reused consistently by each system without manual re-entry or re-interpretation. In industrial and regulated manufacturing environments, it focuses on structured, unambiguous data flows across OT and IT systems.

    What data interoperability includes

    In a manufacturing context, data interoperability typically involves:

    • Standardized data structures, such as common data models, schemas, or master data definitions that multiple systems share.
    • Agreed semantics, where fields, units, codes, and status values have the same meaning across systems.
    • Technical connectivity, such as APIs, message queues, or standardized industrial protocols that move the data.
    • Consistent identification, so objects like batches, lots, equipment, materials, and work orders use common identifiers across systems.
    • Traceable transformations, where any mapping or conversion between systems is controlled, documented, and repeatable.

    In regulated environments, data interoperability is often addressed when integrating MES, ERP, LIMS, QMS, historians, and equipment or control systems. The goal is that data produced by one system can be consumed by others in a way that preserves meaning, context, and traceability.

    Operational meaning in manufacturing

    Operationally, data interoperability shows up as:

    • Equipment sending parameter, status, and result data in a structured format that an MES can interpret directly.
    • MES production records flowing into ERP for inventory and costing, without re-keying or manual interpretation.
    • Quality results moving from equipment or LIMS into a QMS with clear links to batches, materials, and specifications.
    • Common reference data, such as material codes or specification IDs, shared across systems for consistent reporting and genealogy.

    Disciplined integration, interface standards, and controlled configuration and validation are typically required to achieve and maintain data interoperability in regulated operations.

    What data interoperability is not

    • It is not only about physical connectivity or network access; systems can be connected but still not interoperable if they cannot interpret each other’s data correctly.
    • It is not the same as data migration, which focuses on one-time or infrequent bulk movement of data rather than ongoing, bidirectional exchange.
    • It is not limited to a specific technology; it can be implemented via multiple integration patterns and standards.

    Common confusion

    • Data interoperability vs data integration: Data integration focuses on moving and combining data between systems. Data interoperability includes integration but also requires shared structure and meaning so that the receiving system can use the data correctly without custom, case-by-case interpretation.
    • Data interoperability vs data portability: Data portability concerns the ability to export and import data between environments, often for switching vendors. Data interoperability focuses on ongoing, operational data exchange across systems.

    Relation to regulated manufacturing environments

    In regulated manufacturing, data interoperability commonly underpins electronic records, traceability, and consistent reporting across MES, ERP, QMS, and other systems. It supports reliable links between process data, materials, equipment, and quality decisions, which are often subject to internal governance and external regulatory review.

  • syntactic interoperability

    Syntactic interoperability commonly refers to the ability of two or more systems to exchange data using a shared structure, format, and set of encoding rules so that messages can be parsed and processed correctly on each side.

    In industrial and manufacturing environments, syntactic interoperability focuses on aligning how data is packaged, not on what the data means. It is about making sure messages follow the same schemas, field layouts, and protocols so software and equipment can read and validate them reliably.

    What syntactic interoperability includes

    In practice, syntactic interoperability typically covers:

    • Use of common message formats (for example XML, JSON, CSV, EDI transaction sets)
    • Agreed schemas and field structures (data types, field order, required vs optional fields)
    • Protocol-level rules (for example MQTT topic structures, OPC UA node structures, REST API contracts)
    • Consistent character encodings and date/time formats
    • Validation rules that check whether a message conforms to the agreed syntax

    For example, a manufacturing execution system (MES) and an enterprise resource planning (ERP) system can achieve syntactic interoperability by implementing the same JSON API specification for production order messages, even if they still interpret some fields differently.

    Where syntactic interoperability fits in integration

    Syntactic interoperability is usually described as one layer of interoperability, often alongside technical, semantic, and organizational interoperability:

    • Technical: Networks, connectivity, and basic data transport work.
    • Syntactic: The message formats and structures are aligned and machine-readable.
    • Semantic: The systems share a common understanding of what the data elements mean.
    • Organizational: Processes, responsibilities, and governance support consistent use of the data.

    In regulated manufacturing, syntactic interoperability often appears in interface specifications, data mapping documents, and validation evidence showing that messages between control systems, MES, LIMS, QMS, and ERP follow an agreed structure.

    Common confusion

    Syntactic interoperability is often confused with:

    • Technical interoperability, which focuses on connectivity and transport (for example, two systems both support HTTPS), not on the structure of the messages.
    • Semantic interoperability, which addresses the meaning of data elements (for example, whether both systems interpret a field called “batch” in the same way), beyond just the structure.

    Syntactic interoperability alone does not guarantee that two systems agree on business concepts, regulatory interpretations, or how data should be used. It simply ensures that messages follow the same structural rules so they can be exchanged and parsed without errors.

  • data flow mapping

    Core meaning

    Data flow mapping is the activity of systematically documenting how data moves between systems, people, and locations across a process or organization. It describes the sources, destinations, formats, and transfer mechanisms for data, rather than the business logic applied to that data.

    In industrial and manufacturing environments, data flow mapping typically focuses on how production, quality, maintenance, and business data travel across OT and IT systems and into external parties such as suppliers or customers.

    What data flow mapping includes

    Data flow mapping commonly captures:

    – **Data sources**: where data originates (e.g., PLCs, SCADA, MES, LIMS, ERP, supplier portals, spreadsheets).
    – **Data destinations**: where data is consumed or stored (e.g., historians, MES, ERP, QMS, file shares, cloud services).
    – **Transfer paths**: how data moves (e.g., APIs, message queues, OPC, file transfers, email, USB, paper forms later keyed in).
    – **Data types and classifications**: what the data represents and its sensitivity (e.g., production recipes, NC/CAPA records, Controlled Unclassified Information, personally identifiable information).
    – **Process and workflow context**: which business or manufacturing steps the data supports (e.g., work order release, batch record review, supplier qualification).
    – **Actors**: which roles or systems send, modify, or receive the data (e.g., operators, quality engineers, maintenance planners, external labs).

    The result may be represented as diagrams, tabular inventories, or both.

    Use in manufacturing and regulated environments

    In manufacturing, data flow mapping is commonly used to:

    – Describe how shop-floor data moves from equipment and sensors into MES, historians, and ERP.
    – Show how quality data flows between QMS, LIMS, production systems, and customer or regulatory reporting channels.
    – Document how engineering data (e.g., specifications, BOMs, recipes) is distributed to production lines and suppliers.
    – Trace how supplier and customer data is exchanged through portals, EDI, APIs, or manual processes.

    In regulated or audited settings, such mappings help organizations:

    – Identify where controlled or sensitive data is stored or transmitted.
    – Understand system boundaries and trust zones between OT and IT networks.
    – Support risk assessments, change impact analysis, and validation or verification activities.

    Boundaries and what it is not

    Data flow mapping:

    – **Is about movement and location of data**, not about detailed business rules or algorithms.
    – **Is system- and process-focused**, not limited to network-layer packets or code-level interactions.
    – **May include high-level technical details** (e.g., protocol, interface type) but usually does not replace full network diagrams or application design specifications.

    It is not the same as:

    – **Process mapping**: which focuses on business or manufacturing steps, roles, and decisions; data flows may be one component, but are not the only focus.
    – **Value stream mapping**: which concentrates on material and information flow for performance and waste analysis, rather than documenting specific data interfaces and storage locations.
    – **Data modeling**: which describes data structure and relationships (schemas, entities, attributes), not how data moves between systems.

    Common confusion and misuse

    Data flow mapping is sometimes confused with general “system architecture” or “network” diagrams. While these may overlap, data flow mapping is specifically concerned with:

    – What data items move.
    – Between which endpoints.
    – By what mechanisms.
    – Under which process context and controls.

    Another common misuse is to focus only on formal, IT-managed integrations and ignore:

    – Ad-hoc spreadsheets and local databases.
    – Manual exports, email attachments, removable media.
    – Shadow tools and unofficial workflows on the shop floor.

    These informal flows often handle sensitive production, quality, or customer data and are important to capture.

    Site context: security and compliance readiness

    In the context of security and frameworks such as CMMC or similar requirements, data flow mapping is used to:

    – Identify where controlled or regulated data enters manufacturing operations (e.g., controlled drawings, specifications, contract data).
    – Trace how that data moves through OT systems, shop-floor workflows, supplier interactions, and back-office systems.
    – Highlight undocumented or ungoverned paths (e.g., printing drawings, copying to USB, sharing via personal email) that can become compliance and security gaps.

    For assessments and audits, documented data flow maps provide evidence that an organization understands and manages how sensitive information is handled across production, IT, and supplier ecosystems.

  • brownfield

    Core meaning

    In industrial and manufacturing contexts, **brownfield** commonly refers to an existing, already built and operating facility, process, or system that is being upgraded, expanded, or integrated with new technology, rather than designed and implemented from scratch.

    The term is used in contrast to **greenfield**, which describes new facilities or systems built on a “clean slate” without legacy constraints.

    Use in manufacturing and OT/IT systems

    In regulated manufacturing and operations technology (OT) and information technology (IT), brownfield typically means:

    – **Existing plants and production lines** that are already commissioned and producing product.
    – **Legacy automation and control systems** (PLCs, SCADA, DCS, historians) that must remain in place while being connected to newer systems.
    – **Established MES/ERP/QMS implementations** that are already validated or embedded in daily operations.

    Projects described as brownfield often involve:

    – Integrating a new MES with legacy equipment and existing business systems.
    – Adding new lines or equipment into a running plant with existing standards and data models.
    – Migrating from one system (e.g., an old MES) to another while maintaining production.

    Because the environment already exists, brownfield work must account for installed hardware and software, data models, standard operating procedures, and regulatory validation status.

    Boundaries and exclusions

    In this site context, **brownfield**:

    – **Includes** existing factories, warehouses, utilities, and their associated digital systems (OT/IT) that are being modified, integrated, or modernized.
    – **Includes** projects where new systems (such as MES, historians, or analytics platforms) are introduced into running operations.
    – **Excludes** purely conceptual or new, not-yet-built facilities (these are typically **greenfield**).
    – **Excludes** the narrower environmental-planning use of “brownfield” to mean land contaminated by prior industrial use, except where explicitly stated.

    Common confusion with other uses

    The word **brownfield** is also used in urban planning and environmental regulation to describe land or real estate that may be contaminated by prior industrial activity.

    On this site, unless environmental remediation is explicitly discussed, **brownfield** should be understood primarily as:

    – An **existing operational environment** with legacy systems and constraints, being changed or integrated.

    This is distinct from:

    – **Greenfield**: new build with no legacy constraints.
    – **Brownfield site (environmental)**: land requiring environmental assessment or cleanup.

    Site context: brownfield and MES/local process adaptation

    When discussing MES and local process adaptation in a brownfield plant:

    – The MES is deployed into an **existing plant** with established processes, equipment, and data flows.
    – Local teams often adapt processes within the constraints of existing MES configuration, validation, and integration.
    – Changes typically need to respect legacy interfaces, historical data, and regulatory documentation that already exist.

    In this context, calling a deployment **brownfield** highlights that MES or other systems must coexist with and adapt to the current operational and regulatory landscape, rather than redefining it from scratch.

  • Functional hierarchy

    A functional hierarchy is a structured breakdown of an organization’s activities into ordered functional levels, showing how high-level business functions relate to lower-level manufacturing and control functions. It is used to model who does what, at which level, and with which systems, rather than where equipment is physically located.

    In manufacturing and industrial operations

    In regulated and complex manufacturing environments, a functional hierarchy commonly refers to the layered view of enterprise and manufacturing functions defined in standards such as ISA‑95 / IEC 62264. Typical levels include:

    • Enterprise and business planning functions (e.g., strategic planning, financials, corporate scheduling)
    • Manufacturing operations management functions (e.g., production scheduling, MES, quality management, maintenance management, warehouse management)
    • Manufacturing control functions (e.g., SCADA, batch control, recipe execution, cell/area supervision)
    • Process and equipment control functions (e.g., PLC logic, DCS control loops, safety instrumented functions)

    Each level groups functions that share similar scope and time horizons. The functional hierarchy helps describe interfaces between ERP, MES, LIMS, SCADA, control systems and other applications by clarifying which functions are performed at which level.

    Operational use

    Practitioners use functional hierarchies to:

    • Map business processes and manufacturing workflows to system responsibilities
    • Define integration boundaries between ERP, MES, quality, maintenance and control systems
    • Clarify ownership of data and decisions at different levels (planning vs execution vs control)
    • Support impact analysis and change control when systems or processes are modified

    In regulated environments, documenting the functional hierarchy can support system life cycle documentation, validation planning and clear segregation of duties between systems and organizational roles.

    Common confusion

    • Functional hierarchy vs physical hierarchy: A functional hierarchy organizes activities and responsibilities. A physical hierarchy organizes equipment and locations (site, area, line, unit, asset). Many models use both views together.
    • Functional hierarchy vs organizational chart: An org chart shows reporting lines between people or departments. A functional hierarchy focuses on the functions and capabilities, which may be implemented by multiple departments or systems.

    Relation to IEC 62264 / ISA‑95

    IEC 62264 (aligned with ISA‑95) uses functional hierarchies to describe how enterprise systems like ERP and manufacturing systems like MES, SCADA and control systems are partitioned by function. The standard’s levels are a reference model for organizing these functions and for discussing which information should be exchanged between levels, without prescribing specific products or enforcing interoperability.

  • B2MML

    B2MML (Business To Manufacturing Markup Language) is an open, XML-based implementation of the ISA-95 standard. It provides a set of XML schemas that represent ISA-95 object models and data structures so that business systems (such as ERP) and manufacturing systems (such as MES, LIMS, and SCADA/PCS interfaces) can exchange information in a consistent way.

    What B2MML includes

    B2MML commonly includes XML schemas for representing:

    • Enterprise, site, and area models
    • Equipment and production line hierarchies
    • Material definitions, lots, and inventories
    • Production schedules and work orders
    • Production performance and event data
    • Personnel and work center assignments

    Vendors and integrators use these schemas to define message formats for integrations, such as sending production schedules from ERP to MES, or sending production response data from MES back to ERP.

    How B2MML is used in industrial environments

    In regulated and complex manufacturing environments, B2MML is commonly used as a neutral data model and message structure between systems, for example:

    • Integrating ERP or planning systems with MES and scheduling tools
    • Exchanging material master and bill-of-material information with manufacturing systems
    • Capturing production results, consumption, and genealogy from MES and feeding them to ERP or data warehouses
    • Standardizing the interface definitions in multi-vendor system architectures

    B2MML itself does not enforce validation, security, or regulatory compliance. It defines how data is structured and labeled, not how systems must behave or be configured.

    Relationship to ISA-95

    ISA-95 is a conceptual and logical standard that defines models and terminology for integrating enterprise and control systems. B2MML turns those models into concrete XML schemas that can be implemented in software interfaces. B2MML is therefore often described as a practical implementation layer for ISA-95 data exchanges.

    Common confusion

    • Not a protocol: B2MML defines message structures (schemas), not the transport mechanism. It is typically used over web services, message queues, or file transfer, depending on the integration design.
    • Not a full integration solution: B2MML does not replace integration platforms, middleware, or custom mapping logic. It is a data model and schema set that those solutions can use.
    • Not identical to ISA-95: ISA-95 is the overarching standard; B2MML is one widely used XML implementation of that standard.

    Context from interoperability discussions

    In interoperability discussions, B2MML is often mentioned alongside standards such as OPC UA and ISA-95. While it can support interoperability by providing a shared data structure for messages, actual interoperability still depends on vendor implementations, configuration, data mapping, and change control across the integrated systems.

  • data collection

    Core meaning

    Data collection is the systematic capture of raw data from people, machines, and software systems into a defined structure so it can be stored, processed, and analyzed.

    In industrial and regulated manufacturing environments, data collection commonly refers to the ongoing recording of production, quality, maintenance, and environmental data from shop-floor activities and related IT/OT systems.

    How data collection is used in manufacturing

    Typical uses in manufacturing and industrial operations include:

    – **Production execution data**: start/stop times, quantities produced, scrap counts, downtimes, changeovers, and operator IDs.
    – **Quality and inspection data**: measurements, test results, pass/fail decisions, sampling results, and inspection sign-offs.
    – **Equipment and process data**: temperatures, pressures, speeds, setpoints, alarms, and events from PLCs, SCADA, historians, and sensors.
    – **Material and genealogy data**: lot/batch IDs, serial numbers, material consumption, and traceability links between inputs and finished goods.
    – **Compliance and log data**: electronic signatures, access logs, audit trails, and records needed to support internal and external audits.

    Data may be collected:

    – **Manually** (operators entering values on MES terminals, checklists, or forms)
    – **Automatically** (direct acquisition from machines, instruments, and control systems)
    – **Via integration** (exchanging data between MES, ERP, LIMS, CMMS, WMS, and other enterprise systems)

    Boundaries and scope

    Data collection:

    – **Includes** the processes, configurations, and mechanisms used to capture and store raw data at the point of occurrence.
    – **Includes** the definition of what data is captured (data model, fields, timestamps, identifiers) and at what frequency or trigger.
    – **Does not inherently include** analysis, reporting, or decision-making; those are downstream activities (such as analytics, reporting, or operations intelligence) that use collected data.
    – **Does not necessarily imply enforcement** of process steps or rules; it can record what happened without preventing non-compliant actions.

    Common methods and system roles

    In OT/IT and MES contexts, data collection commonly involves:

    – **MES and electronic batch records (EBR)** capturing operator actions, inspections, and process parameters during execution.
    – **Data historians** storing high-frequency time-series data from control systems and sensors.
    – **SCADA/HMI systems** logging alarms, events, and process values.
    – **Edge devices and gateways** aggregating and normalizing data from heterogeneous equipment.
    – **Integration middleware or APIs** transferring data into central repositories, data lakes, or enterprise applications.

    Configuration typically specifies:

    – Trigger conditions (e.g., at operation start/end, at defined time intervals, at alarm, on measurement)
    – Required versus optional fields
    – Data validation rules and formats
    – Time synchronization and source identification

    Relation to MES enforcement (site context)

    When discussing whether an MES can enforce that specific steps or inspections are completed, **data collection** refers to recording the evidence that those steps or inspections were carried out (e.g., entering inspection results, capturing electronic signatures, logging machine parameters).

    In this context:

    – Data collection provides the **record** that an operation, test, or check occurred.
    – Enforcement logic in MES uses required data collection points, routing rules, and status checks to **block progression** until the needed data has been entered or captured.
    – Audit trails and access logs are collected data that demonstrate who performed or approved each action.

    However, the mere presence of data collection screens or fields does not guarantee enforcement; enforcement depends on how the MES and related systems use collected data in workflow and authorization rules.

    Common confusions and related terms

    – **Data collection vs. data logging**: Data logging often implies automated, continuous recording (e.g., from sensors), whereas data collection is broader and includes manual and event-based capture.
    – **Data collection vs. data acquisition (DAQ)**: Data acquisition usually refers to the technical process of reading signals from hardware; data collection is wider and includes human inputs, system integrations, and structured storage.
    – **Data collection vs. data analysis**: Collection is about capturing and storing; analysis is about interpreting and using that data.

    Using these terms precisely helps distinguish between:

    – The act of recording what happened (data collection)
    – The mechanisms that read physical signals (data acquisition)
    – The processing and interpretation of information (analytics, reporting, operations intelligence)