Connect981 – Content Dev

FAQ Category: cross-plant standardization

  • How does an execution layer reduce risk during safety-critical engineering changes?

    An execution layer reduces risk during safety-critical engineering changes by tightly controlling how, when, and by whom new configurations are executed on the shop floor. It does not remove the need for robust engineering, quality, and configuration control, but it can significantly reduce the operational and human-factor risks associated with putting changes into production.

    1. Enforcing the correct revision at the point of use

    In safety-critical environments, the primary operational risk is often using the wrong revision of a design, routing, or instruction set. An execution layer can:

    In practice, this connects to work orders and digital travelers when teams need to turn the answer into repeatable execution habits.

    • Bind work orders, lots, and serial numbers to specific, approved engineering change revisions.
    • Prevent release of work if the referenced BOM, routing, or work instruction is obsolete or not yet effective.
    • Apply effective dates and configuration rules so the right version is used for each unit or batch.
    • Surface only the current, approved digital work instructions to the operator, reducing reliance on tribal knowledge or printed copies.

    The effectiveness of this depends on accurate and timely data from PLM, ERP, and QMS, and on validated interfaces that keep revision status synchronized.

    2. Controlling who can execute safety-critical steps

    Safety-critical changes often come with new skills, tools, or certifications. An execution layer supports:

    • Role and competency-based access control for specific operations and steps.
    • Enforcement that only qualified operators, inspectors, or special process staff can execute or sign off high-risk steps.
    • Electronic signoffs with user identity, timestamp, and revision context captured for each critical operation.

    This reduces the risk of unqualified personnel executing changed processes, but it requires a maintained skills matrix and integration with HR or training records, plus periodic audit of role mappings.

    3. Driving correct sequencing and interlocks

    Many failures around engineering changes occur when steps are performed out of sequence or prerequisites are skipped. An execution layer can:

    • Enforce process flow so operators cannot move to downstream steps until required checks or measurements are completed.
    • Add interlocks tied to new safety-critical steps, such as torque verification, leak tests, or functional checks introduced by the change.
    • Conditionally branch workflows based on configuration, serial, or test results, avoiding manual interpretation of complex change bulletins.

    This reduces reliance on memory and informal workarounds but depends on accurate modeling of routes and decision logic and on careful change control when flows are updated.

    4. Embedding validation, checks, and data capture

    When engineering changes alter fit, function, or safety margins, data collection and verification must follow the updated requirements. An execution layer can:

    • Require capture of new parameters, measurement ranges, and evidence (e.g., photos, tool IDs, gage IDs) aligned with the change.
    • Validate entries against specification limits in real time, preventing continuation if values are out of tolerance for the new design.
    • Ensure calibration and tool control rules are followed when new tools or fixtures are introduced.

    This helps avoid silent deviations but is only as strong as the underlying specification data, gage management processes, and the validation of the execution logic itself.

    5. Managing deviations, concessions, and controlled experiments

    Safety-critical changes often start with limited pilots, controlled builds, or conditional approvals. An execution layer supports structured risk handling by:

    • Routing specific orders or serials through special pilot flows with additional inspections or tests.
    • Linking temporary deviations, waivers, or concessions to affected work orders, and enforcing associated conditions.
    • Capturing nonconformances in context if the new design or process behaves unexpectedly, with traceability back to the underlying change.

    This reduces the risk of uncontrolled experiments on production hardware, but it requires disciplined configuration of special routes and clear sunset rules for temporary flows.

    6. Providing full traceability of what was built, how, and under which change

    When failures occur in the field, or during qualification, the ability to reconstruct exactly which revision and process were used is critical. An execution layer improves traceability by:

    • Linking each unit or batch to the specific engineering change, work instructions, tooling, and parameters used during manufacture.
    • Recording operator identities, signoffs, measurement data, and test results tied to the effective revision at that time.
    • Maintaining an auditable history of when a change went live, where it was applied, and when it was superseded.

    This does not automatically deliver compliance, but it provides the evidence needed for robust root cause analysis and formal investigations when something goes wrong.

    7. Coordinating across brownfield systems

    In most regulated plants, the execution layer must coexist with existing PLM, ERP, QMS, and sometimes legacy MES, along with paper-based work instructions. Risk reduction depends on:

    • Reliable integration with PLM for controlled release of engineering changes and status updates.
    • Clear ownership of the “source of truth” for parts, BOMs, routings, and instructions, avoiding conflicting versions across systems.
    • Well-defined cutover procedures so old and new revisions are not run in parallel without proper segregation.

    Attempting full system replacement during major engineering changes often increases risk because of validation burden, downtime, and integration complexity. A more practical approach is layering execution control on top of existing systems, then migrating specific functions over time under strict change control.

    8. Supporting staged rollout and rollback of changes

    Engineering changes can fail or have unintended side effects. An execution layer can reduce associated risk by:

    • Allowing staged rollout by line, cell, program, or facility, instead of a big-bang cutover.
    • Tracking adoption progress and issues in near real time through exception and nonconformance data.
    • Supporting controlled rollback plans when a change must be paused or reversed, with clear rules about which units are affected and how to handle them.

    This capability still relies on well-defined engineering and quality governance for go/no-go decisions and for managing partial builds or rework.

    9. Capturing operator feedback and surfacing weak signals

    Even well-modeled engineering changes can introduce subtle risks that only appear in execution. An execution layer can:

    • Provide structured channels for operators to flag unclear instructions, unsafe conditions, or unexpected behavior related to the new process.
    • Aggregate these signals with NCRs and near-miss data to help engineering and quality teams refine the change.
    • Feed into continuous improvement and formal risk assessments without relying on informal communication paths.

    This does not replace formal hazard analyses, FMEA, or safety cases, but it improves practical feedback loops around implementation.

    10. Constraints and what an execution layer cannot do

    Even with a strong execution layer, several risk areas remain outside its direct control:

    • It cannot guarantee the correctness of the engineering change itself; design and analysis quality remain separate responsibilities.
    • It does not, by itself, ensure regulatory or certification outcomes. Evidence and behavior must still meet external expectations.
    • It must be qualified and validated like any other system used in regulated, safety-critical environments.
    • If integrations with PLM or QMS are weak, out-of-date, or manually maintained, the execution layer can enforce the wrong information efficiently.

    In practice, the risk reduction comes from combining a validated execution layer with disciplined configuration management, change control, training, and continuous monitoring.

  • How do we ensure service providers follow IEC 62443-2-4 expectations?

    IEC 62443-2-4 focuses on what service providers must do to support secure industrial automation and control systems. You cannot “ensure” compliance in an absolute sense, but you can significantly increase conformance and reduce risk by making 62443-2-4 a structured part of supplier management, contracts, and technical controls.

    1. Make IEC 62443-2-4 explicit in contracts and SOWs

    Service providers rarely align with 62443-2-4 unless it is concretely required. Start by making expectations visible and binding:

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

    • Reference IEC 62443-2-4 in master service agreements and statements of work, specifying which clauses or capability levels apply to your use case.
    • Define scope: which sites, networks, systems, and environments (e.g., production, test, development) are in scope.
    • State required deliverables: security plans, hardening guides, user management procedures, incident support, and documentation that map to 62443-2-4 requirements.
    • Include right-to-audit or right-to-request-evidence clauses, within reasonable limits for confidentiality and export controls.

    Avoid vague language like “provider follows industry best practices.” Tie expectations to specific, testable outputs and behaviors.

    2. Integrate 62443-2-4 into supplier qualification

    Before the first purchase order, assess the provider’s maturity against 62443-2-4, similar to any quality or safety qualification:

    • Use a structured questionnaire mapped to 62443-2-4 requirements (e.g., account management, patching, remote access, backups, incident support).
    • Ask for existing certifications or third-party assessments only as supporting evidence, not as a guarantee of suitability.
    • Review their documented processes for secure configuration, remote access, and change control in operational technology (OT) environments.
    • Classify providers by criticality (e.g., can they impact safety, product quality, or regulatory data) and scale your depth of assessment accordingly.

    In highly regulated or safety-critical environments, you may need on-site or virtual technical reviews involving OT, IT security, and quality representatives.

    3. Define clear responsibilities and boundaries

    IEC 62443 assumes responsibility is shared between asset owners and service providers. Gaps often occur where boundaries are unclear. Clarify in writing:

    • Who owns network zoning and segmentation, firewalls, and remote access gateways.
    • Who creates, approves, and removes user accounts on OT systems and remote access tools.
    • Who applies OS and application patches, and under what approval workflow.
    • Who maintains backup and recovery procedures, and how often restore tests occur.
    • Who leads incident response for cybersecurity events affecting their scope, and how this integrates with your incident and deviation processes.

    Responsibility matrices (e.g., RACI charts) tied to 62443-2-4 control families are often the most practical way to avoid assumptions.

    4. Align with existing brownfield and validated systems

    In brownfield environments with legacy MES, DCS, PLCs, and validated systems, you cannot simply “upgrade to compliant” services without disruption. When applying 62443-2-4 expectations:

    • Identify systems where changes trigger revalidation or requalification, and require service providers to follow your change control and validation processes.
    • Prohibit unilateral provider changes to configurations, firmware, or network connections without documented change requests and impact assessments.
    • Require versioned configuration baselines and traceability for any changes they implement.
    • Favor additive protections (e.g., secure remote access gateways, jump hosts, monitoring) over wholesale replacement of legacy components, which often fails due to downtime, integration complexity, and regulatory burden.

    Where providers propose major technology changes, insist on a structured risk and impact assessment that includes qualification effort, downtime windows, and rollback plans.

    5. Control and monitor remote access

    Remote access is one of the highest-risk areas governed by 62443-2-4 and often heavily used by vendors for troubleshooting and upgrades. At minimum:

    • Use centrally managed, approved remote access solutions rather than ad hoc VPNs or vendor tools installed directly on OT assets.
    • Require strong authentication (e.g., MFA) and unique identities for each individual, not shared vendor accounts.
    • Limit access by time, system, and role; avoid persistent always-on vendor connections.
    • Monitor and log remote sessions at the network and application layer where feasible, and retain those logs per your retention policy.
    • Include remote access use in periodic reviews with the provider and in your internal cybersecurity governance.

    Where legacy constraints limit technical controls, compensate with stricter procedural controls, escorted sessions, and additional logging at adjacent layers (e.g., jump hosts or firewalls).

    6. Require and review evidence, not just policies

    To move from trust to verification, tie 62443-2-4 requirements to concrete artifacts and periodic reviews:

    • Define what evidence you expect: configuration hardening checklists, user lists, change records, incident reports, and test results for backups or failover.
    • Ask for samples of tickets and change records (appropriately redacted) that show how they handle work in regulated plants.
    • Check that their procedures are actually followed on your systems, not just documented generically.
    • Include provider-related controls and evidence in your internal audits and pre-audit readiness activities, but avoid implying that this guarantees any particular audit outcome.

    Be explicit that missing or weak evidence will affect continued use and future sourcing decisions.

    7. Integrate providers into your change control and risk management

    Service providers frequently act outside plant change processes unless you enforce alignment. To match 62443-2-4:

    • Require that all provider changes go through your formal change control, including risk assessment, testing, and approvals where applicable.
    • Mandate pre-deployment testing on non-production or representative testbeds for impactful changes (patches, firmware, major configuration shifts).
    • Ensure cyber-related risks and mitigations are recorded in your risk registers, not just in vendor documents.
    • Document rollback plans for any change that can disrupt production, quality, or safety-related controls.

    In validated or qualified environments, align provider activities with your validation documentation and release processes to preserve traceability.

    8. Use tiered oversight based on criticality

    Not every service provider needs the same rigor. Define tiers such as:

    • High criticality: Can affect safety functions, product quality, batch records, regulatory data, or core OT networks. These should have full 62443-2-4 alignment, detailed contracts, and regular reviews.
    • Medium criticality: Indirect OT impact or limited-scope remote access. Require essential controls (remote access, user management, incident reporting) and periodic spot checks.
    • Low criticality: No network access to OT, no impact on regulated data. Apply baseline corporate security and supplier expectations.

    This avoids overburdening low-risk providers while still maintaining strong control where it matters most.

    9. Plan for lifecycle, exit, and personnel changes

    IEC 62443-2-4 expectations need to hold over long equipment lifecycles and changing vendor relationships:

    • Include offboarding provisions: how accounts are removed, data returned or destroyed, and access revoked at contract end or scope change.
    • Require timely notification when their key personnel with access to your environment change roles or leave.
    • Plan for what happens if the provider discontinues a service or tool, to avoid unmanageable technical debt or stranded unsupported systems.
    • Review alignment with 62443-2-4 at agreed intervals (e.g., annually) to account for technology and threat changes.

    Lifecycle planning is especially important where providers manage components that would be costly to requalify or replace.

    10. Be explicit about limits and shared responsibility

    No combination of clauses or controls can fully guarantee that a provider will always follow IEC 62443-2-4 in practice. Factors like site-specific configurations, integration quality, and internal process maturity will strongly influence actual risk reduction. You remain responsible for:

    • Defining acceptable risk in the context of your operations and regulatory environment.
    • Maintaining network architecture, monitoring, and incident response that can detect and respond to provider missteps.
    • Ensuring internal teams do not bypass agreed processes for the sake of short-term convenience.

    Treat IEC 62443-2-4 as a shared framework: you set clear expectations, the provider demonstrates capability and evidence, and you validate and monitor that behavior over time.

  • What is the primary purpose of ISA-88?

    The primary purpose of ISA‑88 (S88) is to provide a consistent, modular model for batch control so that product recipes are clearly separated from equipment control and system implementation. It defines a common architecture, terminology, and set of models that different teams and vendors can use to design, integrate, and maintain batch processes in a predictable way.

    What ISA‑88 is trying to achieve

    At its core, ISA‑88 aims to:

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

    • Separate recipes from equipment: Make product and process logic (recipes, procedures) distinct from physical assets (units, modules, phases) so that changing a product does not always require changing control code.
    • Standardize batch models and language: Provide a shared way to describe processes, equipment, and control activities so engineering, operations, quality, and vendors can communicate without ambiguity.
    • Support modular, reusable design: Encourage unit, equipment module, and phase-based control that can be reused across products and sites, reducing custom code and integration complexity.
    • Improve lifecycle manageability: Make it easier to maintain, validate, and evolve batch systems over long equipment lifecycles by reducing tight coupling between control logic and product definitions.
    • Enable better traceability of execution: Provide a consistent structure for capturing which recipe, which equipment, and which actions were executed, in what order, to support investigations and regulatory expectations.

    What this means in regulated, brownfield environments

    In regulated and long‑lifecycle operations, ISA‑88 is primarily useful as a design and integration reference, not as a standalone solution. Its practical role is to:

    • Guide how batch control is structured in DCS/PLC/SCADA and batch execution systems, so changes to recipes and equipment can be managed with clearer impact analysis and change control.
    • Provide a backbone for integration to MES, historian, and QMS, because the standard models (procedures, unit procedures, operations, phases, units, equipment modules) give stable integration points.
    • Support validation and traceability by making the relationship between recipes, equipment behavior, and execution data more explicit and easier to document and test.

    Using ISA‑88 does not guarantee compliance, audit success, or validation outcomes. Benefits depend heavily on:

    • How consistently the ISA‑88 models are applied across legacy and newer systems.
    • The quality of integration between control systems, MES, historians, and quality systems.
    • How recipe management, change control, and configuration management are implemented on top of the standard.

    Limits and tradeoffs

    • Not a replacement strategy: Adopting ISA‑88 does not require ripping out existing DCS/PLC or MES. In fact, full replacement to “go pure S88” is rarely practical in highly regulated plants because of validation burden, downtime risk, and integration debt.
    • Interpretation varies by vendor: Different control and batch platforms implement ISA‑88 concepts differently. The standard reduces ambiguity, but it does not eliminate vendor‑specific behavior or configuration.
    • Requires discipline to realize value: Without governance around naming, modular design, and recipe/equipment separation, plants can claim “S88‑compliance” yet still end up with tightly coupled, hard‑to‑maintain systems.

    In practice, many organizations use ISA‑88 as a reference model to incrementally improve existing batch systems: cleaning up equipment models, standardizing phases, and restructuring recipes, rather than attempting a disruptive, full‑scale replacement.

  • What information must be included in an aerospace non-conformance report?

    An aerospace non-conformance report (NCR, NCMR, NCD, DR, QN, etc.) must contain enough structured information to fully identify the part, describe the defect, assess risk, and support traceable disposition and corrective action. Field names and layouts will vary by customer, site, and system, but the required content is broadly consistent.

    1. Identification and traceability

    At minimum the NCR must allow someone outside the immediate team (auditor, customer, investigator) to uniquely identify the event and link it to the affected product and records:

    In practice, this connects to non-conformance management when teams need to turn the answer into repeatable execution habits.

    • NCR identifier: unique NCR / DR number, revision, and status.
    • Date/time: when the non-conformance was detected and recorded.
    • Reporter: name/ID and organization (e.g., inspector, operator, supplier, customer).
    • Location: facility, building, line/cell, station, and operation/inspection step.
    • Customer link: customer program/aircraft/platform, contract/SOW, and any customer defect report ID if applicable.

    2. Part, configuration, and documentation data

    Aerospace non-conformance records must allow reconstruction of the exact configuration involved. Typical required fields:

    • Part identification: part number, description, dash level or variant, and configuration if applicable.
    • Serial/lot/heat/batch: serial numbers, lot numbers, heat numbers, cast numbers, or other unique identifiers for all affected units.
    • Quantity: total quantity affected, and used/scrapped/quarantined quantities.
    • Revision and configuration: drawing revision, model revision, planning revision, software/hardware revision as applicable.
    • Process routing: operation number, work order/traveler number, router/planning ID, and revision under which work was performed.
    • Referenced documents: drawing numbers, specifications, work instructions, special process instructions, and any deviation/concession already applicable.

    3. Detection details (how and when it was found)

    Auditors and customers will look for evidence that your detection and inspection system is functioning. The NCR should record:

    • Detection point: in-process inspection, final inspection, receiving, test, field/service, customer site, or supplier.
    • Detection method: visual, dimensional, NDT, functional test, software verification, torque check, leak test, etc.
    • Inspection tools/equipment: gauge or test equipment ID, calibration status reference, automated test system ID if relevant.
    • Trigger: routine inspection, sampling, SPC alarm, operator observation, customer complaint, or escape report.

    4. Detailed description of the non-conformance

    The defect description needs to be specific enough that another engineer could understand it without access to the part. Aerospace customers and standards typically expect:

    • Requirement violated: clear reference to the requirement not met, such as drawing dimension and tolerance, spec paragraph, procedure step, process limit, or software requirement ID.
    • As-found condition: factual description of what is wrong, avoiding interpretation or blame (e.g., “Ø12.000 mm feature measured Ø12.065 mm; tolerance 12.000 ±0.020 mm”).
    • Defect category and code: standardized defect type or code (e.g., dimensional, surface defect, documentation error, process escape, material non-conformance).
    • Location of defect: feature ID, station, face, hole number, zone, frame-stringer location, rib number, or coordinate system location as appropriate.
    • Extent and pattern: number of occurrences per part, which serials are affected, and whether the issue is isolated or systemic.
    • Visual/test evidence: references to photos, test results, CMM reports, NDT results, or measurement records stored elsewhere.

    5. Risk and impact assessment

    Regulated aerospace environments require a structured evaluation of impact on safety, airworthiness, performance, and compliance. The NCR should capture:

    • Application/use: where and how the part is used (primary/secondary structure, flight control, engine, cabin, ground test only, tooling).
    • Safety/airworthiness impact: preliminary assessment of potential safety impact, including whether the issue is potentially safety-critical or reportable.
    • Functional impact: potential impact on performance, reliability, maintainability, or interoperability.
    • Regulatory/contractual impact: potential effect on certification basis, customer requirements, or regulatory commitments.
    • Escape status: whether non-conforming product has shipped, been installed, or entered service, and how that was determined.

    6. Containment and immediate actions

    Containment steps must be recorded clearly for traceability and to demonstrate control of non-conforming material:

    • Quarantine details: where affected items are physically located (MRB area, quarantine cage, bond room) and how they are segregated.
    • Inventory check: scope of stock search and results (WIP, finished goods, in-transit, at supplier, at customer).
    • Production impact: whether operations were stopped, slowed, or allowed to continue under temporary controls.
    • Temporary controls: additional inspections, holds, tags, or process changes applied pending disposition.

    7. Disposition and approvals

    Formal, documented dispositions are essential in aerospace due to airworthiness and contractual requirements. Depending on your procedures and customer rules, the NCR should include:

    • Disposition type: scrap, rework to drawing, repair (non-standard), use-as-is, return to supplier, re-grade (for material), reclassify to non-flight or ground test use.
    • Repair/rework instructions: clear, approved instructions tied to engineering authority, including new drawings or sketches, process steps, and any additional inspections or tests required.
    • Authority reference: MRB authority numbers, engineering concessions/deviations, customer-approved permits, or controlled repair procedures.
    • Affected documentation: any updates or notes required on travelers, as-built records, configuration management systems, or digital models.
    • Validation requirements: additional proof tests, analysis, or inspections needed to justify the disposition and confirm conformity after action.
    • Approvals: signatures or electronic approvals for quality, MRB engineer, design authority, program/customer representative when required, and date/time stamps.

    8. Root cause and corrective / preventive action (as applicable)

    In many aerospace organizations, the non-conformance record also serves as the entry point to CAPA or problem-solving processes. At a minimum, the NCR should link to these records, and in some systems it will contain them:

    • Cause analysis reference: 5-Whys, fishbone, fault tree, or other analysis used, and where that record is stored.
    • Verified root cause(s): distinct identification of direct cause, contributing factors, systemic/root causes as determined.
    • Corrective actions: actions to prevent recurrence for the same part/location (e.g., fixture correction, updated tool, clarified work instruction).
    • Preventive/systemic actions: broader actions that prevent similar escapes elsewhere (e.g., training, changes to design rules, FMEA updates, additional poka-yoke).
    • Effectiveness checks: how and when you will verify that actions worked, metrics to monitor, and responsible owner.

    9. System integration and brownfield considerations

    In real aerospace plants, NCR information is often spread across multiple systems (MES, QMS, PLM, ERP, supplier portals). To avoid gaps and inconsistencies:

    • Ensure identifiers: the NCR should carry or reference the IDs used in upstream and downstream systems (work orders, as-built records, supplier lots, customer notifications).
    • Link, do not duplicate: where possible, link to source records (CMM reports, NDT logs, test data, concessions) rather than copying data that will get out of sync.
    • Respect long lifecycle: avoid designs where changing NCR formats requires revalidating large portions of the MES/QMS stack unless you have a strong justification and a migration plan.
    • Change control: treat NCR schema and workflow changes as controlled changes, with traceability, training, and, where relevant, revalidation.

    10. Dependencies and variability

    The exact information you must include is constrained by:

    • Customer and regulatory requirements: prime OEMs and authorities often define mandatory fields, codes, and workflows in contracts, quality clauses, or supplier manuals.
    • Internal procedures: your QMS, MRB procedures, and engineering authority processes may add requirements beyond typical industry practice.
    • System capabilities: legacy QMS/MES solutions may not support every desirable field; in those cases, you will need controlled workarounds (attachments, linked records, or upgraded systems) and careful validation.
    • Product type and risk: safety-critical and flight hardware usually demand more detailed risk, analysis, and approval data than ground equipment or test rigs.

    Because of this variability, you should treat the list above as a reference checklist, then map it to your actual forms, electronic workflows, customer requirements, and validation constraints rather than adopting it blindly.

  • Who actually owns and maintains the AS9100 standard?

    AS9100 is owned and maintained by the International Aerospace Quality Group (IAQG), not by individual certification bodies or software vendors.

    Who develops and controls AS9100?

    The core ownership and maintenance of AS9100 sit with:

    In practice, this connects to AS9100 compliance when teams need to turn the answer into repeatable execution habits.

    • IAQG (International Aerospace Quality Group): An industry group made up of major aerospace OEMs and suppliers. IAQG develops the aerospace quality management system requirements that become AS9100.
    • Sector organizations under IAQG: For example, AAQG (Americas), EAQG (Europe), and APAQG (Asia-Pacific) contribute to the content and balloting.

    IAQG controls the technical content, revisions, and official guidance documents (such as clarifications and deployment support materials).

    Who actually publishes AS9100?

    Although IAQG owns the content, the standard is formally published by accredited standards bodies under license from IAQG, most prominently:

    • SAE International (often designated as AS9100, e.g., AS9100D)
    • ASD-STAN in Europe (EN 9100)
    • Other national bodies that adopt the EN 9100 text as a national standard (e.g., BS EN 9100, DIN EN 9100).

    The content is aligned with ISO 9001 plus additional aviation, space, and defense requirements, but ISO itself does not own AS9100.

    What is the role of certification bodies?

    Accredited certification bodies (CBs):

    • Use the current AS9100 text owned by IAQG and published by SAE/ASD-STAN.
    • Are overseen by accreditation bodies that participate in the ICOP (Industry Controlled Other Party) scheme under IAQG.
    • Have no authority to change AS9100 requirements; they interpret and apply them within IAQG and accreditation rules.

    In regulated, long-lifecycle environments, relying on a single CB or software vendor for interpretation without checking IAQG and sector guidance can create divergence from the actual standard over time.

    What does this mean for manufacturers and MROs?

    For plants operating in brownfield, mixed-system environments:

    • Source of truth: The authoritative technical content is the current AS9100 edition as published by SAE/ASD-STAN, driven by IAQG. Local procedures, MES/QMS configurations, and training should trace back to this source.
    • Change impact: When IAQG issues a new revision or clarification, you are responsible for assessing the impact across legacy systems (QMS, MES, ERP, PLM) and processes. There is no automatic grandfathering of old interpretations.
    • Traceability: For audit readiness, be explicit about which AS9100 revision you are aligned to and keep controlled copies of the official text and any IAQG sector guidance used in your interpretations.

    Owning these links yourself is important because standards revisions occur on timelines that rarely match major system upgrade cycles, and full system replacement simply to track an AS9100 update is usually not practical or economical in aerospace-grade environments.

  • What are the main KPI domains defined in ISO 22400?

    ISO 22400 defines a structured set of KPI domains for manufacturing operations, mainly focused on discrete and batch production. The intent is to organize KPIs so that MES, automation, and enterprise systems can describe performance in a consistent way.

    Core KPI domains in ISO 22400

    Across the ISO 22400 series (especially ISO 22400‑2 and 22400‑5), the main KPI domains can be summarized as:

    1. Resource utilization

      KPIs that describe how effectively production resources are used, including:

      • Equipment utilization and availability (e.g., OEE-related measures)
      • Labor utilization (direct / indirect labor effectiveness, attendance)
      • Material utilization (yield, scrap, rework rates at the resource or line level)
      • Energy and utilities consumption per unit, per order, or per resource

    2. Manufacturing time and throughput

      KPIs that characterize timing and flow, for example:

      • Production lead time and order cycle time
      • Processing time vs waiting/idle time
      • Schedule adherence and execution reliability
      • Throughput rates at equipment, line, or plant level

    3. Manufacturing quality

      KPIs describing conformance and defect behavior, including:

      • Yield and first pass yield at different aggregation levels
      • Defect and nonconformity rates (internal, external, by resource or order)
      • Rework and scrap impact on capacity and flow
      • Capability-related KPIs derived from process data (where available)

    4. Cost and efficiency

      KPIs linking operational performance to economic impact, such as:

      • Cost per unit or per order (when supported by reliable cost allocation)
      • Energy cost per unit, line, or resource
      • Cost of non-quality and rework, where traceable to operations
      • Productivity measures combining labor, equipment, and output

    5. Order and delivery performance

      KPIs focused on meeting committed plans and demand, for example:

      • On-time completion / delivery against requested or confirmed dates
      • Adherence to production schedules and frozen plans
      • Reliability of start and finish times for manufacturing orders

    6. Maintenance and availability (closely related domain)

      While maintenance can be treated as its own discipline, ISO 22400 includes KPIs that link maintenance behavior to operations, such as:

      • Mean time between failures and mean time to repair
      • Planned vs unplanned downtime and their impact on availability
      • Maintenance-related losses contributing to OEE

    Dependencies and implementation constraints

    ISO 22400 specifies concepts and formulas, not a turnkey KPI system. Which domains you can realistically implement depends on:

    • Data readiness: Many KPIs need aligned order, resource, and time-event data from MES, automation, and ERP. In brownfield plants, missing or inconsistent timestamps, manual workarounds, and partial routings can limit which domains are practical.
    • Integration quality: Cross-domain KPIs (for example, combining cost, quality, and time) require stable interfaces between MES, ERP, QMS, and maintenance systems. In mixed-vendor stacks, this may be the gating factor.
    • Validation and regulated use: In regulated environments, KPIs used for decision support that may influence validated processes must be traceable, versioned, and change-controlled. Formula changes, data-source changes, or aggregation logic often require impact analysis and documentation.
    • Asset lifecycle and downtime constraints: Instrumenting legacy equipment to support time, utilization, or energy KPIs can be constrained by downtime windows and qualification burdens. This often leads to a phased rollout by resource family rather than plant-wide deployment.

    Many sites adopt ISO 22400 domains as a reference model for structuring KPIs, while keeping existing local definitions in parallel. Full replacement of existing KPI sets by the ISO definitions is uncommon in regulated, long-lifecycle environments because of historical baselines, trend continuity requirements, and the validation effort to re-baseline metrics used in quality or regulatory reporting.

  • What does 85% OEE mean?

    In practical terms, an OEE of 85% means that the equipment or line is delivering 85% of its theoretical maximum output of good product during the time you have defined as “in scope” (usually planned production time). It combines three factors:

    • Availability: How much of the planned time the asset was actually running.
    • Performance: How fast it ran compared with its defined ideal or standard rate.
    • Quality: What portion of produced units met your quality criteria (first-pass yield for that asset).

    Mathematically:

    In practice, this connects to operational visibility when teams need to turn the answer into repeatable execution habits.

    OEE = Availability × Performance × Quality

    So 85% OEE might, for example, come from:

    • Availability = 90% (10% lost to changeovers, breakdowns, etc.)
    • Performance = 95% (5% speed loss, microstops, minor jams)
    • Quality = 99% (1% scrap/rework at that step)

    0.90 × 0.95 × 0.99 ≈ 0.85 → 85% OEE.

    What 85% OEE does and does not mean

    • It does mean your current mix of downtime, speed losses, and quality losses results in a 15% gap between actual and theoretical good output for the defined period.
    • It does not mean the asset is globally “world class” or optimized. Whether 85% is strong or weak depends on product mix, process complexity, regulatory constraints, and how you define the OEE inputs.
    • It does not imply anything about regulatory compliance, audit readiness, or safety performance.

    Why the definition of 85% OEE is highly dependent on your setup

    The meaning and usefulness of 85% OEE are only as good as the definitions and data behind it. Common sources of variation include:

    • Scope of time: Is OEE based on 24/7 calendar time, planned production time, or some narrower window? Excluding setup, cleaning, or validation time will inflate OEE.
    • “Ideal” rate: Is the performance benchmark a theoretical design rate, a validated rate, a derated rate for a specific product, or an average historical rate?
    • Quality counting rules: Are reworkable units counted as good, bad, or excluded? Are quarantined lots treated as losses at this step or later?
    • Data collection method: Manual logs, PLC counters, MES, and historian feeds can all produce different OEE values if triggers and loss categories are not aligned.

    In regulated, long-lifecycle environments, the “ideal” rate is often constrained by validation, recipe rules, or qualification limits rather than pure mechanical capacity. That means 85% OEE is relative to your validated operating window, not necessarily the original equipment specification.

    Interpreting 85% OEE in brownfield environments

    In mixed legacy stacks (MES/ERP/PLM/QMS) and multi-vendor equipment fleets, 85% OEE on one line is rarely directly comparable to 85% on another without careful normalization. Differences in:

    • How downtime reasons are coded (planned vs unplanned, changeover vs cleaning)
    • Where scrap is registered (at the machine, at test, at final inspection)
    • How batch/lot-based processes are treated versus discrete unit flows
    • What is considered in-scope time (e.g., validation runs, engineering trials)

    can shift OEE by many points. An 85% OEE from an old line using manual shift reports is not inherently better or worse than 75% OEE from a newer line with tightly integrated MES and detailed loss accounting. Often, the lower figure just reflects more accurate and granular data.

    Tradeoffs and limitations of using 85% OEE as a target

    Many organizations treat 85% OEE as a generic “world-class” target. In regulated or high-complexity environments, this can be misleading for several reasons:

    • Validation and change control: Aggressive speed increases to raise OEE can trigger revalidation, documentation updates, and extended change control, which may not be justified by the benefit.
    • Product mix and complexity: High-mix, low-volume operations with frequent changeovers, cleaning, or recipe changes may structurally cap achievable OEE without major process redesign.
    • Constraint location: Improving OEE on a non-bottleneck asset might have little impact on overall throughput but consume significant engineering and validation effort.
    • Lifecycle realities: Older, qualified equipment may be kept in service long past its design horizon. Raising OEE from 80% to 85% may demand invasive upgrades that create downtime and requalification risk.

    OEE is a useful signal for loss analysis, but it should not be treated as a guarantee of efficiency, cost performance, or compliance. The critical question is where the 15% loss behind your 85% OEE actually sits and whether reducing those specific losses is feasible within your technical, regulatory, and operational constraints.

    How to make 85% OEE actionable

    To use an 85% OEE figure for decision making:

    1. Validate the calculation method: Confirm how availability, performance, and quality are defined and where the data originates (PLC, MES, manual, mixed).
    2. Drill down to loss buckets: Break the 15% loss into downtime categories, speed losses, and specific quality modes. OEE by itself is too aggregated to drive action.
    3. Compare only like with like: Normalize by product family, routing, shift, and asset type before comparing cells, lines, or plants.
    4. Align with constraint analysis: Prioritize OEE improvements at true bottlenecks rather than across-the-board targets.
    5. Respect validation and change control: For any improvement that changes equipment capability, recipes, or data flows, factor in qualification work, documentation updates, and potential downtime.

    In short, 85% OEE means you are achieving 85% of the defined potential for good output on that asset, within your chosen definitions and data boundaries. Its real value lies in how transparently it is calculated and how well you can trace it back to specific, addressable losses.

  • How should I prioritize multiple potential AI use cases across plants?

    Start with a portfolio approach, not a technology-first one. Across multiple plants, the right priority is usually the use case that combines clear operational value with acceptable implementation risk, sufficient data quality, and a realistic path to adoption. In regulated manufacturing, a technically impressive use case can still be the wrong first choice if it depends on weak master data, unstable integrations, unvalidated workflows, or major process changes.

    A practical rule is to score each candidate use case across two dimensions: expected value and delivery feasibility. Then add a third filter for governance burden. This helps prevent teams from prioritizing ideas that look attractive in demos but stall in production.

    In practice, this connects to implementation and adoption playbooks when teams need to turn the answer into repeatable execution habits.

    What to score first

    • Business impact: Estimate measurable effect on throughput, scrap, rework, labor efficiency, planning stability, cycle time, or exception handling. Use plant-level baselines where possible.

    • Repeatability across plants: Prefer problems that recur in similar forms across sites. A use case tied to one unique line, one local expert, or one nonstandard process may not scale well.

    • Data readiness: Check whether the required data exists, is complete enough, is time-aligned, and can be trusted. Many AI programs fail here. If tags are inconsistent, events are missing, genealogy is fragmented, or key process data lives in spreadsheets, value may be delayed or reduced.

    • Workflow fit: Ask where the output will be used and by whom. If the model creates an insight but no one has an approved workflow to act on it, priority should drop.

    • Integration complexity: Score the number of systems involved, interface maturity, and downtime constraints. In brownfield environments, connecting MES, ERP, historians, QMS, CMMS, and local tools often takes longer than model development.

    • Validation and change burden: If a use case changes how product quality is determined, changes approved records, or affects controlled execution steps, it may require more formal review, testing, and change control than a decision-support use case.

    • Cybersecurity and data handling constraints: Consider technical data sensitivity, export controls, network segmentation, vendor access, and cloud restrictions. These can materially change both cost and schedule.

    • Adoption risk: Prioritize use cases where plant teams can understand, trust, and operationalize the output. If local supervisors or engineers cannot challenge or verify recommendations, usage may remain low.

    Good first-wave candidates

    The most practical early AI use cases are often advisory, narrow, and measurable. Examples can include classification of recurring quality issues, planning risk alerts, maintenance triage support, document search across controlled knowledge sources, or anomaly detection that feeds engineering review rather than automatic control.

    These are often easier to pilot because they do not require immediate closed-loop action on equipment and do not force wholesale replacement of existing systems.

    Use cases that deserve caution

    Be careful with use cases that require automated process changes, direct control decisions, or broad replacement of established workflows. Those can be valuable, but they usually carry higher integration debt, higher validation burden, and more operational risk. In regulated, long-lifecycle environments, full replacement strategies often fail because qualification effort, downtime exposure, traceability requirements, and coexistence with legacy systems are underestimated.

    No, you should not prioritize based only on which model appears most accurate in a proof of concept. Accuracy in a test set is not enough. If the deployment depends on brittle interfaces, poor timestamp alignment, unclear data ownership, or extensive retraining to handle plant-to-plant variation, the use case may not be a good portfolio priority.

    A practical prioritization method

    1. Create a common scoring model for all plants.

    2. Require each use case to document business metric, users, source systems, data owner, expected actions, and failure modes.

    3. Score each use case from 1 to 5 on impact, repeatability, data readiness, integration effort, governance burden, and adoption likelihood.

    4. Weight the scores based on your current constraints. If integration capacity is limited, increase the weight on feasibility. If executive pressure is on cost reduction, increase the weight on measurable financial impact.

    5. Separate candidates into three groups: pilot now, prepare prerequisites, and defer.

    6. For the middle group, define what must be fixed first, such as master data cleanup, event standardization, historian coverage, or interface stabilization.

    How to compare plants fairly

    Do not assume the same use case has the same readiness at every plant. One site may have clean event data and stable MES integration, while another may still rely on manual logs. Prioritization should therefore happen at two levels: enterprise-level use case value and plant-level deployability.

    A common pattern is to pilot in the plant with the best combination of process discipline, local sponsorship, and data availability, then test transferability in a second plant with less favorable conditions. That gives a better picture of scaling risk than repeating success only in highly mature sites.

    What usually changes the ranking

    The ranking often shifts once teams account for non-model work. Data engineering, interface testing, role-based access, validation evidence, training, support ownership, and exception handling can consume more effort than the AI itself. If those dependencies are not visible in the business case, the portfolio will be distorted.

    In practice, prioritize use cases that improve decisions inside existing operational systems before attempting broad autonomous workflows. Coexistence with MES, ERP, PLM, QMS, and existing reporting tools is usually the safer path. In many plants, AI adds value as a layer on top of current systems rather than as a replacement for them.

    If you want a simple test, ask three questions: Is the problem financially meaningful? Is the data usable without heroic cleanup? Can plant teams act on the output within current controlled workflows? If the answer is no to any of those, it is probably not a first-wave priority.

  • Do electronic signatures satisfy regulatory approval requirements for non-conformance dispositions?

    Electronic signatures can satisfy regulatory approval requirements for non-conformance (NCR) dispositions, but they are not automatically compliant just because they are “electronic.” Whether they are acceptable depends on the applicable regulations, your QMS procedures, and how the system is implemented, controlled, and validated.

    Key conditions for electronic signatures to be acceptable

    In regulated manufacturing environments (e.g., aerospace, defense, medical, highly regulated industrial), electronic signatures generally need to meet all of the following conditions to be treated as equivalent to handwritten signatures:

    • Identity assurance: The system reliably ties each signature to a unique individual (e.g., unique user ID, strong authentication, controlled account provisioning and deprovisioning).
    • Intent and meaning: At the time of signing, the user is clearly informed what they are approving (e.g., MRB disposition, use-as-is, repair, rework, scrap) and the signature explicitly records that intent.
    • Integrity of the record: Once the NCR and disposition are approved, the record (including signature, time, and content) cannot be altered without a controlled, auditable change process.
    • Audit trail: The system maintains a secure, time-stamped history of who did what, when, and from where, including revisions, re-approvals, and revocations.
    • Access control and segregation of duties: Only authorized roles can sign dispositions (e.g., MRB engineer, quality, customer representative, design authority), and role mappings are controlled under change management.
    • System validation: The electronic system is validated and documented as fit for purpose, with evidence that signatures behave as intended under normal and failure conditions.
    • Procedural alignment: Your QMS documentation (e.g., NCR/MRB procedures, work instructions) explicitly recognizes electronic signatures as valid for the relevant approvals.

    Regulators and customers typically care less about the technology label (“electronic”) and more about whether you can prove identity, intent, integrity, and control.

    Regulatory and standard-specific considerations

    The detailed requirements vary by sector and regulator. A few common patterns:

    • AS9100 / aerospace QMS: AS9100 focuses on documented processes, authority for dispositions, and traceability. Electronic signatures are typically acceptable if your QMS procedures define them, the system is controlled and validated, and you can produce evidence on demand (e.g., during customer or third-party audits).
    • 21 CFR Part 11 (for organizations also under FDA oversight): Part 11 specifies explicit requirements for electronic signatures and records (unique user IDs, authentication, linking of signatures to records, system validation, procedures, and training). If you claim Part 11 alignment, your e-signature implementation must meet those requirements and be documented as such.
    • Customer and airworthiness authority requirements: Some customers, primes, or authorities (e.g., EASA/FAA in certain contexts) may impose additional requirements on who can approve dispositions, how concessions/deviations are handled, and whether electronic approvals are acceptable for specific classes of non-conformance.

    In practice, acceptance is driven by documented agreements (specifications, quality clauses, supplier manuals) plus your demonstrated control of the system and process.

    How this applies to NCR and MRB dispositions

    Non-conformance dispositions (e.g., rework, repair, use-as-is, scrap, deviation/concession) are often high-risk decisions with significant compliance and safety implications. Using electronic signatures for these approvals is typically acceptable only if:

    • Your NCR/MRB procedure explicitly defines which roles must approve which dispositions, and states that electronic signatures in defined systems are equivalent to handwritten ones.
    • The system ensures that the approved disposition is locked to the specific configuration and context of the NCR (part number, serial/lot, routing, revision, defect description).
    • Any change to the disposition or related work instructions triggers re-approval by the appropriate signatories, with a clear audit trail.
    • Where customer or authority sign-off is required (e.g., concessions on flight-critical hardware), their acceptance of your electronic process is documented.

    If these conditions are not met, auditors may conclude that signatures do not meet your own QMS requirements or external expectations, even if the technology itself could be capable.

    Brownfield and coexistence realities

    In most plants, NCRs and MRB decisions span multiple systems:

    • An MES or NCR module may capture the defect and internal approvals.
    • ERP may handle cost and inventory impact.
    • A PLM or QMS may maintain formal dispositions, deviations, or concessions.
    • Customer portals or shared tools may store customer approvals.

    Because of this, there is rarely a single source of truth with a single signature. To treat electronic signatures as satisfying regulatory approval requirements across this landscape, you generally need:

    • Clear system of record: An explicit decision about which system is the authoritative record for NCR dispositions and signatures.
    • Controlled interfaces: Integration that prevents silent mismatches between systems (e.g., disposition updated in MES but not in QMS) and preserves the provenance of signatures.
    • Change control: Any configuration change to user roles, routing rules, or e-signature behavior is managed under change control and, where required, re-validation.
    • Fallback and continuity: Defined behavior for outages or manual workarounds (e.g., temporary paper approvals) and how those are reconciled back into electronic records.

    Full replacement of legacy NCR/MRB tools purely to standardize signatures often fails in aerospace-grade environments due to validation cost, downtime risk, integration complexity, and the need to maintain long-term traceability to historical records. Layered or federated approaches, with clearly defined systems of record and traceable links, are more common.

    Common failure modes to avoid

    Electronic signatures for dispositions often fall short of regulatory or customer expectations when:

    • Users share credentials, making identity non-credible.
    • The system auto-logins operators or reuses cached sessions without re-authentication at sign-off.
    • Signatures are “rubber stamps” with no clear statement of what is being approved.
    • Disposition logic changes (e.g., routing rules, approval chains) are made without documented impact assessment or re-validation.
    • Printed copies are treated as primary records, but printed output omits key signature data (e.g., time, approver role, revision).
    • Customer or regulator expectations for physical signatures on specific classes of non-conformance are not captured in procedures and therefore not met.

    Each of these weakens the argument that your electronic signatures are equivalent to traditional approvals.

    Practical steps to establish acceptability

    If you intend electronic signatures to satisfy regulatory approval requirements for NCR dispositions, consider:

    1. Map requirements: Identify applicable regulations, customer requirements, and internal QMS clauses that touch approvals, MRB, and electronic records.
    2. Define in procedures: Update NCR/MRB procedures and work instructions to define where and how electronic signatures are used, which systems are authoritative, and what roles are allowed to approve.
    3. Harden identity and access: Implement strong authentication, unique user IDs, and role-based access control. Prohibit shared accounts.
    4. Validate the system: Document testing that shows signatures are correctly bound to records, survive changes, and produce reliable audit trails.
    5. Engage key stakeholders: Align with quality, engineering, IT, and (where appropriate) key customers or regulatory liaisons before fully retiring wet-ink signatures in sensitive workflows.

    Only once these controls are in place and demonstrable does it make sense to rely on electronic signatures as fully satisfying regulatory approval expectations for non-conformance dispositions.