Connect981 – Content Dev

Glossary Tag: signal detection

  • OPC Classic

    OPC Classic is a family of legacy industrial communication standards that define how control systems, devices, and software applications exchange real-time and historical process data, alarms, and events. It is based on Microsoft COM/DCOM technology and is primarily used in Windows environments.

    What OPC Classic includes

    OPC Classic commonly refers to several related specifications released before OPC UA, including:

    • OPC Data Access (DA) for real-time process values, setpoints, and status
    • OPC Alarms & Events (A&E) for alarm and event notifications
    • OPC Historical Data Access (HDA) for querying archived process data

    These standards define a vendor-neutral interface between OPC servers (data providers such as PLCs, DCS, historians, and SCADA systems) and OPC clients (HMI, MES, reporting, and analytics tools).

    Where OPC Classic is used in manufacturing

    In industrial and regulated manufacturing environments, OPC Classic commonly appears as:

    • A layer between PLCs or DCS systems and SCADA/HMI applications
    • A connection between shop floor control systems and MES or data historians
    • An interface for collecting process values and alarms used in quality or batch reporting

    Because it relies on COM/DCOM, OPC Classic typically runs on on-premises Windows servers or workstations, often within an OT network segment.

    What OPC Classic is not

    • It is not a security framework or cybersecurity solution.
    • It is not a compliance or validation method by itself.
    • It is not the same as OPC UA, which is a newer, platform-independent architecture.

    OPC Classic provides a standard way to move data; security, reliability, and regulatory suitability depend on the surrounding architecture, hardening, and procedural controls.

    Common confusion

    • OPC Classic vs OPC UA: OPC Classic uses COM/DCOM and is largely tied to Windows. OPC UA is a newer set of specifications that support platform independence, richer information modeling, and more modern security mechanisms.
    • OPC vs compliance: In manufacturing, OPC (including OPC Classic) is often discussed in the context of data integrity or electronic records, but it is a communication standard, not an indication of regulatory compliance.

    Relation to broader OPC context

    Within the broader OPC Foundation standards, OPC Classic is the earlier generation focused on basic interoperability between industrial systems. Many facilities operate mixed environments where OPC Classic servers and clients coexist with OPC UA gateways or bridges, especially when integrating legacy equipment with newer MES, historian, or analytics platforms.

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

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

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

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

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