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.

  • Data quality

    Data quality commonly refers to how accurate, complete, consistent, timely, and reliable data is for its intended use. In industrial and regulated manufacturing environments, it describes whether data captured across OT systems, MES, ERP, PLM, QMS, and supporting tools can be trusted for production control, compliance, analytics, and decision making.

    Key characteristics of data quality

    While specific models vary, data quality in manufacturing typically considers whether data is:

    • Accurate: Correctly represents the real-world value (for example, actual torque values, lot numbers, inspection results).
    • Complete: Required fields and records are present (no missing traceability links, signatures, or inspection records).
    • Consistent: Aligned across systems and time (the same part, revision, or NC ID is represented the same way in MES, ERP, and QMS).
    • Timely: Available when needed for operations, release decisions, reporting, and audits.
    • Valid: Fits defined formats, ranges, and business rules (for example, date formats, controlled vocabularies, pass/fail codes).
    • Traceable: Can be linked back to its origin, including who created or modified it and under what conditions.

    How data quality shows up in industrial operations

    In regulated manufacturing, data quality is closely tied to execution control, quality management, and compliance. Typical touchpoints include:

    • Production records: Electronic travelers, batch records, and build histories that must be accurate and complete for each unit or lot.
    • Traceability and genealogy: Correct mapping of materials, components, process steps, tools, and operators to final assemblies.
    • Inspection and test data: Reliable measurements, test results, and dispositions for FAI, in-process checks, and final inspection.
    • Nonconformance and CAPA data: Clear, consistent defect codes, root causes, and actions that support analysis and closed-loop improvement.
    • System integration: Aligned master data and transaction data across MES, ERP, PLM, QMS, and LIMS so that no conflicting or duplicated records are created.
    • Audit evidence: Records that are complete, legible, and logically connected, making it possible to demonstrate what happened, when, and under which instructions and revisions.

    What data quality is not

    Data quality is about the condition and fitness of the data itself, not about network security or system performance.

    • It is not the same as data integrity, which often focuses on preventing unauthorized alteration and ensuring records are attributable, legible, contemporaneous, original, and accurate over time.
    • It is not a specific software product; it is a property of data that can be influenced by processes, controls, training, and tooling.
    • It is not limited to analytics. Poor data quality can affect real-time routing, releases, purchasing decisions, and maintenance planning.

    Operational drivers of data quality

    Common operational factors that influence data quality in manufacturing environments include:

    • Standardized data models and master data: Clear definitions for parts, revisions, routings, work centers, and defect codes.
    • Controlled work instructions and forms: Structured data entry, required fields, and validation rules within MES, QMS, or electronic DHR systems.
    • System interoperability: Mapped identifiers and controlled integrations between ERP, MES, PLM, and other systems to reduce manual re-entry.
    • Sensor and equipment calibration: Measurement systems analysis and calibration practices that help ensure captured values are accurate.
    • Governance and stewardship: Defined responsibilities for maintaining and reviewing critical data sets, such as part masters, BOMs, routing, and supplier records.

    Common confusion

    • Data quality vs. data integrity: Data integrity often focuses on protection, attribution, and audit trails; data quality focuses on correctness, completeness, and usability. In regulated environments, both concepts are related and sometimes discussed together but they are not interchangeable.
    • Data quality vs. data governance: Data governance describes the overall policies, roles, and processes for managing data. Data quality is one of the outcomes data governance aims to manage and monitor.

    Manufacturing-focused example

    In an aerospace plant, a data quality issue might occur if the torque values recorded on an electronic traveler are entered in the wrong units or linked to the wrong serial number. Even if the system is secure and tamper-evident, that record has poor data quality because it does not reliably represent what happened on the shop floor. Correcting this may involve changes to work instructions, field validations, and how tool data is integrated into the MES.

  • time zone

    A time zone is a region of the world that observes a uniform standard time, typically defined as an offset from Coordinated Universal Time (UTC) and sometimes adjusted by daylight saving rules. In digital systems, a time zone is usually represented as a named region (such as America/New_York or Europe/Berlin) rather than just a numeric offset, so that historical and daylight saving changes can be applied correctly.

    Use in manufacturing and industrial systems

    In manufacturing, time zones matter wherever events, production data, or documents are timestamped and compared across locations. Common areas include:

    • Manufacturing execution systems (MES) that log machine states, shifts, and production orders.
    • Enterprise resource planning (ERP) and planning systems that schedule work and deliveries across multiple sites.
    • Historian and OT data where sensor and control system events are logged in local time or UTC.
    • Quality and compliance records where exact times of manufacture, testing, and release must be traceable.

    Operationally, a time zone affects how date and time fields are:

    • Stored internally (often normalized to UTC in databases and event stores).
    • Displayed to users in local plant time for shift-handovers, reports, and dashboards.
    • Aligned across sites when calculating cross-plant KPIs, lead times, or on-time performance.

    Relation to plant calendars, shifts, and KPIs

    Time zones interact closely with plant calendars, shift definitions, and local holidays. In multi-site reporting, using different time zones without clear normalization can change which events fall inside a defined day or shift. This can distort:

    • OEE and NPT calculations if runtime and downtime windows are aligned differently by site.
    • On-time delivery metrics when order promise and completion times are recorded in different local times.
    • Audit trails if timestamps from different systems appear out of sequence after conversion.

    To avoid confusion, many systems store timestamps in UTC and apply the appropriate time zone and daylight saving rules only when presenting data to users or generating local reports.

    Common confusion

    • Time zone vs. UTC offset: A UTC offset (for example, UTC+2) is a fixed difference from UTC. A time zone is a named region whose offset can change over the year due to daylight saving or policy changes.
    • Time zone vs. plant calendar: A time zone defines civil clock time. A plant calendar defines working days, holidays, and shift structures. Both influence how time-based metrics are calculated, but they are distinct concepts and should be configured separately.
    • Local time vs. storage time: Users often see local plant time, while systems may store data in UTC. Misunderstandings arise when this conversion is not made explicit during integration or reporting.

  • Scope tagging

    Scope tagging commonly refers to applying standardized labels or metadata to a record, item, document, event, or workflow so it can be identified by its defined scope. In industrial and regulated environments, that scope may include product, process, site, line, program, customer, supplier, regulatory boundary, system boundary, or quality status.

    It is a classification method, not the scope itself. The tag indicates how something should be grouped, filtered, routed, reviewed, or reported. It does not by itself create approval, establish a formal requirement, or replace documented master data and governance rules.

    How it is used in operations and systems

    Scope tagging often appears in MES, ERP, QMS, document control, analytics, and integration workflows. Organizations use it to separate or connect information across operational boundaries, such as:

    • tagging records by plant, area, or production line
    • tagging quality events by product family or defect category
    • tagging documents by controlled process, revision context, or applicable site
    • tagging transactions or data flows that fall within export-control, customer, or program-specific boundaries
    • tagging dashboards or alerts so only relevant teams see them

    In practice, scope tagging helps determine what data is in view, what workflow applies, and which records belong in a given report, queue, or evidence set.

    What it includes and excludes

    Scope tagging usually includes predefined values, naming rules, and consistent application across systems or records. It may be manual, automated, or inherited from another system.

    It does not usually mean freeform keywords added without governance. It also does not mean a full taxonomy model, though a taxonomy may define the allowed tags. In some systems, scope tagging is implemented as attributes, labels, categories, or metadata fields.

    Common confusion

    Scope tagging is often confused with taxonomy design. A taxonomy defines the classification structure, while scope tagging is the act of applying those classifications.

    It can also be confused with access control. Tags may support access decisions, but the tag itself is not the permission model.

    Another common confusion is with traceability. Tags can help organize traceability data, but they do not replace serial, lot, batch, or genealogy records.

  • Timestamp alignment

    Timestamp alignment is the process of making timestamps from different systems, devices, applications, or data sources comparable by placing them on a consistent time basis. In industrial and manufacturing environments, this commonly refers to matching event times across machines, PLCs, historians, MES, SCADA, ERP-connected records, quality systems, or sensor data so that sequences, durations, and relationships can be interpreted correctly.

    The term includes correcting or accounting for differences such as clock drift, time zone mismatches, daylight saving handling, inconsistent timestamp formats, logging delays, and differing data collection intervals. It does not, by itself, guarantee data accuracy, event causality, or system synchronization at the network level. A system can have aligned timestamps in reporting or analytics even if the underlying devices were not perfectly synchronized in real time.

    How it appears in operations

    Timestamp alignment is commonly used when combining data from multiple sources for traceability, performance analysis, root cause investigation, and electronic records review. For example, a manufacturer may need to align machine stoppage logs, operator actions in MES, inspection results, and historian process values to understand what happened before, during, and after a deviation or downtime event.

    • Comparing machine events with operator transactions
    • Matching test or inspection records to production steps
    • Reconstructing a batch or unit timeline across systems
    • Calculating durations such as cycle time, downtime, or hold time from mixed sources

    What it includes and excludes

    Timestamp alignment commonly includes both technical normalization and analytical adjustment:

    • Normalizing timestamps to a single format or time standard
    • Converting local times to a shared reference such as UTC or plant standard time
    • Compensating for known offsets between systems
    • Resampling or interpolating time-series data so records can be compared at meaningful intervals

    It generally excludes broader master data mapping, record reconciliation, or full system integration, although those activities often interact with it.

    Common confusion

    Timestamp alignment is often confused with time synchronization. Time synchronization usually refers to keeping clocks on devices or systems in sync, often through protocols such as NTP or PTP. Timestamp alignment is broader from a data handling perspective: it may use synchronized clocks, but it can also involve correcting mismatched or delayed records after data has already been captured.

    It can also be confused with sequence alignment or event correlation. Those activities use aligned timestamps, but they focus on determining relationships among events rather than establishing a common time reference itself.

  • UTC

    UTC (Coordinated Universal Time) is the primary international time standard used to measure and synchronize time across different regions and systems. It does not observe local time zones or daylight saving rules. In industrial and manufacturing environments, UTC is commonly used for system clocks, event timestamps, and cross-site data integration so that time-based data from different plants can be compared and analyzed consistently.

    Key characteristics

    • Time standard, not a time zone: UTC is a reference time scale that remains constant worldwide. Local time zones are defined as offsets from UTC (for example, UTC+2 or UTC-5).
    • No daylight saving changes: UTC does not shift forward or backward seasonally, which avoids ambiguity and gaps in time-series data.
    • Basis for offsets: All civil time zones and many industrial scheduling and logging systems are defined using an offset from UTC.
    • System-level usage: Many OT, MES, historian, and ERP systems internally store timestamps in UTC, even if they display local time to users.

    Use in manufacturing and regulated environments

    In manufacturing operations, UTC is commonly used to:

    • Normalize event logs, alarms, batch records, and production data from multiple sites that operate in different time zones.
    • Support consistent calculation of time-based KPIs such as OEE, NPT, and on-time delivery across plants.
    • Improve traceability and auditability by providing unambiguous timestamps for quality records, electronic batch records, and equipment logs.
    • Align data integration between OT systems (for example, historians, PLC logs) and IT systems (for example, MES, ERP, LIMS) using a common time reference.

    Operational considerations

    Although systems may store data in UTC, operators usually work with local time for shifts, plant calendars, and work schedules. Practically, this often means:

    • System clocks are configured in UTC, with user interfaces converting to and from local time zones for display.
    • Shift definitions and plant calendars are defined in local time, while underlying timestamps remain in UTC for cross-site reporting.
    • Data warehouses and analytics platforms convert local timestamps to UTC to combine and compare data from different locations.

    Common confusion

    • UTC vs GMT: GMT (Greenwich Mean Time) is a historical time standard and sometimes used informally as a time zone. UTC is the modern, precise standard used in computing and industrial systems. For most operational uses in manufacturing, UTC is the relevant term.
    • UTC vs local time zone: UTC does not include a geographic or political region. A local time zone (for example, Central European Time) is defined as UTC plus or minus an offset and may include daylight saving rules.

    Link to cross-site KPI and calendar alignment

    When plants are in different time zones or follow different shift models and holidays, using UTC for underlying timestamps allows KPI calculations and reports to be normalized. Local definitions for runtime, downtime, or backlog can then be consistently aligned by converting each plant's local time data to UTC before aggregation or comparison.

  • Canonical time model

    A canonical time model is a standardized way of representing time-related data so different systems, applications, and records use the same structure and meaning. It commonly defines how timestamps, time zones, offsets, durations, intervals, and calendar references are formatted and interpreted when data moves between systems.

    In manufacturing and regulated operations, a canonical time model is used to reduce ambiguity when MES, ERP, historians, quality systems, equipment data sources, and reporting tools exchange time-based information. The goal is not to create a new clock source, but to create a common representation of time so events can be compared, sequenced, and traced reliably across systems.

    What it includes

    • Timestamp format, such as a consistent date-time pattern

    • Time zone handling, including whether times are stored in UTC, local time, or both

    • Offset rules, daylight saving treatment, and normalization conventions

    • Definitions for durations, elapsed time, shift time, and effective time windows

    • Business rules for event time, record creation time, update time, and system processing time

    What it does not mean

    A canonical time model is not the same as time synchronization itself. It does not guarantee that devices or applications are set to the same clock, and it does not replace protocols such as NTP or PTP. It also is not just a display format for dashboards. It is a data model and interpretation standard used so time values remain consistent across integrations and records.

    How it appears in operations

    Operationally, a canonical time model often appears in integration mappings, event schemas, data lake models, API contracts, historian connectors, and traceability records. For example, a machine event may be generated in local controller time, converted by an edge or middleware layer, and stored in a canonical format so MES, analytics, and quality systems all interpret the event consistently.

    This matters where sequence and timing affect production history, exception review, electronic records, downtime analysis, alarm handling, and genealogy. Common examples include aligning batch events, reconciling operator actions with equipment states, and comparing production timestamps across plants or regions.

    Common confusion

    Canonical time model is often confused with time synchronization. Time synchronization keeps clocks aligned. A canonical time model keeps time data represented consistently.

    It can also be confused with a data model more generally. A canonical data model may include many entities such as materials, orders, and equipment. A canonical time model is the part that standardizes time semantics within or across those entities.

    In analytics contexts, some teams use the term loosely to mean a standard reporting calendar. That is related, but narrower. A canonical time model usually covers machine-readable timestamps and event timing rules, not only fiscal or reporting periods.