Connect981 – Content Dev

Glossary Tag: signal detection

  • syntactic interoperability

    Syntactic interoperability commonly refers to the ability of two or more systems to exchange data using a shared structure, format, and set of encoding rules so that messages can be parsed and processed correctly on each side.

    In industrial and manufacturing environments, syntactic interoperability focuses on aligning how data is packaged, not on what the data means. It is about making sure messages follow the same schemas, field layouts, and protocols so software and equipment can read and validate them reliably.

    What syntactic interoperability includes

    In practice, syntactic interoperability typically covers:

    • Use of common message formats (for example XML, JSON, CSV, EDI transaction sets)
    • Agreed schemas and field structures (data types, field order, required vs optional fields)
    • Protocol-level rules (for example MQTT topic structures, OPC UA node structures, REST API contracts)
    • Consistent character encodings and date/time formats
    • Validation rules that check whether a message conforms to the agreed syntax

    For example, a manufacturing execution system (MES) and an enterprise resource planning (ERP) system can achieve syntactic interoperability by implementing the same JSON API specification for production order messages, even if they still interpret some fields differently.

    Where syntactic interoperability fits in integration

    Syntactic interoperability is usually described as one layer of interoperability, often alongside technical, semantic, and organizational interoperability:

    • Technical: Networks, connectivity, and basic data transport work.
    • Syntactic: The message formats and structures are aligned and machine-readable.
    • Semantic: The systems share a common understanding of what the data elements mean.
    • Organizational: Processes, responsibilities, and governance support consistent use of the data.

    In regulated manufacturing, syntactic interoperability often appears in interface specifications, data mapping documents, and validation evidence showing that messages between control systems, MES, LIMS, QMS, and ERP follow an agreed structure.

    Common confusion

    Syntactic interoperability is often confused with:

    • Technical interoperability, which focuses on connectivity and transport (for example, two systems both support HTTPS), not on the structure of the messages.
    • Semantic interoperability, which addresses the meaning of data elements (for example, whether both systems interpret a field called “batch” in the same way), beyond just the structure.

    Syntactic interoperability alone does not guarantee that two systems agree on business concepts, regulatory interpretations, or how data should be used. It simply ensures that messages follow the same structural rules so they can be exchanged and parsed without errors.

  • data flow mapping

    Core meaning

    Data flow mapping is the activity of systematically documenting how data moves between systems, people, and locations across a process or organization. It describes the sources, destinations, formats, and transfer mechanisms for data, rather than the business logic applied to that data.

    In industrial and manufacturing environments, data flow mapping typically focuses on how production, quality, maintenance, and business data travel across OT and IT systems and into external parties such as suppliers or customers.

    What data flow mapping includes

    Data flow mapping commonly captures:

    – **Data sources**: where data originates (e.g., PLCs, SCADA, MES, LIMS, ERP, supplier portals, spreadsheets).
    – **Data destinations**: where data is consumed or stored (e.g., historians, MES, ERP, QMS, file shares, cloud services).
    – **Transfer paths**: how data moves (e.g., APIs, message queues, OPC, file transfers, email, USB, paper forms later keyed in).
    – **Data types and classifications**: what the data represents and its sensitivity (e.g., production recipes, NC/CAPA records, Controlled Unclassified Information, personally identifiable information).
    – **Process and workflow context**: which business or manufacturing steps the data supports (e.g., work order release, batch record review, supplier qualification).
    – **Actors**: which roles or systems send, modify, or receive the data (e.g., operators, quality engineers, maintenance planners, external labs).

    The result may be represented as diagrams, tabular inventories, or both.

    Use in manufacturing and regulated environments

    In manufacturing, data flow mapping is commonly used to:

    – Describe how shop-floor data moves from equipment and sensors into MES, historians, and ERP.
    – Show how quality data flows between QMS, LIMS, production systems, and customer or regulatory reporting channels.
    – Document how engineering data (e.g., specifications, BOMs, recipes) is distributed to production lines and suppliers.
    – Trace how supplier and customer data is exchanged through portals, EDI, APIs, or manual processes.

    In regulated or audited settings, such mappings help organizations:

    – Identify where controlled or sensitive data is stored or transmitted.
    – Understand system boundaries and trust zones between OT and IT networks.
    – Support risk assessments, change impact analysis, and validation or verification activities.

    Boundaries and what it is not

    Data flow mapping:

    – **Is about movement and location of data**, not about detailed business rules or algorithms.
    – **Is system- and process-focused**, not limited to network-layer packets or code-level interactions.
    – **May include high-level technical details** (e.g., protocol, interface type) but usually does not replace full network diagrams or application design specifications.

    It is not the same as:

    – **Process mapping**: which focuses on business or manufacturing steps, roles, and decisions; data flows may be one component, but are not the only focus.
    – **Value stream mapping**: which concentrates on material and information flow for performance and waste analysis, rather than documenting specific data interfaces and storage locations.
    – **Data modeling**: which describes data structure and relationships (schemas, entities, attributes), not how data moves between systems.

    Common confusion and misuse

    Data flow mapping is sometimes confused with general “system architecture” or “network” diagrams. While these may overlap, data flow mapping is specifically concerned with:

    – What data items move.
    – Between which endpoints.
    – By what mechanisms.
    – Under which process context and controls.

    Another common misuse is to focus only on formal, IT-managed integrations and ignore:

    – Ad-hoc spreadsheets and local databases.
    – Manual exports, email attachments, removable media.
    – Shadow tools and unofficial workflows on the shop floor.

    These informal flows often handle sensitive production, quality, or customer data and are important to capture.

    Site context: security and compliance readiness

    In the context of security and frameworks such as CMMC or similar requirements, data flow mapping is used to:

    – Identify where controlled or regulated data enters manufacturing operations (e.g., controlled drawings, specifications, contract data).
    – Trace how that data moves through OT systems, shop-floor workflows, supplier interactions, and back-office systems.
    – Highlight undocumented or ungoverned paths (e.g., printing drawings, copying to USB, sharing via personal email) that can become compliance and security gaps.

    For assessments and audits, documented data flow maps provide evidence that an organization understands and manages how sensitive information is handled across production, IT, and supplier ecosystems.

  • brownfield

    Core meaning

    In industrial and manufacturing contexts, **brownfield** commonly refers to an existing, already built and operating facility, process, or system that is being upgraded, expanded, or integrated with new technology, rather than designed and implemented from scratch.

    The term is used in contrast to **greenfield**, which describes new facilities or systems built on a “clean slate” without legacy constraints.

    Use in manufacturing and OT/IT systems

    In regulated manufacturing and operations technology (OT) and information technology (IT), brownfield typically means:

    – **Existing plants and production lines** that are already commissioned and producing product.
    – **Legacy automation and control systems** (PLCs, SCADA, DCS, historians) that must remain in place while being connected to newer systems.
    – **Established MES/ERP/QMS implementations** that are already validated or embedded in daily operations.

    Projects described as brownfield often involve:

    – Integrating a new MES with legacy equipment and existing business systems.
    – Adding new lines or equipment into a running plant with existing standards and data models.
    – Migrating from one system (e.g., an old MES) to another while maintaining production.

    Because the environment already exists, brownfield work must account for installed hardware and software, data models, standard operating procedures, and regulatory validation status.

    Boundaries and exclusions

    In this site context, **brownfield**:

    – **Includes** existing factories, warehouses, utilities, and their associated digital systems (OT/IT) that are being modified, integrated, or modernized.
    – **Includes** projects where new systems (such as MES, historians, or analytics platforms) are introduced into running operations.
    – **Excludes** purely conceptual or new, not-yet-built facilities (these are typically **greenfield**).
    – **Excludes** the narrower environmental-planning use of “brownfield” to mean land contaminated by prior industrial use, except where explicitly stated.

    Common confusion with other uses

    The word **brownfield** is also used in urban planning and environmental regulation to describe land or real estate that may be contaminated by prior industrial activity.

    On this site, unless environmental remediation is explicitly discussed, **brownfield** should be understood primarily as:

    – An **existing operational environment** with legacy systems and constraints, being changed or integrated.

    This is distinct from:

    – **Greenfield**: new build with no legacy constraints.
    – **Brownfield site (environmental)**: land requiring environmental assessment or cleanup.

    Site context: brownfield and MES/local process adaptation

    When discussing MES and local process adaptation in a brownfield plant:

    – The MES is deployed into an **existing plant** with established processes, equipment, and data flows.
    – Local teams often adapt processes within the constraints of existing MES configuration, validation, and integration.
    – Changes typically need to respect legacy interfaces, historical data, and regulatory documentation that already exist.

    In this context, calling a deployment **brownfield** highlights that MES or other systems must coexist with and adapt to the current operational and regulatory landscape, rather than redefining it from scratch.

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

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

  • source of truth

    Core meaning

    In industrial and manufacturing contexts, a **source of truth** is the specific system, database, document set, or process that an organization designates as the **authoritative reference** for a well-defined category of information.

    It answers the question: *“When systems disagree, which one do we treat as authoritative for this data element?”*

    A source of truth is always scoped. It applies to a defined domain such as:

    – Material master data (e.g., ERP or PLM)
    – Production execution data (e.g., MES or SCADA historian)
    – Quality results (e.g., LIMS or QMS)
    – Inventory balances (e.g., ERP or WMS by location/type)

    The designation is usually formalized through governance, procedures, and integration rules, not by the technology alone.

    Use in industrial and manufacturing workflows

    In regulated and complex manufacturing environments, the term commonly refers to:

    – **Master data ownership**: Identifying which system owns product definitions, BOMs, routings, recipes, specifications, or equipment hierarchies.
    – **Transactional ownership**: Defining which application is authoritative for production orders, batch records, material movements, and inventory positions at different stages.
    – **Regulatory records**: Determining which record set (for example, electronic batch records, deviation reports, or calibration records) is treated as the official record for compliance and audits.
    – **Reporting and analytics**: Establishing which data store or model is the reference for KPIs such as OEE, yield, scrap, or on-time delivery so reports are consistent.

    These designations drive how interfaces are built, how discrepancies are triaged, and how investigations are documented.

    Boundaries and exclusions

    A source of truth:

    – **Is authoritative only within its defined scope.** A system may be the source of truth for one data type (e.g., inventory valuation) and not for another (e.g., real-time tank level).
    – **Does not guarantee correctness at all times.** It is the reference point for decisions and corrections, not a claim that the data is error-free.
    – **Is more than a data copy.** Downstream replicas, data warehouses, and reports that consume data are not sources of truth unless explicitly governed as such.

    It is distinct from:

    – **Single database storage**: Having data physically in one place does not automatically make it the authoritative reference.
    – **Canonical data model**: A canonical model defines a common structure and semantics; a source of truth defines which system is authoritative for specific elements.

    Common confusion and misuse

    The term “source of truth” is sometimes used loosely to mean:

    – “The system we prefer to look at,” even when other systems remain authoritative for specific data points.
    – “The system that is most accurate in practice,” without formal governance or procedures to support that claim.

    More precise use in operations and IT architectures:

    – **Single source of truth (SSOT)**: Often used for enterprise master data, though in practice most manufacturing environments operate with **multiple sources of truth**, each clearly scoped.
    – **System of record**: Closely related; often used interchangeably. In some organizations, a system of record is the application that creates and maintains the data, while the source of truth is any designated authoritative reference, which might be the system of record itself or a governed consolidation layer.

    Site context: MES–ERP discrepancies

    Where MES and ERP balances or transactions do not match, organizations typically:

    – Define **source-of-truth rules by balance or transaction type** (for example, ERP as source of truth for financial inventory value, MES as source of truth for in-process quantities on specific equipment).
    – Use these rules to drive **reconciliation and triage**: identifying which system must be corrected and how adjustments are recorded.
    – Document these designations under **change control and data governance**, so that investigations, CAPAs, and audits refer back to the same agreed authority for each data category.

    In this context, “source of truth” is a governance decision that shapes how discrepancies are handled, not a property that either MES or ERP inherently possesses in all cases.