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.

  • SCADA

    SCADA (Supervisory Control and Data Acquisition) is a control system architecture used to monitor, supervise, and control industrial processes that are geographically localized or distributed. It typically connects field devices such as sensors, actuators, programmable logic controllers (PLCs), and remote terminal units (RTUs) to centralized or distributed supervisory systems.

    SCADA systems collect real-time data from field devices, transmit that data over communication networks, display process information to operators, and send control commands back to the field. Core functions usually include data acquisition, process visualization (for example, via human-machine interfaces or graphical screens), alarm and event handling, basic control logic execution, and historical data logging.

    In the context of ISA-95 and industrial automation, SCADA is considered part of the operations and control layer that interfaces with equipment on or near the plant floor. It can integrate with manufacturing execution systems (MES) and enterprise systems as part of broader IT/OT architectures.

  • How can I let auditors drill into data without exposing everything to all users?

    Yes, but usually not by opening the same level of access to every user.

    The practical pattern is to separate who can view summary information from who can drill into underlying records, and then control drill-down by role, site, program, product, supplier, or record type. Auditors and quality personnel may need deep evidence access. Most other users do not.

    In regulated environments, that typically means combining several controls rather than relying on a single permission setting:

    • Role-based access control so users only see the functions and records appropriate to their role.
    • Record-level or attribute-level security to limit visibility by plant, work center, part family, customer program, supplier, or document class.
    • Read-only audit workspaces or reports that let auditors trace from KPI or exception to underlying transaction, document, and approval history without exposing unrelated records.
    • Evidence links back to source systems so a drill-down lands on the governed record, not a disconnected export or screenshot.
    • Full audit trails for who viewed, changed, approved, or exported records, where the platform supports it.

    If the question is whether one dashboard can safely serve operators, supervisors, executives, quality, and auditors with no additional design, the answer is usually no.

    Drill-down access is only trustworthy if the underlying data model, identity controls, and integrations are disciplined. In many plants, the top-level metric may come from a BI layer, while the detailed record lives in MES, ERP, QMS, PLM, or a document repository. If those links are weak, users can drill into stale, incomplete, or mismatched data. That is a governance problem, not just a UI problem.

    What usually works

    A controlled approach often includes:

    • Tiered visibility: broad access to approved summaries, narrower access to detailed records, and highly restricted access to sensitive fields.
    • Context-aware filtering: users can drill only into the site, line, product, customer, or quality scope they are authorized to see.
    • Predefined audit paths: for example, from a nonconformance count to the NCR, then to disposition, approvals, attachments, and linked production history.
    • Masking or redaction for commercial, export-controlled, personnel, or supplier-sensitive data where applicable.
    • Controlled exports: allow viewing when needed, but restrict bulk download or uncontrolled sharing.
    • Change-controlled report definitions: if a report supports audit or release decisions, its logic should be versioned, reviewed, and managed accordingly.

    What can go wrong

    Common failure modes are predictable:

    • Users can see a chart but cannot reach the underlying evidence, so the metric is not defensible.
    • Users can drill too far and see unrelated programs, suppliers, or plants.
    • BI permissions do not match source-system permissions.
    • Exports bypass retention, traceability, or document control practices.
    • Master data inconsistencies cause one summary metric to map to multiple underlying records, or none at all.
    • Security models become so complex that plants start sharing generic accounts or offline files to get work done.

    That last point matters in brownfield environments. If MES, ERP, QMS, PLM, and reporting tools each have different role models, identity stores, and naming conventions, drill-down security becomes brittle fast. Full replacement is rarely the clean answer in long-lifecycle regulated operations because qualification burden, validation cost, downtime risk, and integration complexity are high. In practice, most organizations improve access control by federating identity, tightening system-to-system mappings, and creating governed audit views over existing systems.

    So the short answer is: give broad access to approved summaries, and limited, traceable drill-down to governed source records based on role and scope. Do not assume dashboard access alone solves evidence access, and do not assume one security model will fit every connected system without careful integration and validation.

  • How do we decide when a KPI change needs formal approval?

    Use a simple rule: if the KPI change can alter business decisions, reported results, or traceability of how performance was measured, it should go through formal approval.

    In practice, formal approval is usually warranted when the change affects any of the following:

    • Definition or formula: changing numerator, denominator, inclusions, exclusions, weighting, or time windows.
    • Source data: switching the KPI to a different system, tag, interface, manual entry point, or derived dataset.
    • Thresholds or targets: changing control limits, escalation triggers, red/yellow/green bands, or management targets.
    • Frequency or timing: changing refresh cadence, shift cutoffs, period close logic, or when data is considered final.
    • Audience or intended use: moving a KPI from local improvement use into executive reporting, quality review, customer reporting, or audit evidence.
    • Ownership and accountability: changing who maintains the KPI, who approves exceptions, or who is measured against it.
    • Workflow impact: if alerts, CAPA triggers, staffing decisions, release decisions, or supplier actions depend on it.

    By contrast, not every change needs the same level of formality. A cosmetic dashboard update, label cleanup, or visualization improvement may be handled as a lower-risk configuration change if the underlying KPI definition, data source, and decision logic remain unchanged.

    Practical approval test

    Ask these questions:

    1. Will the value change for the same historical period after this update?
    2. Will people make different decisions because of the update?
    3. Does this KPI feed regulated records, quality reviews, customer reporting, or management review?
    4. Is the KPI used across plants, programs, or suppliers where consistency matters?
    5. Does the change touch validated logic, controlled master data, or integrated interfaces?

    If the answer is yes to any of those, formal approval is usually the safer choice.

    What formal approval should include

    Formal approval does not need to be bureaucratic, but it should be traceable. A controlled KPI change normally includes:

    • the reason for the change and expected impact
    • the old and new definition or logic
    • systems, reports, and dashboards affected
    • effective date and treatment of historical data
    • testing or reconciliation results
    • named approvers from the relevant business and system owners
    • communication and training if users interpret or act on the KPI

    Where plants are using mixed MES, ERP, QMS, historian, BI, or spreadsheet-based reporting, this matters even more. A KPI can look simple on a dashboard while depending on multiple interfaces, local workarounds, and plant-specific assumptions. In brownfield environments, changing one metric definition without coordinating downstream reports and upstream source mappings often creates competing numbers, weakens trust, and complicates audits or investigations.

    Also be careful with retrospective restatement. Recomputing historical KPIs under a new formula may improve consistency, but it can break prior management review records, trend interpretations, or evidence chains unless the restatement is explicitly documented. Some organizations keep both versions for a defined transition period for exactly that reason.

    There is no universal cutoff that works for every site. The right threshold depends on your governance maturity, how standardized KPI definitions already are, whether the metric is used for regulated or contractual reporting, and how tightly connected your reporting stack is. If your current state is fragmented, start with a risk-based classification such as low, medium, and high impact, and require formal approval for medium and high impact KPI changes.

    If you are unsure, default to approval when the change alters meaning, comparability, or evidence. The cost of modest control is usually lower than the cost of conflicting numbers, unmanaged restatement, or decisions made on a metric that no longer means what stakeholders think it means.

  • How much data is “enough” to support a robust root cause analysis?

    There is no universal threshold. “Enough” data for a robust root cause analysis means enough evidence to test the leading hypotheses, distinguish signal from noise, and rule out plausible alternatives with reasonable confidence.

    In practice, the right amount depends on five things:

    • Event frequency: Rare escapes, intermittent downtime, and sporadic defects usually require a longer history than chronic, high-volume issues.
    • Process stability: If the process changed recently through tooling, programming, staffing, routing, suppliers, or work instructions, older data may not be comparable.
    • Measurement quality: If the measurement system is weak, biased, missing timestamps, or inconsistently entered, more bad data does not improve the analysis.
    • Granularity and context: Aggregate plant-level or shift-level data is often not enough. Root cause work usually needs lot, serial, operation, machine, tool, recipe, operator, material, environmental, and rework context where available.
    • Ability to correlate sources: A robust RCA often depends on whether MES, ERP, QMS, historian, maintenance, and manual records can be aligned by time, unit, batch, or event. In brownfield environments, that is often the limiting factor, not raw volume.

    What “enough” usually looks like

    You generally have enough data when you can do all of the following:

    • Define the problem precisely, including where, when, how often, and under what conditions it occurs.
    • Compare affected versus unaffected units, runs, lots, or time periods.
    • Check whether the pattern persists across shifts, operators, machines, suppliers, or product variants.
    • Verify that the timing supports causation rather than coincidence.
    • Confirm that the suspected cause is consistent with process physics, known failure modes, or prior nonconformance history.
    • Show that alternative explanations are less likely based on evidence, not preference.
    • Trace the evidence back to controlled records and revision states.

    If you cannot separate affected from unaffected conditions, cannot trust the measurements, or cannot align records across systems, you probably do not have enough usable data even if you have a large dataset.

    What is not enough

    For most serious investigations, these are common failure modes:

    • A handful of anecdotes with no traceable records.
    • Only summary dashboards, with no unit-level or event-level history.
    • Data collected after containment changes, with no baseline from before the intervention.
    • Mixed data from multiple process revisions, tooling states, or supplier changes treated as one population.
    • Missing negatives, meaning only failed cases are reviewed and good runs are ignored.
    • Manual entries with inconsistent codes, timestamps, or reason categories.
    • Sampling plans designed for inspection acceptance, not for causal analysis.

    A robust RCA is usually weakened more by poor comparability and poor traceability than by small sample size alone.

    Practical rule of thumb

    Do not ask, “How much data do we have?” Ask, “Can we reliably test the main hypotheses?”

    That usually means collecting enough data to cover:

    • Multiple occurrences of the issue, if the event is repeatable
    • A meaningful comparison group of normal output
    • The relevant time window before, during, and after the event
    • Known stratification factors such as part family, machine, tool, supplier lot, shift, and revision
    • Evidence of recent changes that may have introduced the failure mode

    If the issue is rare or high impact, waiting for a statistically large sample may be unrealistic. In those cases, stronger process knowledge, fault-tree logic, engineering review, maintenance evidence, and controlled verification tests may matter more than historical volume. That is a constraint, not a weakness, as long as the reasoning and evidence trail are explicit.

    In regulated operations

    In regulated environments, “enough” also means the analysis is traceable and defensible. You may need to show where the data came from, which system was the system of record, what revisions were active, whether the records were complete, and what assumptions were made. If data was patched together from spreadsheets, operator logs, and legacy systems, note that plainly. That does not invalidate the RCA, but it does limit confidence and repeatability.

    It is also important not to overstate certainty. RCA often identifies the most probable cause or a set of contributing causes, not a mathematically proven single cause. Where data quality, sampling bias, or integration gaps exist, say so directly.

    System reality in brownfield plants

    Many plants already have the needed evidence scattered across MES, ERP, QMS, historians, CMMS, PLC tags, and paper or spreadsheet records. The problem is usually not total absence of data. It is inconsistent identifiers, weak timestamps, missing genealogy, uncontrolled reason codes, and limited cross-system context.

    That is why full replacement is rarely the practical answer. In long-lifecycle regulated operations, replacing core systems just to improve RCA often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve traceability and change control. Incremental improvements to data alignment, event coding, and evidence capture are usually more realistic.

    So the short answer is: enough data is the amount that lets you test and eliminate credible causes with traceable evidence. Sometimes that is a modest but clean dataset. Sometimes a large dataset is still not enough.

  • How should aerospace manufacturers design serial number formats?

    Aerospace manufacturers should design serial number formats to be unique, stable, readable, and usable across systems for the full life of the part or assembly. In most regulated environments, the right answer is not to make the serial number itself highly intelligent. Put as little embedded meaning into the format as you can defend, because business meaning changes faster than physical product lineage, and overloaded formats create traceability problems later.

    What the format should do

    A good aerospace serial number format usually does four things reliably:

    • Uniquely identifies one serialized item within the defined scope.
    • Remains unchanged for the life of that item.
    • Can be captured accurately by people and systems.
    • Works across MES, ERP, PLM, QMS, test, inspection, maintenance, and partner workflows.

    If the format fails any of those, it is usually too clever, too local, or too dependent on one application.

    Design principles that hold up in practice

    1. Separate identity from attributes.

    Do not rely on the serial number to carry revision, configuration, supplier, plant, work order, date, customer, or quality status unless there is a clear contractual or program requirement. Those are attributes that belong in controlled records, not permanently encoded into identity. Revisions change. Suppliers change. Plants change. Status changes. A serial number should not have to.

    2. Define the uniqueness scope explicitly.

    Decide whether serials must be unique by part number, by product family, by legal entity, by enterprise, or across a specific program. Enterprise-wide uniqueness is often easier long term, especially in brownfield environments where data moves between multiple systems and external partners. Reusing the same serial under different part numbers can work in some legacy models, but it increases integration and reporting ambiguity.

    3. Keep the character set conservative.

    Use uppercase alphanumeric characters and avoid symbols unless you have validated every downstream system, scanner, labeler, marking process, and export routine. Many sites also exclude easily confused characters such as O and 0, I and 1, or S and 5. That is not elegant, but it reduces transcription errors on shop floors, in depots, and in supplier paperwork.

    4. Choose a fixed or tightly bounded length.

    Variable-length serials can work, but they often break legacy interfaces, barcode templates, label layouts, and operator expectations. A fixed length or a small allowed range is usually safer. The format should also fit direct part marking, labels, laser etch constraints, and human-readable presentation rules.

    5. Design for both human use and automated capture.

    Serials are not only machine keys. Operators read them, inspectors verify them, and maintainers use them years later under poor conditions. If the format is hard to distinguish visually or easy to transpose, error rates rise. If barcode or 2D code capture is expected, validate the print, marking, and scanner conditions that actually exist on the line and in service environments.

    6. Leave room for growth.

    Do not size the sequence for the current annual volume only. Aerospace lifecycles are long, and mergers, program shifts, rate changes, and service requirements outlast initial assumptions. Running out of serial capacity forces awkward resets, prefixes, or duplicate-handling rules that undermine traceability.

    What to avoid

    Common failure modes are predictable:

    • Encoding too much meaning. A serial that tries to include product, revision, plant, year, line, and supplier usually becomes fragile.
    • Using business keys as serials. Work order numbers, sales order numbers, and batch IDs are usually poor substitutes for permanent serialized identity.
    • Allowing manual local exceptions. Plants creating their own prefixes or resets may seem manageable until enterprise reporting or customer support needs cross-site traceability.
    • Ignoring external parties. If suppliers, customers, repair stations, or MRO systems must reference the serial, their constraints matter.
    • Changing the visible format midstream without migration rules. This creates duplicate risk, broken genealogy links, and confusion in as-built and service records.

    Should the serial number include intelligence?

    Usually only a little, if any. A prefix that distinguishes a regulated product family or serialized object class may be reasonable. Beyond that, embedding intelligence tends to age badly.

    For example, date-coded serial formats look attractive because they seem informative. They also create problems when production spans year boundaries, rework shifts ship dates, acquired sites use different calendars, or old assumptions become misleading. If you need manufacture date, lot context, configuration, or routing history, store those in governed records linked to the serial.

    System and integration realities

    Serial number design is not a naming exercise. It is a cross-system data design decision.

    Before standardizing a format, test how serials are created, stored, displayed, and exchanged in:

    • ERP item master and transaction history
    • MES execution, travelers, and genealogy
    • PLM or configuration records
    • QMS nonconformance, CAPA, and inspection records
    • Test stands, calibration, and equipment interfaces
    • Warehouse, shipping, and ASN workflows
    • MRO, field service, or repair lineage records
    • Supplier portals and customer-required data submissions

    This matters because many brownfield environments have conflicting field lengths, formatting rules, leading-zero behavior, barcode standards, and uniqueness assumptions. A format that looks clean on paper may fail in one legacy interface and create manual workarounds everywhere else. Full replacement is usually unrealistic just to support a new serial scheme, especially where validation cost, downtime risk, and qualification burden are high.

    Governance matters more than syntax

    The format alone will not save traceability. You also need controlled rules for:

    • When a serial is assigned
    • Who or what system is authorized to generate it
    • Whether preallocation is allowed
    • How voided, scrapped, reworked, or replaced serials are handled
    • How duplicate detection works
    • How merges, split lots, or serialized subassemblies are represented
    • How changes are approved and validated

    In regulated operations, these rules should be under change control. If serial assignment can happen in multiple systems without a canonical source or strong synchronization, duplicate and orphaned records are common failure modes.

    A practical pattern

    A common durable pattern is:

    • A short, conservative prefix only if needed for object class or enterprise partitioning
    • A sequential or otherwise nonsemantic unique identifier
    • Optional check logic if manual entry errors are a real problem and your systems can support it

    Then keep all business meaning in linked master and transactional data. That approach is less expressive to humans, but it is usually more robust across long product lifecycles and mixed application stacks.

    Site-specific constraints

    Some serial number rules are not universal. They can be driven by customer contract terms, military or program requirements, direct part marking constraints, maintenance documentation practices, or existing installed-base conventions. If those apply, they may limit how far you can simplify or standardize. In those cases, the goal is usually controlled coexistence and mapping, not a theoretical perfect format.

    If you already have multiple legacy serial schemes in service, do not assume a clean cutover is low risk. You may need a canonical serialization policy at the enterprise level while preserving legacy serials for installed product, historical records, and customer-facing references.

    Bottom line

    Design serial number formats to preserve identity, not to carry business logic. Keep them simple, unique, durable, and validated across the systems and workflows that must use them for years or decades. The hard part is not choosing characters. The hard part is governance, integration, and change control across a brownfield environment.