Connect981 – Content Dev

Glossary Tag: process monitoring

  • OPC UA

    Core meaning

    OPC UA (Open Platform Communications Unified Architecture) is a vendor‑neutral industrial communication standard used to exchange data between devices, control systems, and higher‑level applications in a secure, structured, and interoperable way.

    It provides a common information model and communication protocol so that PLCs, SCADA, MES, historians, and other OT/IT systems can read, write, and subscribe to industrial data without relying on proprietary interfaces.

    Key characteristics

    – **Vendor‑neutral standard**: Defined by the OPC Foundation and implemented by many automation and software vendors.
    – **Unified architecture**: Combines data access, alarms/events, and historical data concepts into a single framework rather than separate specifications.
    – **Service‑oriented**: Uses a service‑based model (read, write, subscribe, browse, etc.) exposed over standardized transports (e.g., TCP, HTTPS, WebSockets).
    – **Information modeling**: Represents data as typed objects with attributes, methods, and relationships, allowing rich, self‑describing industrial data models.
    – **Security features**: Commonly includes encryption, authentication, authorization, and integrity checks, designed for use in industrial networks.

    Use in industrial and regulated environments

    In manufacturing and other regulated operations, OPC UA commonly refers to communication between:

    – Field devices and controllers (PLCs, DCS, robots) and
    – Supervisory and enterprise systems (SCADA, MES, LIMS, historians, analytics platforms).

    Typical uses include:

    – **Real‑time data access**: MES or monitoring systems reading equipment states, process values, and production counters.
    – **Event and alarm exposure**: Publishing equipment events or alarms that other systems can subscribe to.
    – **Metadata and models**: Exposing structured information such as equipment hierarchies, units of measure, or recipe parameters.

    OPC UA is often part of IT/OT integration architectures where standardized data access is required for traceability, batch records, or electronic logs, but it does not by itself ensure regulatory compliance or data integrity controls.

    Boundaries and what OPC UA is not

    – **Not a specific product**: OPC UA is a standard and protocol; actual connectivity requires an OPC UA server and one or more OPC UA clients implemented in products or custom software.
    – **Not limited to Windows or COM/DCOM**: Unlike classic OPC, OPC UA is platform‑independent and does not rely on Microsoft COM/DCOM.
    – **Not a full MES or SCADA system**: It is a communication layer that such systems may use; it does not provide scheduling, quality workflows, or visualization on its own.
    – **Not a guarantee of interoperability**: While it improves interoperability, differences in information models, profiles, and vendor implementations can still require mapping and validation.

    Common confusion and related terms

    – **OPC vs. OPC UA**: Classic OPC refers to older COM/DCOM‑based specifications (e.g., OPC DA, A&E, HDA). OPC UA is the newer, platform‑independent, service‑oriented architecture that supersedes these while covering similar functional areas.
    – **OPC UA vs. fieldbuses / industrial Ethernet protocols**: Protocols like PROFINET, EtherNet/IP, or Modbus/TCP are often used directly at the control level. OPC UA is typically used one level above (e.g., controller to SCADA/MES) or as a unifying abstraction across multiple underlying protocols.
    – **OPC UA vs. MQTT**: Both can be used to move industrial data. OPC UA includes rich information modeling and built‑in services, whereas MQTT is a lightweight publish/subscribe transport; they are sometimes combined (e.g., OPC UA over MQTT or gateways between them).

    Site context: OPC UA in alerting and MES integrations

    When integrating MES alerts with plant systems (such as Andon boards, SCADA, or centralized monitoring), OPC UA is often used as a standard interface to:

    – Expose MES event data as OPC UA nodes or events that other systems can subscribe to.
    – Read machine status, alarms, or production counters into the MES as inputs for alert logic.
    – Act as a neutral layer between legacy equipment and newer OT/IT applications.

    In such integrations, topics like ownership of the OPC UA server, change control for information models, and validation of data mappings are typically part of project planning and ongoing governance.

  • interface specification

    An interface specification is a formal document or definition that describes how two or more systems, software components, or devices interact with each other. It defines the structure, format, behavior, and constraints of the information exchanged, as well as the rules that each side must follow for the integration to work reliably.

    What an interface specification typically includes

    In industrial operations and manufacturing IT/OT environments, an interface specification commonly covers:

    • Scope and purpose: Which systems or components are connected (for example, ERP to MES, MES to SCADA, L3 to L2) and what business or operational processes the interface supports.
    • Data model: Definitions of messages, records, tags, and fields, including names, data types, units of measure, valid values, and cardinality.
    • Protocols and transport: How data moves between systems, such as REST/HTTP APIs, OPC UA, message queues, file drops, or database links.
    • Interaction patterns: Whether communication is request/response, publish/subscribe, event-driven, or batch, and the timing or frequency of exchanges.
    • Directionality and responsibilities: Which system is the source of truth for each data element, which initiates transactions, and how conflicts are handled.
    • Error handling and retries: Expected responses to failures, timeouts, invalid data, and how retries or compensating actions are performed.
    • Security and access: Authentication, authorization, encryption, and logging expectations related to the interface.
    • Versioning and change control: How changes to the interface are introduced, versioned, and validated so that connected systems remain compatible.

    Role in manufacturing and regulated environments

    In manufacturing, interface specifications commonly describe the integration boundaries defined in models such as ISA-95. They document how enterprise systems (for example ERP, PLM, LIMS, QMS) and operations systems (for example MES, SCADA, historians, equipment controllers) exchange:

    • Master data (materials, recipes, routings, specifications)
    • Production orders, schedules, and dispatch lists
    • Production results, quality records, and traceability data
    • Equipment states, alarms, and performance metrics

    In regulated or audit-sensitive environments, interface specifications are often controlled documents. They help support validation, impact assessment, change management, and troubleshooting by clearly stating what each system is expected to send, receive, and do.

    What an interface specification is not

    An interface specification is:

    • Not the implementation itself: It describes behavior and data, but does not replace the actual code, configuration, or middleware that realizes the interface.
    • Not a general system design: It focuses on the boundary between systems and how they communicate, not on all internal logic or architecture details.
    • Not a guarantee of interoperability: Systems still require correct implementation, mapping, testing, and validation against the specification.

    Common confusion

    • Interface specification vs. API documentation: API documentation usually describes a specific technical API (for example REST endpoints). An interface specification may reference one or more APIs and also capture higher-level business rules, responsibilities, and sequencing.
    • Interface specification vs. data mapping: A data mapping document focuses on how fields in one system correspond to fields in another. An interface specification is broader and includes protocol, timing, error handling, and behavior.
    • Interface specification vs. ISA-95 models: ISA-95 provides generic models and categories for information exchange between levels. An interface specification applies those concepts to a concrete implementation between specific systems.

    Use in practice

    Operationally, interface specifications are used by architects, integrators, and validation teams to design, implement, test, and maintain system integrations. They serve as a reference during:

    • Integration design and vendor selection
    • System configuration and custom development
    • Factory acceptance testing, site acceptance testing, and regression testing
    • Incident investigation and root cause analysis for interface-related issues
    • Change control and impact assessment when either connected system is upgraded

  • asset hierarchy

    Core meaning

    An **asset hierarchy** is a structured representation of physical assets and related locations, organized into levels that show how equipment, systems, and areas relate to each other in a facility or across multiple sites.

    In industrial and manufacturing environments, an asset hierarchy commonly:

    – Starts at top levels such as enterprise, site, area, and line or system
    – Breaks down into equipment, sub-equipment, and sometimes component or tag level
    – Includes logical or functional groupings (e.g., utilities system, packaging line) and physical locations (e.g., room, suite, zone)

    The hierarchy provides a consistent “map” for where assets live in the organization and how they are related.

    Use in operational and maintenance systems

    Asset hierarchies are implemented in systems such as:

    – **CMMS / EAM**: to structure equipment records, preventive maintenance plans, work orders, and spare parts associations
    – **MES and SCADA/OT systems**: to align process data, equipment states, and production contexts with specific assets or asset groups
    – **ERP**: to align cost centers, asset accounting records, and sometimes plant maintenance structures with physical assets

    In daily workflows, people use the asset hierarchy to:

    – Log and track maintenance work against the correct equipment and location
    – Analyze reliability or downtime by line, system, or component
    – Associate production events, alarms, or quality issues with specific equipment or areas
    – Control access or responsibilities (e.g., maintenance teams by area or system)

    Structure and levels

    There is no single mandatory structure, but common patterns include levels such as:

    – **Enterprise / company**
    – **Site / plant**
    – **Area / department / building**
    – **Line / system / unit**
    – **Equipment / asset**
    – **Sub-equipment / component / instrument**

    Some organizations implement parallel hierarchies (e.g., functional vs physical vs location-based) when supported by their systems.

    Boundaries and what it is not

    An asset hierarchy:

    – **Is**
    – A structural model of how assets and locations are organized and related
    – A reference used by multiple systems for consistent asset identification
    – **Is not**
    – A maintenance plan, work-order schedule, or spare parts list (these reference the hierarchy but are separate)
    – A process model or recipe definition, although it may align with them
    – A pure accounting fixed-asset list, though it may be reconciled with accounting records

    Common confusion and variations

    – **Versus equipment hierarchy**: Many organizations use the terms interchangeably. “Equipment hierarchy” is often a subset focused strictly on maintainable equipment, while “asset hierarchy” may also include rooms, lines, utilities, or infrastructure.
    – **Versus process hierarchy (e.g., ISA-95 / ISA-88 models)**: Process models describe production activities, units, and recipes. Asset hierarchies focus on physical equipment and locations, though modern systems often align these models.
    – **Across disciplines**: Engineering, maintenance, and finance may maintain different hierarchies (functional, location-based, financial). In integrated manufacturing environments, these are often mapped or partially harmonized rather than fully merged.

    Site context: relation to MES and maintenance integration

    When MES integrates with **CMMS** or **EAM** systems, the asset hierarchy is a key reference point. Typical uses include:

    – Mapping MES equipment models (lines, cells, units) to CMMS/EAM asset records
    – Triggering maintenance work orders from MES events (e.g., downtime, condition limits) against the correct asset
    – Consolidating reliability and production data by line, area, or equipment, based on a shared hierarchy

    Consistent, well-governed asset hierarchies help MES, maintenance, and ERP systems refer to the same physical assets, even when they use different level structures internally.

  • Manufacturing Information Portal

    A Manufacturing Information Portal is a web-based interface that provides centralized access to manufacturing data, reports, and selected applications from across shop-floor and enterprise systems. It typically acts as a single entry point for users to view, query, and navigate production-related information without needing to log directly into each underlying system.

    Key characteristics

    While implementations vary by organization, a Manufacturing Information Portal commonly:

    • Aggregates data from multiple systems such as MES, SCADA, LIMS, historians, quality systems, and ERP
    • Provides role-based dashboards, KPIs, and reports for operations, quality, maintenance, and management users
    • Offers secure, browser-based access to manufacturing information, often inside the corporate intranet
    • Uses a common navigation structure so users can find production, quality, and asset data in one place
    • Integrates with identity and access management to control who can see which data

    In regulated manufacturing environments, the portal is typically positioned as a read-only or limited-interaction layer on top of validated systems, so that core data and workflows remain controlled in the source applications. The portal may show data such as batch status, deviations, equipment status, OEE, material usage, and genealogy, while write actions (such as releasing batches or changing master data) continue to occur within MES, ERP, or other transactional systems.

    Operational role

    Operationally, a Manufacturing Information Portal often functions as the front-end to an integration or data access layer. It may sit on top of a data warehouse, data lake, historian, or a manufacturing integration platform. Typical uses include:

    • Real-time or near real-time production monitoring dashboards
    • Self-service access to manufacturing reports and trend charts
    • Consolidated quality and deviation overviews across sites or lines
    • Access points to digital documents such as work instructions, SOPs, and batch records (often via links into controlled systems)
    • Role-specific homepages for operators, supervisors, engineers, and quality staff

    In multi-site or multi-system environments, the portal can provide a standardized way to view information even when underlying systems differ by site or business unit. In such cases, data harmonization, governance, and clear ownership are needed outside the portal itself.

    What it is not

    A Manufacturing Information Portal is not:

    • A replacement for core transactional systems such as MES, ERP, SCADA, LIMS, or CMMS
    • Automatically a data warehouse or historian, although it may rely on these as data sources
    • In itself a guarantee of data integrity, regulatory compliance, or audit readiness

    Instead, it is a presentation and access layer that depends on the design, validation, and governance of the systems and integrations underneath it.

    Common confusion

    The term Manufacturing Information Portal is sometimes confused with related concepts:

    • Manufacturing Integration Platform (MIP): Focuses on moving, transforming, and orchestrating data and messages between systems. It is typically middleware or an integration layer. A Manufacturing Information Portal, by contrast, is a user-facing web interface that may sit on top of such a platform.
    • Manufacturing Execution System (MES): Manages and records execution of production processes. A Manufacturing Information Portal may display MES data but does not usually manage workflows, enforce sequencing, or execute shop-floor transactions.

    Use in regulated environments

    In regulated industries, a Manufacturing Information Portal is commonly configured to respect data ownership and traceability boundaries. Examples include:

    • Viewing batch and lot status consolidated from multiple validated systems
    • Displaying audit-relevant metrics and reports generated by underlying applications
    • Providing read-only access to key production indicators for auditors or stakeholders through controlled, role-based views

    Any use of the portal for actions that affect product release, quality decisions, or regulated records usually relies on the validated behavior and controls of the underlying systems rather than the portal itself.

  • semantic interoperability

    Semantic interoperability commonly refers to the ability of two or more systems to exchange data in a way that preserves a shared, unambiguous understanding of the meaning, context, and intended use of that data. It goes beyond simply moving data or using the same formats, and focuses on whether all parties interpret the data in the same way.

    In industrial and manufacturing environments, semantic interoperability is relevant when connecting MES, ERP, LIMS, historians, quality systems, and OT control systems so that concepts such as batch, work order, material, specification, deviation, and equipment state are interpreted consistently across systems.

    Key characteristics

    Semantic interoperability typically includes:

    • Shared meaning of data elements: Agreement on what a field or tag represents (for example, whether “lot” and “batch” are equivalent in a given integration).
    • Common vocabulary or ontology: Use of defined terms, master data, reference data, or domain models that describe products, processes, equipment, and events in a consistent way.
    • Stable context: Clarity on units of measure, time zones, product versions, and process stages so that values are not misinterpreted.
    • Machine-interpretable structure: Use of schemas, metadata, or information models that allow software to process the meaning, not just the syntax, of exchanged data.

    Achieving semantic interoperability often involves data modeling, terminology management, and governance so that different plants, business units, or vendor systems align on what key concepts and codes mean.

    Operational meaning in manufacturing

    In day-to-day operations, semantic interoperability shows up in scenarios such as:

    • An MES and ERP both referencing the same definition of a “work order” and its statuses so that production reporting and financial posting reconcile correctly.
    • A quality management system and LIMS using consistent test names, limits, and result interpretations so that pass/fail decisions are comparable across sites.
    • A historian or IIoT platform mapping equipment states and alarms to a standard model so that OEE and downtime analytics use the same event meanings.

    Without semantic interoperability, integrations may technically function and share files or messages, but reports, KPIs, and compliance evidence may be inconsistent because systems interpret the same data differently.

    Relationship to other interoperability types

    Semantic interoperability is often described as one of four interoperability layers:

    • Technical interoperability: Ability to connect and transmit data (networks, protocols, connectivity).
    • Syntactic interoperability: Use of compatible data formats and structures (for example, JSON vs XML schemas).
    • Semantic interoperability: Shared understanding of what the data means.
    • Organizational interoperability: Alignment of processes, responsibilities, and governance across organizations.

    Semantic interoperability usually depends on the lower layers already being in place. It is not an automatic on/off property and tends to improve gradually as data models, master data, and integration designs mature.

    Common confusion

    • Semantic vs syntactic interoperability: Syntactic interoperability focuses on the form of data (for example, the structure of a message), while semantic interoperability focuses on the meaning of that data. Two systems can use the same message format but still misunderstand each other if their definitions of fields differ.
    • Semantic interoperability vs data quality: Data quality addresses whether data is accurate, complete, and timely. Semantic interoperability focuses on consistent interpretation. Poor data quality can undermine semantic interoperability, but they are not the same concept.

    Context in regulated environments

    In regulated manufacturing, semantic interoperability is particularly relevant where records, events, and results must be interpreted consistently across systems used for production, quality, and compliance. This can affect how deviations, batch records, electronic signatures, and audit evidence are created, exchanged, and reviewed across MES, ERP, LIMS, and other systems.

  • IEC 62264

    IEC 62264 is an international standard from the International Electrotechnical Commission that specifies models, terminology, and interface structures for integrating enterprise systems with manufacturing operations and control systems.

    The standard is closely aligned with the ISA‑95 series and is effectively its IEC adoption. It formalizes how information should be organized and exchanged between business-level applications (such as ERP and supply chain systems) and manufacturing-level applications (such as MES, LIMS, and SCADA).

    IEC 62264 defines, among other things:

    • Functional hierarchies for enterprise and manufacturing operations
    • Object models for equipment, materials, personnel, and processes
    • Activity and information models for production, quality, maintenance, and inventory operations
    • Standard categories for interfaces between enterprise and control systems

    In practice, organizations use IEC 62264 as a reference for structuring data models and integration points between IT systems (for example, ERP) and operational technology systems (for example, MES and plant-floor control systems).

  • ESB

    Core meaning

    ESB (Enterprise Service Bus) is a middleware architecture and software platform used to connect multiple enterprise applications by routing, transforming, and orchestrating messages between them.

    In manufacturing and other industrial environments, an ESB commonly sits between business systems (such as ERP), operations systems (such as MES, LIMS, WMS), and sometimes plant-level applications, providing a standardized way for them to exchange data.

    How an ESB operates

    An ESB typically provides:

    – **Message routing:** Directs messages from a producer (e.g., MES) to one or more consumers (e.g., ERP, quality system) based on configurable rules.
    – **Message transformation:** Converts data formats or structures (for example, from a plant-specific schema to a standardized enterprise schema).
    – **Protocol mediation:** Bridges different communication protocols or technologies (e.g., HTTP/SOAP, REST, JMS, file, database adapters).
    – **Orchestration and workflow:** Coordinates multi-step exchanges across several systems (e.g., create production order in MES, then update ERP when order is closed).
    – **Centralized integration logic:** Holds routing and transformation rules in one place instead of duplicating them in every connected application.

    ESBs are usually implemented as a combination of a runtime engine (message bus) and configuration or development tools used to define integration flows.

    Use in MES–ERP and industrial integrations

    In industrial and regulated manufacturing environments, an ESB is commonly used to:

    – Mediate **MES–ERP** exchanges for production orders, material master data, equipment states, and confirmations.
    – Integrate **quality and laboratory systems** (e.g., LIMS, QMS) with MES and ERP for test results and release status.
    – Connect **warehouse and logistics** systems (WMS/TMS) to production and planning systems.
    – Apply **validation-sensitive transformations** in a controlled, versioned layer when integration logic must be traceable and testable.

    In these settings, the ESB often coexists with other patterns (file transfers, database views, APIs, queues). It can serve as the hub that standardizes and governs integrations across heterogeneous OT and IT landscapes.

    Boundaries and what ESB is not

    – **Not a single protocol or standard:** ESB is an architectural style and product category, not a specific protocol like OPC UA or MQTT.
    – **Not an MES or ERP:** It does not manage production execution or business transactions; it transports and transforms messages about those activities.
    – **Not just a message queue:** While it may use message queues underneath, an ESB adds routing, transformation, and orchestration on top of basic queuing.
    – **Not inherently cloud or on-premises only:** ESBs can be deployed on-premises, in the cloud, or in hybrid forms.

    Common confusion and related concepts

    – **ESB vs. message broker/queue:** A message broker (e.g., a JMS broker or simple queue) focuses on reliable message transport and buffering. An ESB usually includes a broker plus mapping, routing, protocol mediation, and sometimes process orchestration.
    – **ESB vs. iPaaS:** An integration Platform as a Service (iPaaS) is a cloud-based integration platform. Many iPaaS offerings provide ESB-like capabilities, but the term iPaaS emphasizes delivery model (cloud) while ESB emphasizes architecture and functionality.
    – **ESB vs. API gateway:** An API gateway fronts and manages APIs (security, rate limiting, routing for API calls). An ESB can call or host APIs but focuses on back-end message flows across multiple systems.

    Site-context application

    Within MES–ERP integration, an ESB commonly:

    – Exposes standardized integration endpoints for MES and ERP rather than point-to-point custom interfaces.
    – Transforms MES-specific data models into ERP structures (and vice versa) while preserving auditability.
    – Implements routing rules for events like order release, production reporting, material consumption, and quality results.
    – Acts as the central place to manage and version integration logic when plants or sites have different system versions or validation requirements.

    This use aligns with broader enterprise integration patterns, while addressing the additional traceability and change-control needs typical of regulated manufacturing.

  • shared-responsibility model

    A shared-responsibility model is a documented understanding of how responsibilities for security, compliance, and operational controls are divided between a service provider and a customer. In industrial and manufacturing environments, it is commonly used for cloud platforms, industrial software, and managed services that are part of the OT/IT stack.

    What it includes

    The shared-responsibility model usually describes:

    • Provider responsibilities, such as platform security features, infrastructure hardening, built-in logging, availability controls, and default configurations.
    • Customer responsibilities, such as user and role management, network segmentation, configuration of security settings, procedure documentation, and local validation or testing.
    • Joint or conditional responsibilities, where both parties contribute (for example, applying patches provided by the vendor, or configuring audit logging features in line with plant policy).

    In regulated manufacturing environments, the model is often aligned with control frameworks such as NIST 800-53 or ISO-style information security controls. The provider may map its capabilities to specific controls, while the customer must show how those capabilities are deployed, configured, and governed in the plant context.

    Operational meaning in industrial settings

    Practically, a shared-responsibility model helps clarify:

    • Who maintains system configurations and access controls for MES, historians, or industrial data platforms.
    • Who provides evidence of control operation during audits, such as change records, validation reports, or network diagrams.
    • Which party owns incident response steps for security events affecting OT and connected IT systems.
    • How responsibilities may differ between on-premises, hybrid, and cloud-hosted components.

    The model is typically captured in security or quality documentation, supplier agreements, or platform reference architectures, and should be kept under change control as the system or scope evolves.

    Common confusion

    • Not the same as a service-level agreement (SLA): An SLA focuses on performance and availability targets. A shared-responsibility model focuses on who does what for controls and operations.
    • Not a compliance certificate: The model explains role boundaries. It does not, by itself, prove that controls are effectively implemented or validated in a specific plant.

    Link to the NIST 800-53 context

    When industrial platforms describe alignment with NIST 800-53, a shared-responsibility model helps show which controls the provider supports directly and which remain the customer’s responsibility. This allows manufacturers to design their own control environment, gather appropriate evidence, and avoid assuming that platform capabilities alone meet all framework expectations.

  • Quality cost

    Quality cost refers to the total cost associated with achieving, assuring, and failing to meet specified quality requirements for products, processes, or services. In manufacturing and other regulated operations, it is a structured way of categorizing how resources are spent to prevent defects, inspect and verify quality, and deal with nonconformities when they occur.

    Main categories of quality cost

    Quality cost is commonly broken into four groups:

    • Prevention costs: Costs incurred to avoid defects and nonconformances. Examples include training, process engineering, mistake-proofing (poka-yoke), preventive maintenance, document control, and quality planning activities.
    • Appraisal costs: Costs related to evaluating and inspecting products and processes to verify they meet requirements. Examples include incoming inspection, in-process checks, final inspection, testing, calibration, audits, and verification activities in MES or QMS workflows.
    • Internal failure costs: Costs that arise when defects are found before the product is delivered to the customer. Examples include scrap, rework, re-inspection, downgrading, line stoppages, MRB reviews, and updating records or travelers after a nonconformance is found.
    • External failure costs: Costs that arise when defects are found after delivery to the customer. Examples include returns, warranty work, field repairs, rework at customer sites, complaint handling, investigations, potential penalties, and disruptions to supply or production schedules.

    Operational use in manufacturing and regulated environments

    In industrial operations, quality cost is often tracked as part of broader cost of poor quality (COPQ) and continuous improvement efforts. Data may be captured across systems such as MES, ERP, QMS, and maintenance systems, then analyzed to:

    • Understand how much of total cost is tied to failures versus prevention and appraisal.
    • Identify high-impact sources of scrap, rework, and nonconformances.
    • Support decisions on investments in process controls, training, or automation.
    • Align quality performance metrics with financial reporting and operational KPIs.

    In regulated industries, documenting and categorizing quality costs can also support internal reviews, management reporting, and evidence for audits, without implying any specific compliance outcome.

    Common confusion

    • Quality cost vs cost of poor quality (COPQ): Quality cost usually includes all four categories (prevention, appraisal, internal failure, and external failure). Cost of poor quality commonly focuses on failure costs only (internal and external), or on the portion of quality cost that is considered avoidable. Usage varies by organization.
    • Quality cost vs general production cost: Quality cost is a subset of total production and operating cost, specifically related to quality activities and outcomes. It does not include unrelated expenses such as general administration or sales and marketing.