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.

  • brownfield environments

    Brownfield environments are existing industrial sites, facilities, or systems that are already built and in operation, where new equipment, automation, or software must be integrated into what is already there. In manufacturing, this typically includes legacy OT assets, established production lines, installed control systems, and supporting IT infrastructure that cannot simply be replaced.

    In contrast to greenfield projects, which start from a clean slate, brownfield work focuses on modifying, extending, or upgrading current systems while production, quality, and compliance obligations continue.

    Key characteristics in industrial and regulated settings

    • Existing assets and constraints: Legacy PLCs, DCS, SCADA, MES, and custom integrations that may have limited documentation or vendor support.
    • Continuous operations: Changes must be implemented around live production schedules and validation needs, often with tight maintenance windows.
    • Mixed technology generations: Old and new hardware, operating systems, networks, and applications must coexist securely and reliably.
    • Regulatory and quality impact: Modifications may trigger requalification, revalidation, or updates to procedures, records, and training.
    • Physical and network limitations: Existing layouts, cable routes, panels, and IP schemes restrict how new systems can be deployed.

    Operational meaning

    In practice, working in a brownfield environment affects how organizations plan and execute initiatives such as:

    • Introducing new OT security controls or segmenting existing networks.
    • Integrating new MES or historian systems with legacy controllers and databases.
    • Upgrading plant-floor equipment while maintaining validated states in regulated plants.
    • Applying supply chain and procurement controls for replacement parts and vendors when original suppliers are no longer available.

    Engineering, IT, quality, and operations teams typically need coordinated change control, impact assessment, and testing strategies that account for installed base variability and historical configurations.

    Common confusion

    • Brownfield vs. greenfield: Greenfield environments are new builds with no existing production or systems to integrate with. Brownfield involves modification of existing, running facilities.
    • Brownfield site (environmental) vs. operational brownfield: Outside industrial operations, “brownfield” can also refer to land with prior industrial use and possible contamination. In manufacturing systems and OT/IT discussions, the term more often refers to existing plants and installed systems, not environmental remediation status.

    Relation to supply chain and risk controls

    In frameworks such as NIST SP 800-53, brownfield environments influence how supply chain and cybersecurity controls are applied. For example, controls on vendor selection, component authenticity, and system integrity must be adapted to replacement parts, upgrades, and integrations into an existing installed base rather than only to new greenfield projects.

  • Autonomous decision-making

    Autonomous decision-making commonly refers to a system’s ability to evaluate inputs, apply rules or models, choose among available actions, and carry out a response without a person approving each individual decision in real time.

    In industrial and manufacturing settings, this usually applies to software, control systems, or connected equipment that can act on production, quality, maintenance, scheduling, or process data. The decision logic may be simple, such as threshold-based rules, or more complex, such as optimization or machine learning models.

    The term includes both the decision itself and the automated execution of the selected action when that execution is part of the system design. It does not mean the system operates without any human involvement at all. People still commonly define objectives, limits, escalation paths, permissions, and oversight.

    Where it appears in operations

    Autonomous decision-making can appear in workflows such as:

    • adjusting machine parameters within approved ranges based on sensor readings

    • routing work or exceptions to different queues based on business rules

    • triggering maintenance actions from condition-monitoring data

    • holding or releasing material based on predefined quality logic

    • reordering materials when stock and demand conditions meet set criteria

    In integrated environments, these decisions may span OT and IT systems, such as a control layer reacting to process conditions while MES, ERP, or quality systems record the event and resulting status changes.

    What it is not

    Autonomous decision-making is not the same as basic automation that follows a fixed sequence with no meaningful selection among alternatives. It is also not the same as decision support, where a system recommends an action but a person must approve or execute it.

    Not all autonomous decision-making uses artificial intelligence. Many industrial implementations rely on deterministic rules, setpoints, recipes, exception logic, or optimization routines.

    Common confusion

    • Automation: a broader term for automatic execution. Autonomous decision-making is a narrower case where the system chooses an action based on current conditions.

    • Decision support: provides recommendations or alerts for human review. Autonomous decision-making allows the system to act within defined boundaries.

    • Autonomy: often used more broadly to describe the overall level of independent operation of a machine or software system. Autonomous decision-making is one capability within that broader concept.

    • AI: may enable autonomous decisions, but the terms are not interchangeable.

    Manufacturing context

    In regulated or quality-sensitive operations, autonomous decision-making is commonly bounded by approved rules, traceable data, exception handling, and escalation conditions. The practical concern is usually not whether decisions are automatic, but which decisions may be delegated to systems, under what limits, and how the resulting actions are recorded.

  • What are the 7 foundational requirements for IEC 62443?

    IEC 62443 defines seven high-level security Foundational Requirements (FRs) for industrial automation and control systems (IACS). They describe what must be protected, not a single technology stack. Implementation always depends on your specific assets, vendors, network design, and regulatory and validation constraints.

    FR 1: Identification and Authentication Control

    Ensure that all users, software processes, and devices are uniquely identifiable and authenticated before they can access system resources.

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    In practice this may include:

    • Unique user accounts, role-based access, and avoiding shared logins on HMIs and engineering workstations
    • Strong password policies and, where feasible, multi-factor authentication for remote and administrative access
    • Device identity for controllers, servers, and gateways (certificates, secure keys)

    In brownfield environments, FR1 is frequently limited by legacy controllers that do not support modern identity mechanisms, shared terminals on the shop floor, and incomplete integration with corporate identity providers. Workarounds (badges, physical controls, procedural controls) must be designed and documented carefully.

    FR 2: Use Control

    Limit what authenticated users or processes are allowed to do based on their roles and responsibilities.

    Typical elements:

    • Role-based access control (RBAC) on engineering tools, HMIs, historians, and MES
    • Segregation of duties (e.g., engineering vs. operations vs. maintenance vs. IT admin)
    • Least-privilege configuration for service accounts and API integrations

    In regulated manufacturing, FR2 interacts directly with qualification and validation. Tightening roles can change system behavior and may require re-validation or documented impact assessment. Many plants implement FR2 incrementally to avoid large, disruptive requalification efforts.

    FR 3: System Integrity

    Protect system functions and data from unauthorized modification and detect attempts to tamper with them.

    Examples include:

    • Secure configuration of PLCs, drives, robots, and safety systems to prevent unauthorized logic changes
    • Code signing, firmware integrity checks, and controlled patching
    • Application whitelisting and anti-malware on servers and engineering workstations where feasible
    • Change control with traceability for configuration and logic changes

    In long-lifecycle environments, vendors may not support frequent patching or modern hardening on older operating systems. Many facilities rely on compensating controls (network segmentation, strict change control, offline backups) to fulfill the intent of FR3 without destabilizing validated systems.

    FR 4: Data Confidentiality

    Prevent unauthorized disclosure of sensitive information in transit and at rest.

    Common measures:

    • Encrypted remote access connections to OT networks
    • Secure protocols (for example, where possible using encrypted variants instead of legacy cleartext protocols)
    • Encryption and access control for engineering project files, batch records, and recipes
    • Segregation of regulated or export-controlled technical data

    In many industrial control systems, data confidentiality has historically been weaker than integrity and availability. Retrofitting encryption into legacy protocols can be difficult or impossible without gateways. Decisions usually require balancing confidentiality against performance, determinism, vendor support, and validation constraints.

    FR 5: Restricted Data Flow

    Control how data moves between zones and conduits to reduce exposure and limit the blast radius of incidents.

    This typically includes:

    • Network zoning and segmentation (e.g., separating safety, control, supervision, and business networks)
    • Firewalls, data diodes, or controlled gateways between zones
    • Strictly defined conduits for vendor remote support, historian replication, and MES/ERP integration
    • Documented and reviewed firewall rules and port/protocol lists

    In brownfield plants with many point-to-point connections and undocumented integrations, FR5 often requires gradual remediation: discovery, documentation, then staged tightening. Aggressive segmentation without deep understanding of dependencies can disrupt production or break validated data flows.

    FR 6: Timely Response to Events

    Detect security-relevant events and respond to them in a timeframe that limits impact.

    Practical elements include:

    • Logging and audit trails on key systems (controllers where supported, HMIs, engineering tools, servers, gateways)
    • Integration of OT logs into monitoring systems, with clear runbooks for triage and escalation
    • Incident response procedures tailored to production constraints and safety considerations
    • Periodic testing of response processes, including communications between OT, IT, and plant leadership

    Full SIEM integration and continuous monitoring are not always realistic for all OT assets, especially very old controllers. Many organizations start with a smaller set of critical systems and key conduits, then expand coverage as tooling, budget, and validation bandwidth allow.

    FR 7: Resource Availability

    Ensure that critical system resources remain available, even under fault or attack conditions, and that loss of availability is limited and recoverable.

    Key aspects:

    • Protection against denial-of-service (DoS) by limiting unnecessary services, connections, and broadcast traffic
    • Redundancy for critical servers, networks, and controllers where justified by risk and cost
    • Backup and restore procedures for configurations, logic, and key data, tested regularly
    • Capacity planning so added security controls do not overload controllers, networks, or gateways

    For validated and safety-critical systems, availability controls must be designed so that security failures do not create unacceptable process or safety risks. Any changes to redundancy, failover, or recovery behavior usually need formal impact assessment and, in many regulated plants, revalidation.

    How these requirements apply in mixed, long-lifecycle environments

    The seven Foundational Requirements are goals, not a fixed technology recipe. In most real plants:

    • Legacy devices may not fully support all FRs, so you rely on compensating controls and documented risk acceptance.
    • Integration with existing MES, ERP, PLM, and QMS stacks often constrains how far you can push identity, encryption, and segmentation without breaking validated workflows.
    • Large, all-at-once replacement projects to “become IEC 62443 compliant” typically fail due to downtime risk, qualification and validation burden, and integration complexity across vendors.

    Effective use of IEC 62443 usually means:

    • Mapping the FRs to your actual zones, conduits, and assets.
    • Prioritizing high-consequence areas and modernizable components first.
    • Coordinating with change control, validation, and production scheduling so improvements are sustainable and auditable.

    The standard provides a structured way to reason about security posture. The specific controls, technologies, and timelines are highly plant-specific and should be aligned with your risk appetite, regulatory environment, and operational realities.

  • Can automation help with NIST 800-53 continuous monitoring?

    Yes, automation can significantly support NIST 800-53 continuous monitoring, but only for well-defined portions of the process. It cannot by itself achieve compliance or eliminate the need for governance, risk assessment, human review, and disciplined change control. In industrial and regulated environments, automation is most useful for structured data collection, evidence management, and repeatable checks.

    Where automation actually helps

    In a brownfield industrial environment with mixed OT/IT, automation is typically effective in these areas:

    In practice, this connects to industrial security evidence when teams need to turn the answer into repeatable execution habits.

    • Asset discovery and status tracking: Periodic or near real-time discovery of servers, workstations, network devices, and some OT assets, feeding configuration management and inventory required by multiple NIST 800-53 controls.
    • Configuration and baseline checks: Automated comparison of device configurations, group policies, firewall rules, and key system parameters against approved baselines, then flagging drift for review.
    • Patch and vulnerability status: Scanning IT assets (and some OT assets where safe) for missing patches and vulnerabilities, generating prioritized lists and trend reports aligned to risk assessments.
    • Log collection and correlation: Centralizing logs from servers, network gear, security tools, and where possible industrial control systems, then automating correlation rules for known indicators and policy violations.
    • User access monitoring: Automated reporting on account changes, privileged access use, stale accounts, and multi-factor authentication coverage, with alerts on policy violations.
    • Evidence capture and retention: Automatically attaching logs, screenshots, configuration exports, and scan results to specific controls or policies in a repository to support audits and internal reviews.
    • Dashboarding and reporting: Generating periodic control health dashboards and exceptions lists, so that human reviewers can focus on interpretation and decisions rather than manual data collection.

    What automation cannot reliably do

    Several parts of NIST 800-53 continuous monitoring do not lend themselves to full automation, particularly in regulated manufacturing:

    • Risk acceptance and prioritization: Deciding which vulnerabilities or control gaps to accept, defer, or fix requires business, safety, and regulatory judgment.
    • Control design and tailoring: Selecting, tailoring, and scoping controls for OT and safety-critical systems is a design activity, not a monitoring task.
    • Evaluating process effectiveness: Determining whether an incident response, change control, or supplier management process is actually effective needs qualitative review, not just metrics.
    • Interpreting OT-specific constraints: Automated tools typically lack context on qualification, validation, and production constraints that drive why certain patches or architectural changes cannot be applied quickly.
    • Compliance judgments: Automation can provide evidence and metrics, but it cannot make defensible statements about compliance status on its own.

    Key dependencies and constraints in industrial environments

    The usefulness of automation for NIST 800-53 continuous monitoring depends heavily on your existing landscape and process maturity:

    • System diversity and age: Legacy PLCs, DCSs, and older HMIs may not support modern agents, APIs, or secure logging. Passive monitoring, network-based discovery, and selective integration are often the only viable options.
    • Integration quality: Automated monitoring tools must coexist with MES, ERP, historian, and QMS systems. Partial integration is common. Gaps in interfaces, identity management, or data models will limit what can be automated.
    • Downtime and validation constraints: Deploying agents, updating security tooling, or enabling new logging on production systems may trigger requalification or validation and cannot always be done on the vendor’s schedule. This slows rollout and sometimes forces lighter-touch approaches.
    • Data quality and normalization: Automation is only as good as the asset inventory, network diagrams, and configuration baselines it draws from. Incomplete or stale data will produce misleading dashboards and alerts.
    • Change control: Any automated change or remediation must go through established change control, with documented testing and rollback plans, especially in validated and safety-critical environments.

    How automation maps to NIST 800-53 continuous monitoring activities

    NIST 800-53 and associated guidance describe a continuous monitoring strategy built around defined metrics, event-driven updates, and periodic assessments. Automation can support several of those steps:

    • Defining key parameters and metrics: Once you decide what to measure (e.g., patch latency, number of unapproved configurations, account anomalies), automation can collect the raw data and compute metrics.
    • Ongoing security and configuration checks: Automated scans and configuration audits provide near real-time or scheduled checks of selected controls, especially technical access control, configuration management, and audit logging controls.
    • Event-driven updates: Triggers such as new high-severity vulnerabilities, significant configuration changes, or security events can initiate automated workflows that notify control owners and collect additional evidence.
    • Evidence packaging for assessments: Automation can pre-assemble evidence for periodic control assessments, reducing manual document hunting and screen captures.

    However, defining the monitoring strategy, selecting metrics, approving thresholds, and interpreting outcomes remain human responsibilities.

    Tradeoffs and typical failure modes

    Introducing automation into NIST 800-53 continuous monitoring in regulated manufacturing comes with predictable tradeoffs and risks:

    • Too much scope, not enough depth: Attempting to automate monitoring for every control at once often leads to shallow coverage and unreliable alerts. It is usually more effective to prioritize a subset of high-impact controls.
    • Alert fatigue: Poorly tuned tools generate noise that is ignored, effectively degrading monitoring. Thresholds and rules must be iteratively tuned to the actual environment.
    • Unvalidated changes to production systems: Automated remediation or configuration pushes can unintentionally impact production or validated states if not strictly controlled and tested.
    • Overreliance on IT-centric tools for OT: Tools built for corporate IT may misinterpret OT traffic or lack awareness of process-critical dependencies. Passive, read-only deployments are often the safest starting point for OT networks.
    • Assuming automation equals compliance: Dashboards showing “green” metrics do not replace formal risk assessments, documented justifications, or independent reviews required in many regulated contexts.

    Practical approach to adopting automation for continuous monitoring

    A pragmatic approach for industrial organizations is incremental and risk-based:

    1. Start from existing inventories and controls: Use current asset lists, network diagrams, and control matrices as the foundation. Identify where manual monitoring is most fragile or labor-intensive.
    2. Select a small set of high-value use cases: Common early wins include automated asset discovery on IT/DMZ segments, centralized logging for key servers and firewalls, and basic configuration drift detection for domain controllers and jump hosts.
    3. Separate OT and IT strategies: For core OT networks, consider passive monitoring and vendor-supported solutions, and avoid intrusive scanning unless tested and explicitly approved.
    4. Align with change control and validation: Treat monitoring tool deployment and configuration as controlled changes, with documented testing, rollback, and impact assessment.
    5. Define owners and review cadences: Make it explicit who reviews automated outputs, how often, and how findings feed into risk registers, CAPA, or similar processes.
    6. Iterate based on actual outcomes: Use early deployments to refine rules, thresholds, and data flows before scaling to additional plants or systems.

    Why full replacement strategies rarely work

    Some organizations try to replace existing monitoring, logging, and configuration tools with a single new platform in the name of NIST alignment. In aerospace-grade and other highly regulated environments, this often fails or stalls because:

    • Qualification and validation burden: Replacing a working tool can trigger system requalification, documentation rewrites, and revalidation that outweigh potential benefits.
    • Downtime and cutover risk: Monitoring is tightly coupled with production and safety. A mismanaged cutover can disrupt operations or leave blind spots.
    • Integration complexity: Existing MES, historian, QMS, and ERP interfaces are usually tailored over years. Rebuilding these integrations for a new platform is costly and risky.
    • Traceability and change history: Long equipment lifecycles mean historical logs and evidence must remain accessible. Wholesale replacement can complicate traceability unless carefully staged.

    Layered, coexistence-focused strategies are generally safer: augment existing capabilities with targeted automation rather than tearing everything out in one step.

    Bottom line

    Automation can substantially improve the efficiency, repeatability, and coverage of NIST 800-53 continuous monitoring activities, particularly for technical controls and evidence management. Its real value depends on careful scoping, integration with existing OT/IT systems, alignment with change control and validation practices, and clear human ownership of risk decisions and compliance judgments. It should be treated as an enabler, not a guarantee of compliance.

  • How do we ensure MES data is trusted for KPI reporting?

    Start with precise KPI definitions and data ownership

    Trustworthy MES-based KPIs start with unambiguous definitions of what is being measured, how it is calculated, and which system is the source of record for each component. In regulated environments, these definitions should be documented, version-controlled, and linked to procedures or specifications, not just held in spreadsheets or slide decks. For each KPI, you need a clear data owner who is accountable for the definition, the data sources, and how exceptions are handled. Ambiguity around whether a KPI is based on order-level, operation-level, or unit-level data is a frequent root cause of “untrusted” numbers. Without this foundation, no amount of tooling or integration can reliably produce consistent, comparable KPIs across shifts, lines, and plants.

    Establish data lineage and traceability from shop floor to report

    For MES data to be trusted in KPI reporting, you need transparent data lineage: where each figure originates, which transformations were applied, and how it moved across systems. In brownfield environments, this usually involves multiple hops through historians, integration middleware, and data warehouses before reaching reporting tools, which can hide logic and create silent mismatches. Documenting and, where possible, automating lineage (including interface specs, mapping rules, and time-alignment logic) helps you explain why a reported value is what it is. In regulated settings, being able to trace a reported scrap rate back to specific orders, machines, and events is critical for both confidence and investigation. If you cannot walk a skeptical engineer from a KPI on a dashboard back to the underlying MES transactions, the KPI will not be trusted, regardless of how sophisticated the visuals are.

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    Control and validate integrations between MES and other systems

    MES rarely operates in isolation; KPIs often depend on ERP (costs, orders), PLM (BOMs), QMS (nonconformances), and historians (process parameters). Each interface is a potential point of distortion if mappings, timing, or error handling are not well controlled. To build trust, integration logic needs to be specified, version-controlled, and tested under realistic loads and failure conditions, not just happy-path scenarios. Automated checks for missing, duplicate, or stale data flows are important, as is clear behavior when an upstream system is down or partially available. In aerospace-grade and similar environments, replacing entire integration stacks just to “clean things up” usually fails due to revalidation cost and downtime risk; improving trust often means hardening and documenting existing integrations instead of wholesale change.

    Validate KPI calculations and transformations

    MES and reporting layers often embed business logic that materially changes what the raw data means: time-bucketing rules, handling of rework, exclusions for planned downtime, and thresholds for quality classifications. To ensure trust, these calculation rules need to be explicitly documented, reviewed with process owners, and validated against known test scenarios. A practical approach is to build a KPI validation pack: test datasets with expected results that can be re-run after any change to the MES, integration, or reporting logic. In regulated environments, treating KPI calculation logic like software—subject to specification, testing, and change control—helps avoid silent shifts in meaning when someone “fixes” a report. If logic lives partly in MES, partly in ETL jobs, and partly in the BI tool, you must still validate the complete path end-to-end.

    Implement reconciliation and reality checks against the physical process

    Trust ultimately depends on whether reported KPIs match the physical reality that operators and supervisors observe. Regular reconciliation between MES data and independent references—such as physical counts, weighbacks, or inventory adjustments—can reveal systemic gaps. For example, comparing MES-produced quantity and scrap records with ERP inventory movements often exposes timing differences, missing transactions, or unrecorded rework loops. Structured spot checks, where a shift’s production is manually tracked and then compared to MES and KPI outputs, are effective at identifying configuration issues or operator workarounds. When discrepancies are found, they should be logged, investigated, and resolved via a defined process, not treated as one-off anomalies.

    Manage change rigorously across long-lived systems

    In long-lifecycle manufacturing environments, MES and surrounding systems accumulate many small changes over years, each of which can subtly alter KPI behavior. Without tight change control, a minor configuration change to routing, reason codes, or statuses can break long-standing KPI definitions without anyone realizing it until discrepancies become large. To maintain trust, changes that affect data structures, status codes, or business rules must be risk-assessed for KPI impact before implementation and verified after deployment. This includes vendor upgrades, customizations, and local “quick fixes” made by plant teams under time pressure. Because full system replacement is often impractical due to qualification and validation burden, you must assume coexistence and invest in governance that spans legacy and new components, with clear rollback plans when KPI integrity is affected.

    Address behavioral and process gaps at the data entry point

    Even a well-designed MES cannot produce trustworthy KPIs if the underlying data capture processes are weak or routinely bypassed. Common issues include operators skipping scans when stations are congested, using generic reason codes to save time, or performing work outside of defined routings during unplanned events. These behaviors create systematic blind spots that later appear as “data problems” in reporting, even though the system is technically working as configured. To build trust, you need clear procedures, training, and sometimes process redesign so that using MES correctly is the path of least resistance. Periodic audits and comparisons of expected versus recorded events can highlight where reality diverges from the modeled process, enabling targeted corrections or adjustments to KPI interpretation.

    Communicate known limitations and confidence levels

    No MES deployment in a brownfield, regulated environment produces perfect data for all KPIs, especially where legacy equipment and manual steps remain. Rather than claiming completeness, it is better to document known gaps, approximations, and confidence levels for each KPI, and to indicate where manual adjustments are being made. For example, you may state that scrap data is complete for automated lines but partial for certain manual assembly cells, or that OEE excludes specific legacy machines pending integration. Making these limitations explicit builds credibility and guides decisions about where KPIs are suitable for external reporting versus internal trend monitoring. Over time, incremental improvements can reduce the gaps, but maintaining this transparency is essential to keeping leadership and regulators from over-interpreting numbers beyond what the underlying data can support.

  • What MES data do I need before starting AI projects in aerospace?

    You do not need a perfect MES to start AI projects in aerospace. You do need data that is trustworthy enough for a narrow, well-defined problem and traceable enough that engineering, quality, and operations can review how the output was produced.

    In practice, the best starting point is not “all MES data.” It is the smallest data set that supports one operational question, such as predicting rework risk on a process step, identifying likely bottlenecks, or prioritizing quality review queues.

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

    Minimum MES data foundation

    For most aerospace manufacturing use cases, the minimum useful MES data set includes:

    • Work order and routing history
      Operation sequence, work center, planned versus actual step completion, hold events, rework loops, and dispatch status.

    • Part, serial, and lot traceability
      Part number, revision, serial number or lot, parent-child relationships where applicable, and material or component consumption records.

    • Timestamps with consistent event meaning
      Start, stop, queue, move, hold, release, inspection complete, and close timestamps. If timestamp semantics vary by area or by shift, AI outputs will be difficult to trust.

    • Quality outcomes
      Inspection results, pass-fail dispositions, defect codes, NCR links, rework records, scrap events, and disposition timing.

    • Operator and resource context
      Work center, machine or asset identifier, shift, certification or role if allowed by policy, and major tooling context. This matters when trying to separate product effects from resource effects.

    • Configuration and revision context
      Routing revision, work instruction revision, process plan revision, and where possible the effective configuration at the time of execution.

    • Basic master data stability
      Consistent part numbers, operation codes, defect codes, reason codes, and asset identifiers. If names and codes change without control, the model may learn noise instead of process behavior.

    What usually matters more than volume

    For aerospace, data quality and context usually matter more than raw volume. A smaller, cleaner execution history with stable identifiers and strong genealogy is more useful than a large MES extract full of missing timestamps, free-text workarounds, and uncontrolled code changes.

    You should expect problems if any of the following are true:

    • The MES event model changed over time and no one mapped old and new meanings.

    • ERP, PLM, QMS, and MES disagree on part revision, operation naming, or status definitions.

    • Rework is recorded inconsistently or outside the MES in spreadsheets, email, or disconnected QMS workflows.

    • Inspection outcomes are captured, but not linked reliably to the exact operation, configuration, or serial number.

    • Important process changes were made without clean change control metadata, making before-and-after comparisons misleading.

    Data readiness by AI use case

    The data needed depends on the use case.

    • Bottleneck and flow analysis
      You mainly need event timestamps, routing states, queue and hold reasons, and work center context.

    • Yield, scrap, or rework prediction
      You need genealogy, operation history, inspection outcomes, defect codes, rework loops, revision context, and enough historical examples of failures to train against.

    • Operator guidance or anomaly detection
      You may also need machine, sensor, or test data outside MES, plus digital work instruction usage and exception history.

    • Scheduling or dispatch recommendations
      You usually need MES plus ERP and planning context, because MES alone rarely contains all constraints, material status, outside processing dependencies, or program priorities.

    So the honest answer is that MES data alone is often necessary but not sufficient.

    What is enough to start

    A practical starting threshold is usually:

    • One clearly defined business question

    • Six to eighteen months of reasonably consistent execution history, if product and process conditions were stable enough during that period

    • Reliable identifiers linking work orders, operations, parts, serials or lots, and quality events

    • A known system of record for each critical field

    • Documented data gaps and business rules, rather than pretending the data is cleaner than it is

    That said, the required history length depends on event frequency and process stability. High-mix, low-volume programs may not produce enough repeatable examples for some supervised models. In those environments, analytics, rules, and constrained anomaly detection may be more realistic than ambitious predictive AI.

    Brownfield reality in aerospace

    In aerospace plants, MES data readiness is usually limited by coexistence issues, not just MES functionality. Many sites run mixed MES, ERP, PLM, QMS, and homegrown systems with different data models and years of integration debt. Important execution evidence may be split across digital travelers, test systems, inspection tools, and manual records.

    That is why full replacement is rarely the right prerequisite for AI. Replacing MES or surrounding systems first often fails because of qualification burden, validation cost, downtime risk, integration complexity, and the long lifecycle of equipment and regulated processes. A narrower approach is usually safer: map the data needed for one use case, establish traceable extracts, validate logic with process owners, and expand only after the outputs are reviewable and useful.

    Governance you should have before production use

    Before using AI outputs operationally, you should have:

    • Clear data lineage from source systems to features and outputs

    • Change control for mappings, code sets, and model versions

    • Review procedures for questionable recommendations or anomalies

    • Defined handling for missing, late, or corrected records

    • Validation appropriate to the intended use and system impact

    This does not guarantee acceptance or compliance outcomes, but without these controls, AI results are hard to defend in a regulated environment.

    Bottom line

    Start with MES data that can reliably answer one operational question: event history, routing context, genealogy, quality outcomes, revision context, and stable timestamps. If those links are weak, fix the data path before scaling AI. If those links are strong, you can begin with a bounded use case even in a brownfield aerospace environment.

  • Can I build AI models directly on my MES database without a data warehouse?

    Yes, you can sometimes build AI models directly on an MES database without a data warehouse. For limited, read-only, non-critical analysis, it may be technically possible.

    But as a general production approach, it is usually not the right default in regulated manufacturing environments.

    In practice, this connects to data integrity, version control and audit when teams need to turn the answer into repeatable execution habits.

    The issue is not whether it is possible. The issue is whether the MES database is the right place to source, govern, contextualize, validate, and retain the data needed for reliable models without creating operational or compliance risk.

    Why direct MES access is often a bad default

    • MES databases are optimized for execution, not analytics. Query patterns for model training and feature generation can compete with shop floor transactions, reporting jobs, and integrations. In brownfield plants, that can create performance instability at exactly the wrong time.

    • Raw MES data is rarely analytics-ready. It often contains missing context, inconsistent timestamps, event duplication, late-arriving records, code-value variations, and plant-specific workarounds. If the data model reflects years of operational exceptions, the model will learn those inconsistencies too.

    • You usually need data beyond MES. Useful manufacturing AI often depends on ERP, QMS, PLM, historian, maintenance, lab, inspection, and sometimes manual records. MES alone may not contain the full causal chain for quality, throughput, delay, or scrap outcomes.

    • Traceability and reproducibility become harder. If source records can change after transactions are corrected, backfilled, or reprocessed, you can struggle to prove which data version trained which model. That matters for change control, investigation, and revalidation.

    • Security and access boundaries get messy. Direct connections from data science tools or AI platforms into a production MES database can expand attack surface, increase privilege complexity, and blur IT and OT responsibilities.

    • Validation effort rises. In regulated settings, the more tightly the model depends on live transactional structures and brittle custom joins, the harder it is to validate behavior and manage changes safely.

    When direct MES-based modeling can be reasonable

    It can be reasonable if all of the following are true:

    • You are using a read replica, reporting replica, or export, not the primary production database.

    • The use case is narrow, such as exploratory analysis, anomaly screening, or a pilot on one line or process area.

    • The data needed is mostly contained in MES and does not require heavy cross-system reconciliation.

    • You have stable identifiers, timestamps, revision handling, and event semantics.

    • You can document data lineage, model inputs, refresh logic, and change control.

    • The model is advisory, not making autonomous release, quality, or safety decisions.

    Even then, most teams end up creating a curated analytical layer because direct use of MES data becomes hard to maintain as scope grows.

    What you need instead of a full warehouse

    A data warehouse is not the only option. If the concern is cost, time, or architecture overhead, there are middle paths:

    • Read replicas for isolated analytical workloads

    • Curated data marts for specific use cases like yield prediction or cycle time variance

    • Lakehouse patterns if you need lower-cost storage and mixed structured data

    • Feature stores or governed model input layers if multiple models will reuse the same signals

    • Historian plus MES plus QMS extracts for process-focused analytics

    The practical requirement is not a warehouse by name. It is a governed, query-safe, version-aware data layer that does not put the execution system at risk.

    Brownfield reality

    In many plants, the MES is only one piece of a mixed vendor stack with custom interfaces, manual workarounds, and long-lived equipment. That matters because AI projects often fail when teams assume the MES database is a complete and clean system of record. It usually is not.

    Full replacement of MES, ERP, PLM, or QMS just to make AI easier is often the wrong move in regulated, long lifecycle environments. Replacement programs can trigger major qualification work, validation cost, downtime risk, interface rewrites, and traceability disruption. A coexistence approach is usually more realistic: extract and govern the data you need while leaving execution systems in place.

    Practical decision rule

    If the use case is small, read-only, and non-critical, direct access to a replica of MES data may be acceptable.

    If the use case will influence production decisions at scale, combine multiple systems, or need repeatable validation and auditability, build a governed analytical layer first. That can be modest in scope, but it should exist.

    So the short answer is yes, but usually not directly against the live MES database, and usually not without some intermediate data architecture.