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.

  • UTC (Coordinated Universal Time)

    UTC (Coordinated Universal Time) is the primary global reference time standard used to keep timestamps consistent across locations, systems, and time zones. It provides a common baseline for recording events, synchronizing clocks, and exchanging time-based data.

    In manufacturing and regulated operations, UTC commonly appears in system logs, audit trails, equipment data, MES and ERP integrations, historian records, and data exchanged between sites in different local time zones. A timestamp stored in UTC can be converted for display in a user's local time zone without changing the original event time.

    UTC is not a local time zone. It does not change for daylight saving time, and it is not the same as a site's local operating time. It is also distinct from how time is displayed to users. For example, an event may be stored in UTC in a database but shown in Eastern Time or Central European Time in an application interface.

    Operational meaning

    • Used as a standard timestamp reference across plants, systems, and regions

    • Supports consistent sequencing of events in logs, alarms, transactions, and electronic records

    • Helps reduce ambiguity when integrating MES, ERP, SCADA, historians, LIMS, or quality systems

    • Commonly used in APIs, databases, cloud platforms, and machine-generated data

    Common confusion

    UTC vs GMT: These are often treated as equivalent in everyday use, but UTC is the modern time standard commonly used in technical systems.

    UTC vs local time: Local time includes a regional offset from UTC and may change with daylight saving rules. UTC itself does not.

    UTC vs time synchronization protocols: UTC is the reference time standard, while protocols such as NTP or PTP are methods used to synchronize devices and systems to a time source.

    In manufacturing systems

    Using UTC as the system-of-record time basis is common where traceability, cross-site reporting, or multi-system reconciliation matters. Examples include comparing machine events from different plants, aligning ERP transaction times with MES execution records, or reviewing audit trail entries generated by systems in different time zones.

  • What is a semantic model in the context of manufacturing KPIs?

    In this context, a semantic model is a shared business definition layer for manufacturing data and KPIs. It specifies how measures such as throughput, scrap, downtime, yield, schedule attainment, or OEE are defined, where the source data comes from, how entities relate to each other, and which calculation rules apply.

    Put simply, it is the structure that helps different systems and teams interpret the same KPI the same way. Instead of every report or dashboard defining metrics separately, the semantic model provides a controlled way to say things like:

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

    • what counts as a production order, operation, machine state, shift, batch, lot, or work center
    • which source system is authoritative for each field
    • how timestamps, units of measure, and time zones are handled
    • how events roll up into site, line, asset, product family, or program level KPIs
    • which exclusions, assumptions, and calculation windows apply

    For manufacturing KPIs, that matters because the same metric often produces different numbers depending on source selection and business rules. For example, downtime from an equipment historian, downtime from MES, and downtime from operator-entered production logs may all be useful, but they are not automatically interchangeable.

    What a semantic model usually includes

    A practical semantic model for KPI reporting often includes:

    • standard metric definitions
    • master data relationships between products, assets, routings, lines, plants, and suppliers
    • calculation logic and aggregation rules
    • hierarchies for drilldown and rollup
    • data lineage back to source systems
    • governance for versioning, approvals, and change control

    In regulated or high-traceability environments, the governance part is as important as the technical structure. If a KPI definition changes, teams typically need to know what changed, when it changed, who approved it, and whether historical reporting should be restated or left as originally calculated.

    What it does and does not solve

    A semantic model can reduce reporting disputes, improve comparability across plants, and make analytics tooling more consistent. It can also make it easier to connect KPI dashboards to operational context such as genealogy, nonconformance, maintenance, or routing status.

    But no, it is not a shortcut around data integration, data quality, or validation. If source systems are inconsistent, late, poorly mapped, or missing key events, the semantic model will expose those problems more clearly, not remove them. It also does not guarantee that two sites can use identical KPI logic if their processes, automation maturity, or data capture methods differ materially.

    Brownfield reality

    In most plants, the semantic model sits across existing MES, ERP, historian, SCADA, QMS, PLM, EAM, and spreadsheet-driven processes. That coexistence is normal. In many regulated operations, replacing all source systems just to standardize KPIs is usually not realistic because of qualification burden, validation cost, downtime risk, integration complexity, and long equipment lifecycles.

    That is why semantic modeling is often used as a coexistence strategy. It creates a governed interpretation layer above mixed systems instead of forcing immediate full replacement. The tradeoff is that the model is only as strong as the mappings, interfaces, and data stewardship behind it.

    Common failure modes

    • definitions are standardized on paper but source event logic remains inconsistent
    • master data is not aligned across ERP, MES, and quality systems
    • time handling differs by system, causing shift and utilization errors
    • local plant exceptions are hidden instead of modeled explicitly
    • ownership of KPI definitions is unclear
    • changes are made in dashboards without formal review or traceability

    If the goal is trustworthy KPI reporting, the semantic model should be treated as a governed operational asset, not just a BI artifact.

  • hierarchy levels

    Hierarchy levels are structured layers used to describe how functions, systems, and data are organized within a manufacturing or industrial operation. They provide a common way to reference where activities occur, which systems are responsible, and how information flows from the enterprise level down to individual machines and equipment.

    Functional hierarchy levels in manufacturing

    In regulated and complex plants, hierarchy levels often follow industrial standards that separate business planning from manufacturing execution and physical control. A common model, aligned with IEC 62264 / ISA-95, includes:

    • Enterprise / Business level (often called Level 4 or above): Long-term planning, finance, customer orders, and supply chain management, typically managed by ERP and business systems.
    • Site / Plant level: Overall plant coordination, capacity planning, and site-wide performance management.
    • Area / Line / Cell level (often called Level 3): Manufacturing execution, sequencing, dispatching, detailed scheduling, quality recording, and traceability, typically managed by MES and related execution systems.
    • Process control level (often called Level 2): Automatic control of production processes, typically using SCADA, DCS, or PLC-based control systems.
    • Equipment / field level (often called Level 1 and 0): Sensors, actuators, tools, machines, and other physical devices that directly interact with materials and products.

    These levels are used to clarify which systems own certain data, where control decisions are made, and how responsibilities are divided between IT and OT.

    Use in metrics, KPIs, and integration

    Hierarchy levels are often referenced when defining and mapping manufacturing KPIs and data flows. For example, ISO 22400 KPIs such as Overall Equipment Effectiveness (OEE) or availability can be associated with specific hierarchy levels to show:

    • At which level the raw data is generated (for example, equipment or control level).
    • Which system calculates or aggregates the KPI (for example, MES at the area or line level).
    • Where the KPI is consumed for decisions (for example, enterprise or plant management level).

    In practice, engineering, IT, and operations teams use hierarchy levels to design system architectures, define interfaces between ERP, MES, and control systems, and document data ownership and responsibilities.

    Common confusion

    • Hierarchy levels vs. organizational hierarchy: Functional hierarchy levels describe systems and control responsibilities, not reporting lines or job titles.
    • Hierarchy levels vs. network layers: They are different from network models that describe how devices are connected. A control system and a business system may sit on similar networks but occupy different functional hierarchy levels.
    • Hierarchy levels vs. building layout: Physical plant layout (buildings, floors, and rooms) is separate from functional hierarchy, although both may use terms like “area” or “cell.”

    Context for aerospace and regulated environments

    In aerospace and other regulated industries, hierarchy levels are commonly used to document which level and which system is the system of record for production data, quality records, and traceability. When mapping standardized KPIs or compliance-related metrics, associating each metric with a hierarchy level helps clarify data provenance, validation responsibilities, and how evidence will be retrieved during audits.

  • EAM (Enterprise Asset Management)

    Enterprise Asset Management (EAM) is the discipline and supporting software used to plan, operate, maintain, and track physical assets across their full lifecycle. In industrial and manufacturing environments, it focuses on keeping equipment, facilities, and infrastructure reliable, compliant, and cost-effective from acquisition through decommissioning.

    What EAM includes

    In regulated manufacturing and industrial operations, EAM commonly includes:

    • Asset registry and hierarchy: Structured records of equipment, tools, facilities, and infrastructure, including IDs, locations, specifications, and ownership.
    • Preventive and predictive maintenance: Definition, scheduling, and tracking of work to reduce unplanned downtime and extend asset life.
    • Work management: Creation, assignment, execution, and closure of maintenance work orders, with time, labor, and material tracking.
    • Spare parts and MRO inventory: Control of maintenance, repair, and operations (MRO) parts and consumables linked to specific assets and work orders.
    • Asset performance tracking: Monitoring of uptime, failure history, repair times, and lifecycle costs to support decisions on replacement, overhaul, or redesign.
    • Compliance and documentation: Maintenance logs, calibration records, and inspection histories that support audits and regulatory requirements.

    Operational role in manufacturing systems

    In modern plants, EAM is typically implemented as a specialized software platform that connects with ERP, MES, and sometimes condition-monitoring or OT systems. Typical interactions include:

    • With ERP: Sharing asset master data, purchasing requests for spare parts, and financial information such as asset capitalization and depreciation (ERP) vs. operational health and maintenance history (EAM).
    • With MES: Exchanging equipment status, maintenance-related downtime codes, and maintenance work that affects production schedules and routings.
    • With quality and compliance systems: Providing evidence that equipment was maintained and calibrated when producing specific lots or serial numbers, often used in traceability and audit trails.

    For regulated sectors such as aerospace, defense, or life sciences, EAM records often support investigations, root cause analysis, and proof that production assets were maintained according to defined standards when critical parts were manufactured or repaired.

    What EAM is not

    • Not the same as ERP: ERP focuses on financials, procurement, and high-level planning. EAM focuses on the technical and operational side of asset health and maintenance execution.
    • Not strictly MES: MES manages production execution, work instructions, and WIP tracking. EAM manages the assets on which production runs, not the products being built.
    • Not only CMMS: A Computerized Maintenance Management System (CMMS) typically covers maintenance work management. EAM is broader, covering full asset lifecycle, performance, and integration with enterprise processes.

    Common confusion

    EAM vs CMMS: A CMMS usually centers on maintenance work orders and scheduling. EAM usually includes CMMS capabilities but adds asset lifecycle management, cost tracking, strategy optimization, and tighter integration with ERP and other enterprise systems.

    EAM vs APM (Asset Performance Management): APM often emphasizes analytics, condition monitoring, and predictive models for asset performance. EAM is the operational and administrative backbone that holds master data, maintenance history, and work execution records. In practice, EAM and APM may be separate tools that integrate, or capabilities within the same platform.

    Examples in regulated manufacturing

    • Tracking maintenance and calibration for critical machining centers used in aerospace part production, with records linked to specific serial numbers and work orders.
    • Managing overhaul cycles and component histories for assets used in MRO operations, such as test stands, ground support equipment, or specialized fixtures.
    • Coordinating planned maintenance windows with production schedules so that required inspections do not conflict with delivery commitments.

  • event model

    An event model is a structured description of how events are represented, related, and stored in a system so that different applications can interpret, exchange, and analyze them consistently. In industrial and manufacturing environments, it commonly refers to the agreed format and rules for recording time-based occurrences such as equipment state changes, alarms, operator actions, and production milestones.

    Key characteristics

    A practical event model in manufacturing and OT/IT systems typically defines:

    • Event types (for example, equipment state change, alarm, production start/stop, quality decision).
    • Required attributes such as timestamps, resource identifiers, product or batch identifiers, and user or system source.
    • Optional attributes like reason codes, severity, duration, and links to related records (work orders, NCRs, maintenance orders).
    • Cardinality and rules, for example only one active equipment state event per resource at a time, or how overlapping events are handled.
    • Semantics, meaning how an event should be interpreted for KPIs, traceability, or workflows (e.g., which states count as “productive time” for OEE or ISO 22400 KPIs).

    Role in manufacturing and industrial systems

    In OT and MES/ERP-integrated landscapes, an event model provides a common language for:

    • Equipment and automation (PLC/SCADA) to report machine states and alarms in a normalized way.
    • MES and production systems to track operations, resource utilization, and shift performance based on time-stamped events.
    • Quality and compliance systems to link events to lots, batches, NCRs, or deviations for investigations and evidence trails.
    • Operations intelligence and KPIs such as OEE, non-productive time (NPT), and ISO 22400 metrics that depend on consistent state and timestamp logic.

    Event model vs data model

    An event model focuses on time-ordered changes and occurrences, while a general data model describes relatively static entities such as products, equipment, or bills of material. In many architectures, the data model defines what things exist, and the event model defines what happens to them and when.

    Common confusion

    • Event model vs message schema: A message schema (for example, a JSON or XML structure) defines the technical format of a single message. An event model is broader and covers event types, their relationships, sequencing rules, and interpretation for analytics and workflows.
    • Event model vs process model: A process model describes the intended sequence of activities or states. An event model describes the actual recorded occurrences that can later be compared against the process model.

    Relation to ISO 22400 KPIs and equipment states

    When implementing ISO 22400 manufacturing KPIs, an event model is often used to standardize how equipment state events are captured. This includes defining a unified set of states, ensuring only one active state per resource at a time, capturing precise start and end timestamps, and recording reason codes for state changes. Such a model allows vendor-specific SCADA or MES states to be normalized so that KPIs are calculated consistently across lines, plants, and systems.

  • Data Harmonization

    Data harmonization commonly refers to the process of aligning data from different sources, formats, and structures so the data can be understood and used consistently across systems, teams, and workflows. In manufacturing and regulated operations, this often includes standardizing names, codes, units of measure, reference values, and business meaning across applications such as MES, ERP, PLM, QMS, LIMS, historians, and reporting tools.

    It is not the same as simply moving data from one system to another. A file transfer, interface, or API connection may transport data without resolving differences in terminology, structure, or meaning. Harmonization focuses on making equivalent data comparable and usable together.

    What it typically includes

    • Aligning master data such as part numbers, materials, equipment IDs, suppliers, customers, and sites

    • Standardizing transactional data such as production orders, batches, quality results, downtime events, or maintenance records

    • Normalizing units, date formats, status values, naming conventions, and code sets

    • Mapping different source fields to a common business definition

    • Resolving duplicate, conflicting, or incomplete records where practical

    For example, one system may record a machine as “Line 2 Filler,” another as “FILL02,” and a third by an asset number. Harmonization links or standardizes those references so reporting and traceability use the same meaning.

    Operational meaning in manufacturing

    In operational environments, data harmonization often appears in system integration projects, plant-to-enterprise reporting, digital traceability efforts, and cross-site analytics. It supports consistent interpretation of production, quality, inventory, maintenance, and genealogy data when information comes from multiple plants, business units, or software platforms.

    Common examples include aligning defect codes between QMS and MES, standardizing material identifiers between ERP and shop floor systems, or making downtime categories comparable across production lines.

    Common confusion

    Data harmonization is often confused with related terms:

    • Data integration: focuses on connecting and exchanging data between systems. Harmonization may be part of integration, but integration alone does not guarantee consistent meaning.

    • Data standardization: usually refers to converting data into a consistent format or structure. Harmonization is broader and also addresses business meaning and cross-system alignment.

    • Data cleansing: focuses on correcting errors, duplicates, or incomplete records. Cleansing may support harmonization, but the two are not identical.

    • Master data management: governs key shared business data over time. Harmonization may rely on MDM practices, but it can also be narrower and project-specific.

    Why the term matters

    When organizations use multiple systems or sites, the same operational concept can be represented in different ways. Without harmonization, reports, traceability records, KPI calculations, and compliance evidence may be difficult to compare or interpret consistently. Data harmonization is the work of reducing those differences so data from separate sources can function together with clearer meaning.

  • Application programming interface (API)

    An application programming interface (API) is a defined interface that lets one software application exchange data with, or request functions from, another application or service. It commonly refers to the rules, endpoints, data formats, authentication methods, and expected responses that make system-to-system communication possible.

    An API is not the same thing as a user interface. People interact with screens, forms, and buttons, while software interacts with APIs. An API is also not the entire integration by itself. In practice, the full integration may also include data mapping, transformation logic, error handling, monitoring, and security controls.

    How it is used in manufacturing and regulated operations

    In manufacturing environments, APIs are commonly used to connect business and operational systems such as ERP, MES, QMS, PLM, CMMS, LIMS, and warehouse or supplier platforms. They allow systems to pass structured information without relying on manual re-entry.

    • An ERP sends production orders to an MES through an API.
    • An MES posts production results, material consumption, or lot data back to an ERP.
    • A QMS receives nonconformance or inspection data from an execution system.
    • A document or training system checks status information from another platform through an API.

    Depending on the design, an API may support real-time exchange, near-real-time updates, or event-driven communication. Some APIs are internal to one organization, while others are exposed for suppliers, customers, or third-party software.

    What an API typically includes

    • Defined requests and responses
    • Data structures or schemas
    • Authentication and authorization methods
    • Error codes and status handling
    • Versioning rules
    • Documentation for developers or integrators

    Common implementation styles include REST APIs, SOAP APIs, GraphQL APIs, and event or message-based interfaces. In industrial settings, APIs may also be used alongside protocols and standards that are more specific to equipment or OT environments.

    Common confusion

    API vs integration: An API is a mechanism that can enable integration, but an integration usually includes broader workflow and data-handling logic.

    API vs EDI: EDI is a structured document exchange approach often used in supply chains. APIs are generally more flexible and interactive, but they serve a different technical pattern.

    API vs protocol: A protocol defines communication rules at a technical level. An API defines how software should request or exchange specific application data or functions. The two can overlap, but they are not identical.

    API vs connector: A connector is usually a packaged integration component built on top of one or more APIs.

    Boundary notes

    In some contexts, API can also refer more broadly to a software library interface used by developers inside the same application environment. In enterprise and manufacturing systems, however, it most often means a web or service interface used to connect separate systems.

  • Competitive Differentiation

    Competitive differentiation commonly refers to the distinct and defensible way an organization positions its products, services, operations, or capabilities so that customers can clearly tell it apart from competitors.

    Core meaning

    In industrial and manufacturing contexts, competitive differentiation is the specific combination of characteristics that make one supplier, plant, or solution meaningfully different from another in the eyes of customers, regulators, or internal stakeholders. It is not just being “better” in general, but being recognizably different in ways that matter to a defined market or use case.

    Examples of competitive differentiation in manufacturing and regulated operations can include:

    • Proven ability to operate reliably under strict regulatory requirements or industry standards
    • Deep integration between MES, ERP, quality, and OT systems that enables faster, more accurate data flows
    • Consistent, documented quality performance with traceable, audit-ready records
    • Specialized process capabilities, materials expertise, or environmental controls that few competitors provide
    • Shorter and more predictable lead times for complex, engineered-to-order products

    Operational perspective

    Operationally, competitive differentiation shows up in how a manufacturer designs and runs its systems and processes, such as:

    • How digital workflows, MES, and quality systems are configured to support repeatable compliance
    • How equipment, data collection, and analytics are used to maintain stable quality or high OEE
    • How documentation, change control, and traceability are handled across the product lifecycle
    • How quickly and accurately operations respond to design changes, nonconformances, or supply disruptions

    Competitive differentiation is typically intentional and supported by organizational choices in technology, training, governance, and supplier relationships. It should be sustainable enough that it is not easily copied by competitors.

    What it includes and excludes

    Competitive differentiation includes:

    • Unique or rare capabilities that are verifiable, such as certified process know-how, specialized equipment, or integrated data environments
    • Recognizable performance characteristics, such as reliability, consistency, or responsiveness backed by data
    • Documented ways of working, such as robust change control or validation practices, that are embedded into day-to-day operations

    It does not necessarily include:

    • Temporary advantages that disappear quickly, such as short-lived price discounts
    • Vague claims of quality or innovation that cannot be demonstrated or audited
    • Features customers do not value in the specific regulated or industrial context

    Common confusion

    Competitive advantage vs. competitive differentiation: The terms are often used together. Competitive advantage commonly refers to the overall strength that allows an organization to perform better than competitors, while competitive differentiation is the specific way the organization stands out. Differentiation is about being distinct; advantage is about outcomes such as margin, share, or resilience.

    Unique selling proposition (USP): A USP is typically a concise marketing statement about what makes an offering unique. Competitive differentiation is broader and covers operational, technical, and compliance dimensions, not just messaging.

    Use in regulated and manufacturing environments

    In regulated manufacturing, competitive differentiation often centers on:

    • How reliably an organization can demonstrate compliance through records, data integrity, and traceability
    • How well it integrates OT, IT, MES, and quality systems to support audits, investigations, and continuous improvement
    • How effectively it manages risk, change control, and knowledge transfer across products and sites

    When evaluating or designing systems in these environments, organizations may explicitly ask whether a given capability is merely required for compliance or whether it also contributes to competitive differentiation in their target markets.