Connect981 – Content Dev

Glossary Tag: leading indicators

  • Functional hierarchy

    A functional hierarchy is a structured breakdown of an organization’s activities into ordered functional levels, showing how high-level business functions relate to lower-level manufacturing and control functions. It is used to model who does what, at which level, and with which systems, rather than where equipment is physically located.

    In manufacturing and industrial operations

    In regulated and complex manufacturing environments, a functional hierarchy commonly refers to the layered view of enterprise and manufacturing functions defined in standards such as ISA‑95 / IEC 62264. Typical levels include:

    • Enterprise and business planning functions (e.g., strategic planning, financials, corporate scheduling)
    • Manufacturing operations management functions (e.g., production scheduling, MES, quality management, maintenance management, warehouse management)
    • Manufacturing control functions (e.g., SCADA, batch control, recipe execution, cell/area supervision)
    • Process and equipment control functions (e.g., PLC logic, DCS control loops, safety instrumented functions)

    Each level groups functions that share similar scope and time horizons. The functional hierarchy helps describe interfaces between ERP, MES, LIMS, SCADA, control systems and other applications by clarifying which functions are performed at which level.

    Operational use

    Practitioners use functional hierarchies to:

    • Map business processes and manufacturing workflows to system responsibilities
    • Define integration boundaries between ERP, MES, quality, maintenance and control systems
    • Clarify ownership of data and decisions at different levels (planning vs execution vs control)
    • Support impact analysis and change control when systems or processes are modified

    In regulated environments, documenting the functional hierarchy can support system life cycle documentation, validation planning and clear segregation of duties between systems and organizational roles.

    Common confusion

    • Functional hierarchy vs physical hierarchy: A functional hierarchy organizes activities and responsibilities. A physical hierarchy organizes equipment and locations (site, area, line, unit, asset). Many models use both views together.
    • Functional hierarchy vs organizational chart: An org chart shows reporting lines between people or departments. A functional hierarchy focuses on the functions and capabilities, which may be implemented by multiple departments or systems.

    Relation to IEC 62264 / ISA‑95

    IEC 62264 (aligned with ISA‑95) uses functional hierarchies to describe how enterprise systems like ERP and manufacturing systems like MES, SCADA and control systems are partitioned by function. The standard’s levels are a reference model for organizing these functions and for discussing which information should be exchanged between levels, without prescribing specific products or enforcing interoperability.

  • B2MML

    B2MML (Business To Manufacturing Markup Language) is an open, XML-based implementation of the ISA-95 standard. It provides a set of XML schemas that represent ISA-95 object models and data structures so that business systems (such as ERP) and manufacturing systems (such as MES, LIMS, and SCADA/PCS interfaces) can exchange information in a consistent way.

    What B2MML includes

    B2MML commonly includes XML schemas for representing:

    • Enterprise, site, and area models
    • Equipment and production line hierarchies
    • Material definitions, lots, and inventories
    • Production schedules and work orders
    • Production performance and event data
    • Personnel and work center assignments

    Vendors and integrators use these schemas to define message formats for integrations, such as sending production schedules from ERP to MES, or sending production response data from MES back to ERP.

    How B2MML is used in industrial environments

    In regulated and complex manufacturing environments, B2MML is commonly used as a neutral data model and message structure between systems, for example:

    • Integrating ERP or planning systems with MES and scheduling tools
    • Exchanging material master and bill-of-material information with manufacturing systems
    • Capturing production results, consumption, and genealogy from MES and feeding them to ERP or data warehouses
    • Standardizing the interface definitions in multi-vendor system architectures

    B2MML itself does not enforce validation, security, or regulatory compliance. It defines how data is structured and labeled, not how systems must behave or be configured.

    Relationship to ISA-95

    ISA-95 is a conceptual and logical standard that defines models and terminology for integrating enterprise and control systems. B2MML turns those models into concrete XML schemas that can be implemented in software interfaces. B2MML is therefore often described as a practical implementation layer for ISA-95 data exchanges.

    Common confusion

    • Not a protocol: B2MML defines message structures (schemas), not the transport mechanism. It is typically used over web services, message queues, or file transfer, depending on the integration design.
    • Not a full integration solution: B2MML does not replace integration platforms, middleware, or custom mapping logic. It is a data model and schema set that those solutions can use.
    • Not identical to ISA-95: ISA-95 is the overarching standard; B2MML is one widely used XML implementation of that standard.

    Context from interoperability discussions

    In interoperability discussions, B2MML is often mentioned alongside standards such as OPC UA and ISA-95. While it can support interoperability by providing a shared data structure for messages, actual interoperability still depends on vendor implementations, configuration, data mapping, and change control across the integrated systems.

  • data collection

    Core meaning

    Data collection is the systematic capture of raw data from people, machines, and software systems into a defined structure so it can be stored, processed, and analyzed.

    In industrial and regulated manufacturing environments, data collection commonly refers to the ongoing recording of production, quality, maintenance, and environmental data from shop-floor activities and related IT/OT systems.

    How data collection is used in manufacturing

    Typical uses in manufacturing and industrial operations include:

    – **Production execution data**: start/stop times, quantities produced, scrap counts, downtimes, changeovers, and operator IDs.
    – **Quality and inspection data**: measurements, test results, pass/fail decisions, sampling results, and inspection sign-offs.
    – **Equipment and process data**: temperatures, pressures, speeds, setpoints, alarms, and events from PLCs, SCADA, historians, and sensors.
    – **Material and genealogy data**: lot/batch IDs, serial numbers, material consumption, and traceability links between inputs and finished goods.
    – **Compliance and log data**: electronic signatures, access logs, audit trails, and records needed to support internal and external audits.

    Data may be collected:

    – **Manually** (operators entering values on MES terminals, checklists, or forms)
    – **Automatically** (direct acquisition from machines, instruments, and control systems)
    – **Via integration** (exchanging data between MES, ERP, LIMS, CMMS, WMS, and other enterprise systems)

    Boundaries and scope

    Data collection:

    – **Includes** the processes, configurations, and mechanisms used to capture and store raw data at the point of occurrence.
    – **Includes** the definition of what data is captured (data model, fields, timestamps, identifiers) and at what frequency or trigger.
    – **Does not inherently include** analysis, reporting, or decision-making; those are downstream activities (such as analytics, reporting, or operations intelligence) that use collected data.
    – **Does not necessarily imply enforcement** of process steps or rules; it can record what happened without preventing non-compliant actions.

    Common methods and system roles

    In OT/IT and MES contexts, data collection commonly involves:

    – **MES and electronic batch records (EBR)** capturing operator actions, inspections, and process parameters during execution.
    – **Data historians** storing high-frequency time-series data from control systems and sensors.
    – **SCADA/HMI systems** logging alarms, events, and process values.
    – **Edge devices and gateways** aggregating and normalizing data from heterogeneous equipment.
    – **Integration middleware or APIs** transferring data into central repositories, data lakes, or enterprise applications.

    Configuration typically specifies:

    – Trigger conditions (e.g., at operation start/end, at defined time intervals, at alarm, on measurement)
    – Required versus optional fields
    – Data validation rules and formats
    – Time synchronization and source identification

    Relation to MES enforcement (site context)

    When discussing whether an MES can enforce that specific steps or inspections are completed, **data collection** refers to recording the evidence that those steps or inspections were carried out (e.g., entering inspection results, capturing electronic signatures, logging machine parameters).

    In this context:

    – Data collection provides the **record** that an operation, test, or check occurred.
    – Enforcement logic in MES uses required data collection points, routing rules, and status checks to **block progression** until the needed data has been entered or captured.
    – Audit trails and access logs are collected data that demonstrate who performed or approved each action.

    However, the mere presence of data collection screens or fields does not guarantee enforcement; enforcement depends on how the MES and related systems use collected data in workflow and authorization rules.

    Common confusions and related terms

    – **Data collection vs. data logging**: Data logging often implies automated, continuous recording (e.g., from sensors), whereas data collection is broader and includes manual and event-based capture.
    – **Data collection vs. data acquisition (DAQ)**: Data acquisition usually refers to the technical process of reading signals from hardware; data collection is wider and includes human inputs, system integrations, and structured storage.
    – **Data collection vs. data analysis**: Collection is about capturing and storing; analysis is about interpreting and using that data.

    Using these terms precisely helps distinguish between:

    – The act of recording what happened (data collection)
    – The mechanisms that read physical signals (data acquisition)
    – The processing and interpretation of information (analytics, reporting, operations intelligence)

  • digital transformation

    Digital transformation commonly refers to the structured and long-term use of digital technologies to redesign how an organization operates, creates value, and makes decisions. In industrial and regulated environments, it usually spans processes, systems, data, and culture, instead of being a single project or tool deployment.

    Core meaning in industrial and regulated environments

    In manufacturing and other regulated operations, digital transformation typically includes:

    • Process and operations transformation: Moving from paper or disconnected tools to integrated, data-driven workflows across production, maintenance, quality, and supply chain. Examples include using MES, electronic batch records, digital work instructions, and automated data capture from equipment.
    • Business and service model transformation: Changing how value is delivered using digital capabilities, such as connected products, remote monitoring services, outcome-based contracts, or digital self-service portals for customers and suppliers.
    • Stakeholder and customer experience transformation: Using digital channels to provide more transparent, timely, and traceable information to customers, regulators, auditors, and partners, while maintaining required controls.
    • Organizational and cultural transformation: Developing skills, governance, and behaviors so that teams use data and digital systems in daily decisions, follow controlled digital workflows, and collaborate across OT, IT, quality, and engineering.

    Digital transformation in this context usually must coexist with, and incrementally upgrade, existing MES, ERP, QMS, LIMS, and control systems rather than replace them all at once.

    What digital transformation is and is not

    • Is: A long-term shift in how work is done, driven by integrated digital systems, governed data, and changed practices.
    • Is: A portfolio of initiatives that can include automation, analytics, cloud services, industrial IoT, and standardized digital workflows.
    • Is not: Just buying new software, deploying a dashboard, or automating one isolated step without changing processes or governance.
    • Is not: Limited to IT; it spans OT, production, quality, maintenance, supply chain, engineering, and supporting functions.

    Operational characteristics

    In day-to-day operations, digital transformation often appears as:

    • Digital capture of production, quality, and maintenance data instead of manual records.
    • Integration between shop floor systems (equipment, SCADA, MES) and enterprise systems (ERP, QMS, PLM).
    • Standardized, version-controlled digital procedures, work instructions, and forms.
    • Use of analytics, dashboards, and alerts to support operational decisions and investigations.
    • Defined governance for data integrity, access control, and change management, aligned with regulatory expectations where applicable.

    Common confusion

    • Digitization vs. digitalization vs. digital transformation:
      • Digitization usually means converting analog information to digital form, such as scanning paper records.
      • Digitalization commonly refers to using digital tools to improve existing processes, for example replacing a paper form with an electronic form without changing the workflow.
      • Digital transformation goes further by rethinking processes, roles, and decisions around integrated digital systems and data.
    • Industry 4.0 vs. digital transformation: Industry 4.0 is a broad concept for highly connected, automated, and intelligent manufacturing. Digital transformation is the ongoing organizational journey that may use Industry 4.0 technologies but is not limited to them.

    Link to the “four types” framing

    Many industrial and regulated organizations describe digital transformation in four overlapping types: business model, operations/process, customer or stakeholder experience, and organizational or cultural transformation. This framing is often used to plan initiatives, align OT/IT/quality stakeholders, and prioritize integration work with existing MES, ERP, and QMS environments.

  • ANSI/ISA-95

    ANSI/ISA-95 is an international standard that provides a common reference model, terminology, and set of models for integrating business systems and manufacturing control systems. It is widely used to structure data flows and responsibilities between systems such as ERP, PLM, MES, SCADA, and shop-floor control in industrial environments.

    Scope and purpose

    ANSI/ISA-95 focuses on the interface between enterprise-level systems and manufacturing operations. It:

    • Defines functional levels from enterprise planning to process control (often represented as Levels 0 to 4).
    • Describes models for production, quality, inventory, and maintenance information.
    • Provides standard terminology and object models to reduce ambiguity between vendors and users.
    • Helps structure integration projects between ERP and MES/SCADA and other OT systems.

    The standard describes what information is typically exchanged and how to model it, rather than prescribing a specific technology stack, vendor solution, or implementation method.

    What ANSI/ISA-95 includes

    Within industrial and regulated manufacturing environments, ANSI/ISA-95 commonly includes:

    • A layered model for separating enterprise planning, manufacturing operations management, and process/control activities.
    • Information models for materials, equipment, personnel, production schedules, production performance, and quality information.
    • Concepts and structures that underpin many MES architectures and MES/ERP integration patterns.
    • A basis for defining standard interfaces and data exchanges between heterogeneous systems.

    What ANSI/ISA-95 does not include

    ANSI/ISA-95 does not:

    • Guarantee interoperability between specific products or vendors.
    • Provide a complete system design or project methodology.
    • Specify programming interfaces, protocols, or vendor-neutral APIs by itself.
    • Replace regulatory requirements, validation approaches, or quality system procedures.

    Organizations typically adapt the standard to fit their processes, legacy (brownfield) systems, and compliance expectations.

    Operational use in manufacturing

    In practice, ANSI/ISA-95 is used as a blueprint to:

    • Clarify responsibilities between business planning (ERP) and manufacturing execution (MES) functions.
    • Define data objects (such as work orders, material definitions, equipment capability, and production results) in a consistent way.
    • Support integration projects that need structured data exchanges across OT and IT, including regulated environments.
    • Inform vendor selection and interface specifications for MES, LIMS, historian, and SCADA systems.

    Common confusion

    • Not a product: ANSI/ISA-95 is a standard, not a specific software solution. Vendors may claim to be “based on” or “aligned with” it, but that does not represent formal certification.
    • Different from ISA-88: ISA-88 focuses on batch control and batch models, while ANSI/ISA-95 focuses on enterprise-to-manufacturing integration and operations models. The two are complementary.
    • Not a compliance framework: It is a technical and architectural reference, not a regulatory or quality-system standard.

    Relation to enterprise control system integration

    In enterprise control system integration, ANSI/ISA-95 is commonly used to structure how business systems such as ERP or PLM exchange information with MES, SCADA, historians, and control systems. It provides a shared language for defining levels, data structures, and interfaces so that cross-functional teams can design and maintain integrations more consistently.

  • 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.

  • 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.

  • 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).