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.

  • What does a “third way” for industrial digitalization look like?

    The phrase “third way” for industrial digitalization commonly refers to a hybrid approach for designing and deploying digital systems in manufacturing that sits between two traditional extremes:

    • Custom, one-off solutions that are heavily engineered, expensive to maintain, and hard to scale.
    • Rigid, monolithic platforms (for example some MES, ERP, or MOM suites) that are standardized but often slow to adapt to local plant needs or changing regulations.

    The “third way” aims to combine the strengths of both while avoiding their main drawbacks.

    Core characteristics of a “third way” approach

    • Modular and composable
      Systems are built from reusable building blocks such as workflows, forms, data connectors, and equipment adapters. Plants can assemble these modules for different lines, products, or regulatory regimes without starting from scratch.
    • Configuration over custom code
      Most behavior is controlled through configuration, not bespoke programming. This shortens validation and change control cycles in regulated environments and reduces dependency on scarce specialist developers.
    • Open, interoperable data layer
      The approach emphasizes open APIs, event streaming, and data models that can bridge OT, MES, ERP, LIMS, QMS, and PLM rather than locking data into a single monolithic system.
    • Local flexibility within global guardrails
      Corporate standards (for example master data definitions, mandatory quality records, traceability rules) are enforced centrally, while plants have room to adapt screens, workflows, and integrations to their local processes and equipment.
    • Incremental and iterative
      Instead of multi-year, big-bang rollouts, the third way favors stepwise implementations (line by line, site by site) with rapid feedback, learning, and continuous improvement.
    • Designed for compliance by construction
      Capabilities such as audit trails, electronic signatures, version control, and change history are embedded as standard features, so new workflows inherit compliant behavior instead of requiring repeated re-engineering.

    What it is not

    • It is not a single product or vendor offering, but a pattern for how organizations structure their digital architecture and delivery model.
    • It is not limited to a specific layer like MES or SCADA. The approach can span shop floor systems, quality and laboratory systems, data platforms, and higher-level business applications.
    • It does not imply reduced rigor in validation, security, or change control. Instead it tries to make those controls more systematic and reusable.

    Why it matters in regulated manufacturing

    In regulated or highly audited environments, a third way approach can help balance:

    • Standardization for consistent records, traceability, and audit readiness across sites.
    • Adaptability to frequent changes in product mix, customer requirements, or regulatory expectations.
    • Total cost of ownership by reducing duplicated custom solutions and avoiding overly rigid platforms that are costly to modify and validate.

    Example in an industrial context

    Instead of building a fully custom MES or accepting an out-of-the-box template that does not fit operations, a manufacturer might:

    • Adopt a modular execution and data layer that integrates with existing ERP, historians, and quality systems.
    • Use configurable digital work instructions, checklists, and data capture forms that share a standard data model across plants.
    • Apply shared, reusable patterns for electronic signatures, deviations, and CAPA triggers, while allowing each plant to tailor details such as step sequences and equipment mappings.

    In this sense, the “third way” is a practical architectural and organizational strategy for industrial digitalization that pursues both control and flexibility rather than choosing only one.

  • supplier integration

    Supplier integration commonly refers to the structured connection of a manufacturer’s systems, data, and processes with those of its suppliers. In industrial and regulated manufacturing environments, it focuses on how information about materials, parts, processes, and changes flows across organizational boundaries so that upstream activities can be monitored, controlled, and traced.

    Supplier integration can occur at several levels, from simple electronic data exchange to deep process and quality collaboration. It typically involves IT and OT systems such as ERP, MES, LIMS, QMS, and supplier portals, along with defined processes for data governance, change management, and issue escalation.

    Key elements

    In manufacturing operations, supplier integration commonly includes:

    • Data integration: Exchanging purchase orders, advanced shipping notices, certificates of analysis, inspection results, and batch/lot information between supplier and manufacturer systems.
    • Process integration: Aligning specifications, work instructions, quality plans, and change-control workflows across organizations so that suppliers operate to the same controlled requirements.
    • Quality and compliance integration: Sharing nonconformance data, CAPA actions, deviations, and audit findings, and linking them to specific supplier lots, batches, or processes.
    • Traceability and genealogy: Capturing supplier material identifiers and process data so they can be traced through manufacturing, testing, and final product release.
    • Technical collaboration: Providing controlled access to drawings, recipes, specifications, and approved changes via secure platforms or portals.

    How it appears in workflows and systems

    Operationally, supplier integration shows up as:

    • Automated transfer of purchasing, delivery, and invoice data between ERP systems.
    • Inbound material receiving processes that use supplier-provided data (e.g., barcodes, serials, COAs) to populate MES, QMS, or warehouse systems.
    • Digital approval workflows where supplier process changes or specification updates are reviewed and released using controlled documents and version governance.
    • Quality workflows that link supplier nonconformances and test results to lots, equipment, and finished goods within plant systems.
    • Dashboards that combine internal and supplier metrics to monitor lead times, defect rates, and supply risk.

    Supplier integration in regulated environments

    In regulated or highly audited industries, supplier integration usually requires documented interfaces, validation or verification of data flows, and alignment with existing quality, traceability, and change-control processes. Integrations are commonly scoped to specific data sets (for example, material certificates, test results, and approved specifications) and are managed under formal change-control and document-control practices.

    Common confusion

    • Supplier integration vs. supplier management: Supplier management covers the broader relationship, including contracts, performance reviews, and risk assessments. Supplier integration focuses more narrowly on how systems, data, and processes are connected.
    • Supplier integration vs. EDI only: Electronic Data Interchange (EDI) is one technical method for exchanging data. Supplier integration is broader and may include APIs, web portals, shared PLM or QMS workflows, and collaborative engineering processes.

    Context from scrap and upstream quality

    When applied to scrap prevention and upstream quality control, supplier integration often means exposing supplier process or test data early, tightening specification and change-control alignment, and linking supplier lots and parameters to internal quality records. This makes it easier to detect nonconformances before they propagate into production and to trace issues back to the originating supplier processes.

  • KPI migration

    KPI migration commonly refers to the process of moving key performance indicators (KPIs) from one system, data model, or reporting environment to another while preserving their definitions, calculations, and operational meaning.

    What KPI migration includes

    In industrial and manufacturing environments, KPI migration typically involves:

    • Inventory and mapping of existing KPIs such as OEE, yield, scrap, on-time delivery, and backlog across MES, ERP, QMS, and data warehouse tools.
    • Translating KPI definitions into a new data model, database schema, or analytics platform, including how inputs (tags, transactions, quality records) are sourced and aggregated.
    • Reimplementing calculations and logic in the target system (for example, moving from spreadsheet-based KPIs to an MES, BI tool, or data lakehouse).
    • Validating and reconciling results between old and new environments to ensure that KPI values, thresholds, and trends remain consistent and trustworthy.
    • Updating visualizations and workflows such as dashboards, scorecards, shop-floor displays, and management reports that consume these KPIs.

    KPI migration can occur during MES or ERP upgrades, consolidation of plants into a common reporting model, introduction of a centralized data platform, or replacement of legacy reporting tools.

    What KPI migration does not include

    KPI migration is distinct from:

    • Defining new KPIs from scratch, although gaps or inconsistencies may be discovered and addressed during migration.
    • Business process redesign, such as changing production scheduling or quality workflows. Those changes may trigger KPI migration but are separate activities.
    • Simple data backup or replication that copies raw data without re-establishing KPI logic and governance.

    Operational perspective in manufacturing

    From an operational standpoint, KPI migration often touches:

    • OT and MES data, including machine states, downtime codes, and production counts feeding OEE and throughput metrics.
    • ERP and supply chain data, such as work-order status, purchase orders, and delivery performance feeding supplier scorecards and on-time delivery KPIs.
    • Quality systems, including nonconformance, rework, and scrap records feeding COPQ, defect rates, and customer complaint KPIs.
    • Governance and documentation, where KPI definitions, owners, calculation rules, and data lineage are documented or revised during the migration.

    Common confusion

    KPI migration is sometimes confused with:

    • KPI redesign or rationalization, which focuses on choosing which KPIs to use and how many. KPI migration is about transporting and re-establishing KPIs, though rationalization may occur as a side effect.
    • System migration (for example, moving from one MES to another). System migration is broader and covers all data and functions; KPI migration focuses specifically on performance metrics and their implementation in the new environment.

    In regulated and audited environments

    In regulated manufacturing, KPI migration commonly includes retaining evidence of how KPIs were defined before and after migration, documenting changes in formulas or data sources, and ensuring that historical KPI trends remain interpretable when systems or data platforms change.

  • integration layer

    An integration layer is an architectural tier in an information system that connects, mediates, and coordinates data and processes between otherwise separate applications or platforms. In industrial and manufacturing environments, it commonly sits between shop-floor systems (for example MES, SCADA, PLC networks) and higher-level business or enterprise systems (for example ERP, quality, or planning tools).

    The integration layer focuses on how systems communicate, not on executing production itself. It typically provides routing, data transformation, protocol adaptation, and orchestration of messages or events, so that each connected system can continue to use its own internal data structures and technologies.

    Key characteristics

    • Mediation and routing: Receives data or events from one system and delivers them to one or more target systems based on defined rules.
    • Data transformation: Maps and converts data formats, codes, and structures (for example, aligning equipment IDs or material codes) so that systems with different schemas can interoperate.
    • Protocol and interface adaptation: Bridges different technical interfaces, such as translating between OPC UA, message queues, REST or SOAP APIs, and file-based exchanges.
    • Orchestration and workflows: Coordinates multi-step interactions across several systems, such as synchronizing production orders between ERP and MES and updating quality records.
    • Centralized governance: Provides a controlled point for managing versions, monitoring integrations, and enforcing security and access rules across connected systems.

    Operational context in manufacturing

    In a manufacturing setting, the integration layer often appears as middleware platforms such as enterprise service buses, iPaaS tools, or custom API gateways. It may handle scenarios like:

    • Exchanging production orders and confirmations between ERP and MES.
    • Collecting equipment data from OT systems and publishing it to historians, analytics platforms, or operations intelligence tools.
    • Synchronizing master data, such as materials, routes, and work centers, across multiple plants or systems.
    • Standardizing metric definitions (for example, OEE, availability, or scrap) into consistent, site-specific schemas before they are consumed by reporting or KPI dashboards.

    The integration layer does not replace MES, ERP, PLCs, or quality systems. Instead, it provides a structured way for them to exchange data reliably and consistently, especially when different plants or vendors use differing standards or versions.

    Relation to standards and data contracts

    When organizations align to standards such as ISA-95 or ISO 22400, the integration layer is often where those reference models are translated into concrete APIs, message schemas, and data contracts. The layer can:

    • Implement canonical data models derived from standards while allowing each system to maintain its native model.
    • Version and document how each metric or object is represented and computed across the environment.
    • Provide a single place to adapt integrations when standards, system versions, or internal conventions change.

    Common confusion

    • Integration layer vs. MES or ERP: The integration layer does not plan, execute, or record production as a system of record. It only coordinates information flows between such systems.
    • Integration layer vs. data lake or historian: A data lake or historian primarily stores and analyzes large volumes of data. The integration layer primarily moves and transforms data, though it may deliver data into these repositories.
    • Integration layer vs. API: An API is a specific interface exposed by a system or the integration layer itself. The integration layer is the architectural tier that hosts, manages, and composes multiple APIs and other integration mechanisms.
  • Operational data store (ODS)

    An operational data store (ODS) is a centralized data repository that collects and holds current or near-real-time data from multiple operational systems so it can be viewed, queried, and shared in a consistent way. In manufacturing and regulated operations, an ODS commonly brings together data from systems such as MES, ERP, quality, maintenance, laboratory, or shop-floor equipment interfaces.

    An ODS is usually designed for integrated operational reporting, status visibility, and short-to-medium-term data access. It is not the same as the original source system, and it is not usually the long-term historical repository used for enterprise analytics. Data in an ODS is typically refreshed frequently and normalized enough to support cross-system use, while still staying close to the operational state of the business or plant.

    Where it applies

    In industrial environments, an ODS may be used to assemble a current view of production orders, material status, quality holds, equipment events, labor activity, or shipment readiness across systems that were not built to provide one shared operational picture. It often sits between transactional applications and downstream reporting, analytics, or integration layers.

    For example, a manufacturer might use an ODS to combine work order status from ERP, execution details from MES, and nonconformance status from a quality system so supervisors and planners can review the latest operating conditions without querying each system separately.

    What an ODS includes and excludes

    • Includes: integrated operational data from multiple sources, frequent updates, standardized structures for querying, and support for operational dashboards, reconciliation, and handoff to other systems.

    • Excludes: direct replacement of source applications, full system-of-record responsibilities, and in most cases the deep historical modeling associated with a data warehouse or data lake.

    Common confusion

    ODS vs. data warehouse: An ODS commonly focuses on current operational data and short-latency access. A data warehouse commonly focuses on historical, trend, and analytical use across longer time horizons.

    ODS vs. database: An ODS is a specific integration-oriented data layer, not just any database.

    ODS vs. system of record: The source application usually remains the authoritative system of record for transactions, approvals, and master ownership unless governance is explicitly designed otherwise.

    Manufacturing context

    In MES and ERP integration, an ODS often supports reporting consistency, cross-functional visibility, and downstream interfaces that need a consolidated operational view without placing reporting load on production systems. In regulated settings, its role is commonly informational and integrative. Record authority, audit trails, retention rules, and approval logic usually remain governed by the originating applications and the surrounding data management design.

  • data source

    A data source is the defined origin of data that a system, report, or analysis uses. In industrial and regulated manufacturing environments, it describes where the data comes from, how it is accessed, and which system or device is considered the authoritative provider of that data.

    What a data source includes

    In operations and manufacturing, a data source commonly refers to:

    • A specific IT or OT system, such as an MES, ERP, QMS, PLM, historian, SCADA system, CMMS, or LIMS
    • A particular database, schema, table, or view used for reporting (for example, a production orders view in the MES database)
    • A defined interface or feed, such as an API endpoint, OPC UA server, message queue, or file drop location
    • A measurement or collection point, such as a test stand, machine controller, sensor network, or inspection station that generates structured data

    The term also implies configuration details that allow systems to connect to and interpret the data, such as connection parameters, credentials, and data models or tags.

    What a data source is not

    • It is not the data set itself, but the origin from which data sets are retrieved.
    • It is not the business rule or KPI definition, although those rules specify which data sources they rely on.
    • It is not necessarily the physical equipment alone; it is the combination of equipment plus the defined interface that makes it a usable source.

    Operational use in manufacturing and quality

    In practice, a data source is specified whenever plants define KPIs, integration flows, or audit trails. Examples include:

    • Defining OEE or ISO 22400 KPIs based on a specific MES event log as the data source for run time, stop time, and quantities produced
    • Stating that the ERP production order table is the data source for planned quantities and required dates
    • Using a calibrated measurement system as the data source for dimensional inspection results in an FAI or AS9102 report
    • Declaring the plant historian as the data source for environmental or process parameters required for traceability

    Clear identification of data sources supports data lineage, change control, and repeatable calculations. In contracts or specifications, especially in regulated sectors, parties often list data sources for each metric so that results can be reproduced and audited.

    Common confusion

    • Data source vs. system of record: A system of record is the authoritative system for a specific type of information. A data source is any origin a report or interface reads from, which might or might not be the system of record.
    • Data source vs. interface: An interface (such as an API or file format) is the technical mechanism used. A data source is the combination of system, interface, and defined location that provides the data.
    • Data source vs. dataset: A dataset is a particular extracted set of values, often stored or exported. The data source is where those values were originally obtained.

    Relation to contracts and KPI definitions

    When suppliers and customers formalize KPIs, such as those aligned with ISO 22400, they typically specify the data source for each metric. For example, a contract might define that on-time delivery is calculated using shipment dates from the ERP system as the data source, while machine availability is calculated using event logs from the MES. This common language reduces ambiguity in how metrics are calculated and validated across different plants and systems.

  • Crosswalk

    A crosswalk is a structured mapping that aligns data elements, business processes, or requirements between two different systems, models, or standards. In industrial and regulated manufacturing environments, it is commonly used to compare and translate between data schemas, coding systems, or compliance frameworks so that information can be interpreted consistently across tools and organizations.

    How crosswalks are used in manufacturing and operations

    In practice, a crosswalk often appears as a controlled document, configuration file, or mapping table inside an integration or reporting solution. Typical uses include:

    • System integration mappings: Aligning fields and codes between MES and ERP (for example, mapping operation codes, work-center IDs, material numbers, or nonconformance codes).
    • Standard and requirement mappings: Relating clauses or controls across standards (for example, mapping ISO 9001 requirements to internal procedures or to aerospace-specific standards).
    • Data normalization: Converting legacy codes and naming conventions into a unified model used for reporting, traceability, OEE, or CAPA analytics.
    • Regulatory and security mappings: Relating security or compliance controls from one framework to another so that evidence and audit artifacts can be reused.

    A well-governed crosswalk typically identifies the source element, the target element, and the relationship between them (such as one-to-one, one-to-many, or partial match), along with any transformation rules or conditions.

    What a crosswalk is not

    • It is not the data itself, but a reference that explains how different data sets or requirement sets relate.
    • It is not a full integration platform, although it is often a key configuration artifact used by integration tools and ETL processes.
    • It is not a process flowchart, though it may complement process maps by explaining how steps in different systems correspond.

    Common confusion

    • Crosswalk vs. data dictionary: A data dictionary describes fields within a single system or database. A crosswalk relates fields or codes between systems or models.
    • Crosswalk vs. traceability matrix: A traceability matrix tracks coverage (for example, requirements to tests or requirements to design elements). A crosswalk focuses on equivalence or translation between different structures, such as two standards or two coding schemes.
    • Crosswalk vs. interface specification: An interface spec defines how systems exchange data (protocols, formats). A crosswalk defines how the meaning of data elements in one context corresponds to another.
  • Semantic layer

    A semantic layer is a business-focused data model that sits between raw data sources and end-user tools such as reports, dashboards, and self-service analytics. It translates technical data structures, tables, and fields into consistent business terms such as part, work order, nonconformance, or batch, so that users can query and analyze data without needing to know the underlying database schemas.

    Key characteristics

    In manufacturing and industrial operations, a semantic layer commonly includes:

    • Business entities and relationships: Definitions of core objects such as work orders, routings, equipment, lots, serial numbers, inspections, and suppliers, and how they relate to each other.
    • Standardized metrics and KPIs: Common calculations such as OEE, first-pass yield, scrap rate, on-time delivery, and cycle time, defined once and reused across reports.
    • Logical views of multiple systems: A unified representation of data coming from MES, ERP, QMS, PLM, historians, and other OT/IT sources, presented as a single, coherent model.
    • Business-friendly naming: Column and object names expressed in language that engineers, quality teams, and operations leaders recognize, instead of system-specific field codes.
    • Centralized rules: Shared filters, hierarchies, time logic, and other rules applied consistently across all consuming tools.

    How it is implemented

    A semantic layer can be implemented in several technical forms, including:

    • Business intelligence (BI) models inside tools like Power BI or other analytics platforms, where the semantic model is embedded in the reporting environment.
    • Logical data models in data warehouses or data lakehouses, where views or modeled layers expose business concepts derived from raw tables.
    • Metadata-driven semantic platforms that expose the layer through SQL, APIs, or standardized query interfaces for many tools to consume.

    Operationally, analysts and engineers use the semantic layer as their main entry point for building dashboards and analyses on production performance, quality, supply chain status, or maintenance, rather than connecting directly to individual source systems.

    What it includes and excludes

    • The semantic layer includes logical models, naming conventions, relationships, and metric definitions that describe how data should be interpreted and queried.
    • It does not typically include the physical storage of data itself; storage resides in databases, data warehouses, or data lakes beneath the model.
    • It is not the same as an ETL/ELT process, although it often depends on those processes to prepare and integrate data before it is modeled semantically.

    Use in regulated and manufacturing environments

    In regulated manufacturing, a semantic layer commonly supports:

    • Traceability analysis: Consistent views of genealogy across work orders, lots, serials, and supplier data.
    • Quality and NCR reporting: Standardized structures for nonconformances, CAPA records, inspections, and test results across plants or programs.
    • Operations performance: Harmonized KPIs for OEE, downtime, throughput, and labor utilization across multiple lines or sites.
    • Compliance evidence queries: Repeatable ways to retrieve data that may be needed for audits or internal reviews, without rewriting complex joins for every request.

    Common confusion

    • Semantic layer vs. data warehouse: A data warehouse is a physical repository where integrated data is stored. The semantic layer is a logical model that describes and exposes that data in business terms. A warehouse can exist without a semantic layer, and a semantic layer can span multiple warehouses or databases.
    • Semantic layer vs. data integration/ETL: Data integration pipelines move, transform, and standardize data between systems. The semantic layer focuses on how that data is described, related, and queried by end users.
    • Semantic layer vs. KPI catalog: A KPI catalog documents metric definitions. A semantic layer not only defines metrics but also implements them in a technical model that tools can query directly.