Connect981 – Content Dev

RSC Colour: Primary Blue

  • Pilot phase

    A pilot phase is a limited, controlled trial period used to test a new process, system, product change, or operating method before broader rollout. In manufacturing and regulated operations, it commonly refers to a planned introduction in a narrow scope such as one line, one site, one product family, or a small user group.

    The purpose of a pilot phase is to observe how something performs under real operating conditions while containing impact, cost, and disruption. It is not the same as full production deployment, and it is not just a lab test or a software sandbox. A pilot typically uses actual workflows, users, and operational data, but within defined boundaries.

    What it usually includes

    • A defined scope, such as a single workcell, shift, supplier, or department

    • Specific objectives and success criteria

    • Monitoring of performance, usability, data quality, and process fit

    • Documentation of issues, deviations, and change requests

    • A decision point on whether to expand, revise, pause, or stop the rollout

    How it appears in operations

    In practice, a pilot phase may be used for MES deployment, digital work instructions, new inspection workflows, ERP-MES integration changes, automation projects, traceability enhancements, or revised standard work. For example, a plant may pilot electronic batch or routing records on one production line before extending them across the facility.

    In regulated environments, the pilot phase is often managed with tighter change control, documented scope limits, and closer review of evidence generated during the trial. The term itself does not imply approval, validation, or permanent release. Those outcomes depend on the organization’s own processes and requirements.

    Common confusion

    Pilot phase is often confused with proof of concept, prototype, and beta test.

    • A proof of concept is usually earlier and narrower, focused on whether an idea can work at all.

    • A prototype is an early model or draft version, often not used in live operations.

    • A beta test is more common in software and often emphasizes user feedback before general release.

    • A pilot phase usually sits closer to real operations and is meant to test readiness for scaled use.

    What it does not mean

    A pilot phase does not automatically mean a process is production-ready, compliant, validated, or standardized across the organization. It also does not require that every feature or workflow be final. Its main role is to reduce uncertainty before a larger commitment is made.

  • raw data

    Raw data commonly refers to unprocessed values captured directly from a source, such as sensors, machines, operator inputs, or IT/OT systems, before those values are cleaned, transformed, aggregated, or interpreted.

    What raw data includes

    In industrial and manufacturing environments, raw data typically includes:

    • Time-stamped sensor readings (for example, temperature, pressure, speed)
    • Machine status codes and event logs from PLCs, SCADA, or MES
    • Unaggregated production counts, scrap counts, and cycle times
    • Operator entries such as checklists, comments, or manual measurements
    • Transaction-level records from MES, ERP, LIMS, or quality systems

    Raw data is usually stored in historians, databases, log files, or message streams before any significant business logic is applied.

    What raw data does not include

    Raw data does not include values that have been substantially processed or interpreted, such as:

    • Indicators that combine multiple raw data points into a single derived metric
    • Key performance indicators (KPIs) such as OEE, on-time delivery, or defect rate
    • Aggregated reports (for example, hourly, shift, daily summaries)
    • Statistical calculations like averages, control limits, or capability indices

    Once rules, calculations, or contextual enrichment are applied, the result is no longer considered raw data, even if the original values are retained.

    Operational role in manufacturing systems

    In OT and IT environments, raw data is the foundation for monitoring, analysis, and compliance activities. It is:

    • The input to indicators and KPIs used in performance dashboards and reports
    • The evidence base for traceability, genealogy, and deviation investigations
    • The feedstock for advanced analytics, such as predictive maintenance models
    • A key element of data integrity and audit trails in regulated operations

    Effective governance often distinguishes raw data from transformed data so that users understand which values are directly measured and which are calculated or modeled.

    Relation to ISO 22400 concepts

    In the context of ISO 22400, raw data corresponds to basic measurements captured from equipment and systems. These measurements can then be transformed into indicators by adding calculations or context, and a subset of those indicators may be designated as KPIs for operational or business decision-making. The standard emphasizes structural distinctions but does not, by itself, guarantee how any site defines or governs its raw data.

    Common confusion

    • Raw data vs. indicators: Indicators typically aggregate or calculate values from raw data and may include business rules or contextual information, while raw data remains as-captured.
    • Raw data vs. logs: Logs are often collections of raw data, but a log file may also contain derived or formatted entries; individual log entries can still be raw data if they directly reflect unprocessed measurements or events.
    • Raw data vs. cleansed data: Once data has been filtered, corrected, or normalized, it is no longer strictly raw, even if it retains the same basic structure as the original measurements.

  • quality ratio

    Quality ratio commonly refers to a calculated indicator that compares a measure of conforming output to a measure of total output or potential output. It is used to express quality performance as a proportion, rate, or percentage rather than as an absolute count.

    What a quality ratio usually measures

    In industrial and regulated manufacturing environments, the term is most often used for ratios such as:

    • Good units / total units (e.g., non-defective parts divided by all produced parts)
    • Accepted lots / total lots (e.g., lots that pass inspection divided by all lots inspected)
    • Conforming time / total production time (e.g., time producing in-spec product divided by total run time)
    • In-spec measurements / total measurements (e.g., test results within tolerance divided by all tests performed)

    These ratios can be expressed as decimals (0 to 1), percentages (0% to 100%), or indices, depending on how they are used in reports and dashboards.

    Role in metrics, indicators, and KPIs

    Within performance frameworks such as ISO 22400, a quality ratio is typically treated as an indicator or a derived metric rather than raw data. It is calculated from underlying measurements such as unit counts, defect counts, test results, or inspection decisions. Depending on local governance, a specific quality ratio may be designated as a key performance indicator (KPI) if it is critical to business or regulatory objectives.

    How quality ratio appears in operations and systems

    In practice, quality ratios may be:

    • Calculated in MES, LIMS, SPC, or quality management systems based on production and inspection data
    • Included in OEE or similar performance dashboards as the “quality” or “yield” component
    • Used in shift, batch, or lot summaries to quantify the share of conforming vs nonconforming output
    • Aggregated by product, line, plant, or supplier for trend analysis and reporting

    The exact definition and formula of a quality ratio should be documented so that users understand what is in the numerator, what is in the denominator, how rework or re-tests are treated, and what time or scope filters apply.

    What quality ratio is not

    • It is not a specific, single standard formula. Different organizations or standards may define different quality ratios for their purposes.
    • It is not the same as cost of poor quality (COPQ), although a quality ratio may be one input to COPQ calculations.
    • It is not a qualitative assessment or narrative description of quality; it is a numeric, computed metric.

    Common confusion

    • Quality ratio vs yield: In many plants, “yield” and “quality ratio” are used interchangeably when referring to good output divided by total output. In other contexts, yield may include or exclude specific categories (e.g., reworkable units), while quality ratio may follow a different local definition.
    • Quality ratio vs defect rate: Defect rate typically measures defects or defective units divided by total units, while a quality ratio often measures the complementary side (good units divided by total units). Both are ratios but focus on different perspectives of the same data.

    Link to the ISO 22400 context

    In the context of ISO 22400 and similar performance standards, a quality ratio is an example of a derived indicator: it is calculated from primary measurements (such as unit counts, test results, and inspection outcomes) and used as part of a broader performance model. The standard provides structure for such indicators but does not define a single universal “quality ratio” formula for all organizations.

  • 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 is the role of design of experiments (DoE) in AI-driven process window optimization?

    DoE provides the disciplined experimental structure that AI needs to optimize a process window without relying only on noisy historical data or trial-and-error changes. In practice, DoE helps determine which factors matter, how factors interact, where the practical operating limits are, and which combinations produce acceptable performance across multiple responses such as yield, cycle time, scrap, and critical quality characteristics.

    AI and DoE are complementary, not interchangeable.

    In practice, this connects to lean and process improvement when teams need to turn the answer into repeatable execution habits.

    • DoE is used to generate informative data on purpose.

    • AI and statistical models are used to learn from that data, plus available historical data, to predict outcomes and recommend settings.

    • Process window optimization then uses those models to identify a robust operating region rather than a single best point that may fail under normal variation.

    That distinction matters because many plants do not have historical data that is clean, complete, or well-labeled enough for direct AI optimization. Data may be fragmented across MES, ERP, PLM, historians, spreadsheets, and lab systems. Measurements may also reflect changing tooling, operator methods, maintenance state, incoming material variation, or recipe revisions. In that situation, DoE is often the fastest way to create data with known intent, controlled factor changes, and defensible traceability.

    What DoE contributes to AI-driven optimization

    • Efficient data generation: It reduces the number of runs needed compared with changing one variable at a time.

    • Interaction discovery: It exposes factor interactions that simpler approaches miss, which is often where process instability actually comes from.

    • Boundary detection: It helps map where quality, throughput, or equipment constraints begin to break down.

    • Model training support: It creates balanced, informative data that improves model fitting and reduces bias from historical operating habits.

    • Robustness analysis: It supports optimization for tolerance to common variation, not just peak performance under ideal conditions.

    • Evidence for change control: It creates a more reviewable basis for recipe, setpoint, or routing changes than ad hoc tuning.

    What AI adds beyond classical DoE

    AI can help when the process is nonlinear, multivariate, and affected by hidden patterns across equipment, materials, or time. It can combine DoE results with broader production history to estimate more realistic operating windows, detect drift, and prioritize new experiments. In some cases, active learning or Bayesian optimization can propose the next most informative experiment instead of running a fixed design up front.

    But this only works if the underlying data is trustworthy enough. If sensor calibration is weak, timestamps do not align, genealogy is incomplete, or outcome labels are inconsistent, AI can amplify error rather than reduce it. A polished model on poor data is still poor evidence.

    Limits and tradeoffs

    DoE is not optional in every case, but it is often necessary when you need credible, explainable process learning in a regulated manufacturing context. That said, it has constraints:

    • Production disruption: Experiments consume machine time, material, engineering attention, and sometimes increase scrap risk.

    • Qualification burden: Changes to validated processes, recipes, inspection plans, or critical parameters may trigger formal review, revalidation, or additional evidence requirements.

    • Measurement dependency: Weak MSA or unstable test methods can invalidate the results.

    • Transfer risk: A model built on one machine, tool state, material lot profile, or facility may not generalize cleanly to another.

    • Objective conflicts: The best settings for yield may not be best for throughput, energy use, or downstream rework.

    • Human factors: If operators cannot execute the recommended settings consistently, the theoretical optimum may not be the operational optimum.

    So the role of DoE is not simply to feed data into AI. It is to create reliable learning conditions, expose cause-and-effect relationships, and define the safe space within which AI recommendations can be evaluated.

    How this usually fits into a brownfield environment

    In most plants, AI-driven process window optimization has to coexist with existing MES, ERP, PLM, QMS, historians, SCADA, and lab systems. Full replacement is rarely the practical starting point. In regulated, long-lifecycle environments, replacement strategies often fail because qualification effort is high, downtime is constrained, integrations are brittle, and traceability and change control obligations do not disappear just because a new platform is introduced.

    A more realistic approach is incremental:

    1. Use DoE to generate a controlled baseline on a targeted process.

    2. Link experiment plans, materials, machine states, and outcomes back to existing record systems.

    3. Train and compare models using both designed and historical data.

    4. Validate recommendations offline before limited production use.

    5. Deploy setpoint guidance or decision support first, not fully autonomous control, unless the control strategy is separately justified and governed.

    This approach is slower than a greenfield AI narrative, but it is usually more survivable operationally.

    Bottom line

    DoE is the structured foundation that makes AI-driven process window optimization more credible, explainable, and transferable. AI can accelerate learning and improve multivariable optimization, but it does not remove the need for designed experimentation, measurement discipline, validation, and controlled implementation. If those prerequisites are weak, neither DoE nor AI will produce a reliable process window.