Connect981 – Content Dev

Glossary Tag: process monitoring

MQTT

Core concept

MQTT (Message Queuing Telemetry Transport) is a lightweight, TCP/IP-based messaging protocol that uses a publish–subscribe model. It is commonly used to connect devices, sensors, controllers, and applications, especially where bandwidth, power, or processing capacity is limited.

In industrial and manufacturing environments, MQTT is often used as a transport layer for OT data (e.g., machine states, sensor values, alarms) to be consumed by IT systems such as MES, historians, analytics platforms, or cloud services.

How MQTT works

MQTT is based on three key elements:

– **Broker**: A server that receives messages from publishers and routes them to subscribers based on topics.
– **Publisher**: A client that sends messages to the broker, tagging them with a topic (for example, `plant1/line3/machine7/state`).
– **Subscriber**: A client that registers interest in specific topics and receives messages that match those topics.

Characteristics commonly seen in industrial use:

– **Publish–subscribe pattern**: Decouples data producers and consumers in time, location, and implementation.
– **Topic hierarchy**: Messages are organized under topic strings, often reflecting plant/line/machine/parameter structure.
– **Quality of Service (QoS) levels**: Controls delivery guarantees (at most once, at least once, exactly once) for messages, important for alarms and state changes.
– **Lightweight wire format**: Messages have a small overhead, suitable for constrained devices and high-volume telemetry.

Use in manufacturing and regulated operations

In industrial and regulated environments, MQTT commonly refers to its role in:

– **Machine and device connectivity**: PLCs, sensors, gateways, and edge devices publish machine states, process values, and alarms to an MQTT broker.
– **MES, SCADA, and historian integration**: MES or SCADA applications subscribe to MQTT topics to receive real-time production, quality, or alarm data, or publish commands and setpoints.
– **Event and alert transport**: Alerting systems (for example, Andon boards, email/SMS gateways, operator dashboards) may subscribe to MQTT topics carrying alarm or status events from MES or shop-floor systems.
– **Edge-to-cloud data flows**: Edge gateways consolidate OT data and forward it using MQTT to cloud analytics or centralized monitoring systems.

When used in regulated environments, MQTT-based data flows are typically subject to the same change control, validation, access control, and audit requirements as other integration mechanisms.

Boundaries and exclusions

– **MQTT is a transport protocol, not a full application standard**: It defines how messages are moved, not the semantics of payloads. Payloads may be JSON, binary, or other formats; structure and meaning are defined separately (for example via OPC UA data models, custom schemas, or vendor-specific formats).
– **Not the same as message queues or enterprise buses**: Despite the name, MQTT is not a traditional enterprise message queue or ESB. It can be used within such architectures, but it does not itself provide workflow orchestration, transactional queuing, or complex routing rules beyond topics and wildcards.
– **Not specific to any one vendor or platform**: MQTT is an open protocol and is implemented by many brokers and clients. Using MQTT does not imply a particular MES, SCADA, or cloud platform.

Common confusion and related terms

– **MQTT vs. OPC UA**:
– MQTT is a messaging transport; it says how to move messages.
– OPC UA is a broader standard covering data models, services, security, and sometimes transport. OPC UA can be used over MQTT, and some industrial stacks combine both.
– **MQTT vs. AMQP, Kafka, or other messaging protocols**:
– MQTT is optimized for lightweight telemetry and constrained devices.
– AMQP, Kafka, and similar protocols are often used for heavier enterprise messaging or streaming use cases with more complex broker features.
– **MQTT vs. REST/HTTP APIs**:
– MQTT is stateful and push-oriented with publish–subscribe.
– REST/HTTP is typically request–response. Both can coexist; for example, MES may expose REST APIs while using MQTT for live telemetry and alerts.

Site context: MES alerts and plant systems

In the context of MES alerts and plant integrations:

– MES or event-processing services can **publish alerts** (e.g., `plant1/alerts/andon/line3`) to an MQTT broker.
– Andon displays, email/SMS gateways, or other notification systems can **subscribe** to these topics to render visual signals, send emails, or log events.
– Reliability considerations (QoS, retained messages, persistent sessions) and IT/OT governance (network zoning, authentication, authorization, audit logging) are typically addressed when using MQTT as part of validated MES and plant alert workflows.

This usage does not change the general meaning of MQTT; it is one common application pattern within OT–IT integration.

April 13, 2026
Cost Allocation

Operational meaning

Cost allocation is the systematic assignment of costs to specific products, processes, departments, cost centers, or projects according to defined rules. It is used to attribute shared or indirect costs (for example, utilities, maintenance, IT, or quality functions) to the areas of the business that consume those resources.

In industrial and manufacturing environments, cost allocation is typically performed within ERP or financial systems, sometimes using data originating from MES, maintenance, or quality systems to determine usage or drivers.

How it is used in manufacturing workflows

In regulated and complex manufacturing operations, cost allocation commonly refers to:

– **Allocating overhead to products or batches**: Using drivers such as machine hours, labor hours, or material usage to assign factory overhead to production orders or product lines.
– **Assigning costs to cost centers**: Splitting expenses like utilities, calibration, or IT infrastructure across production areas, labs, warehouses, or support departments.
– **Linking operational data to financials**: Using shop-floor data (runtime, downtime, scrap, rework, test time) from MES, OT systems, or quality systems to support more granular allocation of costs.
– **Regulatory and internal reporting**: Providing traceable, auditable cost breakdowns by product family, site, or process segment for internal management reporting and, where required, regulated cost reporting.

Scope, inclusions, and exclusions

Included under cost allocation:

– Distribution of **indirect costs** (overhead) to cost objects (products, lines, departments).
– Distribution of **shared direct costs** (for example, a shared packaging line) among multiple products or customers.
– Use of **allocation bases or drivers**, such as:
– Machine time or capacity usage
– Labor hours or headcount
– Floor space
– Volume or weight of material processed

Typically excluded or distinct from cost allocation:

– **Cost determination**: Calculating the total amount of a cost (e.g., total energy bill) before it is allocated.
– **Costing methodology selection**: Choosing between standard costing, actual costing, activity-based costing (ABC), or lean accounting approaches. Cost allocation can exist under any of these methodologies.
– **Pricing decisions**: Using allocated costs to set prices. Pricing uses cost allocation outputs but is a separate commercial activity.

Relationship to manufacturing and information systems

Cost allocation often depends on accurate data from operational systems:

– **MES and OT systems** may provide actual machine hours, cycle counts, scrap quantities, and changeover times used as allocation drivers.
– **Maintenance systems (CMMS/EAM)** can supply asset-level maintenance costs and downtime for allocation to lines or products.
– **Quality systems (QMS, LIMS)** can contribute data on inspection effort, testing time, and nonconformance handling for allocation to products, batches, or customers.
– **ERP systems** usually perform the allocation calculations using configuration of cost centers, cost elements, and allocation rules, and then feed results to financial and management reporting.

In regulated environments, traceability of cost allocation rules, versioning of drivers, and documentation of changes is often expected to ensure that reported product costs can be reconstructed and justified.

Common confusion and related terms

Cost allocation is sometimes confused with:

– **Cost apportionment**: A broader term for splitting costs that may include both direct and indirect components. In many industrial finance practices, apportionment is used for the initial separation of costs, and allocation for assigning them to final cost objects, but the distinction is not universal.
– **Activity-based costing (ABC)**: A costing methodology that uses activities and cost drivers. Cost allocation is a mechanism within ABC but can also be used with simpler methods (for example, allocating based on labor hours only).
– **Budget allocation**: Distribution of planned or budgeted funds to departments or projects. This is forward-looking, while cost allocation generally concerns incurred costs.

Being precise about the cost object (product, batch, line, department) and the allocation driver (time, volume, headcount, etc.) helps reduce ambiguity when discussing cost allocation in industrial operations.

April 13, 2026
Use Case

Core meaning

A **use case** is a structured description of how a user, role, or external system interacts with a system to achieve a specific goal in a defined context. It typically captures:

– The actor (person, role, or external system) initiating the interaction
– The goal or outcome the actor wants to achieve
– The main sequence of interactions between actor and system
– Alternate or exception paths when things do not follow the main flow
– Preconditions and postconditions that define when the use case starts and ends

Use cases are widely used in requirements analysis, system design, and solution evaluation.

Use in industrial and manufacturing environments

In industrial operations and regulated manufacturing, a use case commonly refers to a concrete operational or information flow scenario, such as:

– A quality engineer recording a nonconformance in a QMS and triggering a corrective action workflow
– An operator starting a production order in an MES and reporting material consumption and downtime
– An automated test bench sending test results to an SPC or data historian system
– An ERP system requesting real-time WIP status from an MES for ATP (available-to-promise) calculations

These use cases may be documented at different levels of detail, ranging from high-level business scenarios (e.g., “Release a batch record for production”) to detailed system interactions (e.g., message exchanges between MES and PLCs).

Structure and documentation

Use cases in this domain are often represented using:

– **Textual descriptions**: Narrative or table-based format listing actor, triggers, main flow, alternate flows.
– **Diagrams**: UML use case diagrams or system context diagrams to show actors and their relationships to systems.
– **Scenarios or stories**: Concrete examples of how a shift, batch, or order is run using specific systems.

They may be grouped into use case catalogues for an MES, QMS, LIMS, historian, or other OT/IT platform.

Boundaries and exclusions

A use case:

– **Is not** the same as a process map, although a process map may contain multiple use cases.
– **Is not** a full functional specification; it describes interactions and goals, but not all technical details.
– **Is not** limited to software; it can cover interactions with equipment, manual steps, and paper artifacts, as long as they relate to a defined goal.

In regulated environments, use cases may inform but do not replace validation documentation, test cases, or formal procedures.

Common confusion and related terms

– **Use case vs. user story**: A user story is a brief, informal requirements statement (e.g., “As a line supervisor, I want to see OEE by shift…”). A use case is more structured and details interaction flows.
– **Use case vs. business case**: A business case explains why an initiative is undertaken (costs, risks, expected value). A use case explains how the solution will be used to achieve specific operational goals.
– **Use case vs. test case**: A test case is a specific, step-by-step test to verify a requirement. A use case provides the scenario from which many test cases can be derived.

Site-context application

On this site, use cases are generally discussed in relation to:

– Designing and selecting MES, QMS, LIMS, historian, and other OT/IT systems
– Describing interactions across ISA-95 style levels (ERP, MES, control, equipment)
– Clarifying how manufacturing, quality, maintenance, and regulatory workflows are supported by integrated systems

Use cases serve as a neutral way to describe these interactions without prescribing a specific product or implementation approach.

April 13, 2026
MES vs ERP boundary

Core meaning

The **MES vs ERP boundary** commonly refers to the practical and conceptual dividing line between:

– **Manufacturing execution systems (MES)**, which coordinate and monitor production on the shop floor, and
– **Enterprise resource planning (ERP)** systems, which plan and manage enterprise‑level resources, finance, and high‑level supply chain activity.

It describes which data, decisions, and workflows are handled by MES versus ERP, and where handoffs occur between the two.

Typical scope on the MES side

In industrial and regulated manufacturing environments, the boundary usually places the following activities predominantly in **MES**:

– **Executing production orders**:
– Breaking down planned orders into detailed operations, sequences, and work instructions
– Dispatching work to specific lines, machines, or work centers
– **Real‑time shop floor control**:
– Tracking work in process (WIP) by unit, lot, or batch
– Capturing start/stop, downtimes, and actual cycle times
– Enforcing process parameters and routings
– **Production data collection**:
– Recording material consumption and yields at operation or batch level
– Capturing operator inputs, machine signals, and alarms
– **Quality and compliance execution**:
– In‑process inspections, sampling, and test results
– Electronic batch records / device history records, deviations, and e-signatures as implemented in MES or adjacent systems
– **Equipment and resource usage**:
– Machine status, availability, and utilization
– Tooling and fixture tracking, cleaning or sterilization cycles, and line clearance where implemented in execution layer

Typical scope on the ERP side

The same boundary typically puts the following activities predominantly in **ERP**:

– **Planning and commitments**:
– Demand planning, master production scheduling, and material requirements planning (MRP)
– Long‑horizon capacity planning and resource loading at plant or work-center level
– **Order management and fulfillment**:
– Customer orders, pricing, and delivery commitments
– Creation and closure of production orders at a commercial or financial level
– **Inventory and costing**:
– Valuated inventory, general ledger integration, and cost of goods manufactured/sold
– Standard costs, variances, and financial settlement
– **Procurement and supply chain**:
– Purchase requisitions, purchase orders, and supplier management
– Inter‑plant transfers and overall distribution planning
– **Enterprise governance data**:
– Chart of accounts, financial consolidation, and corporate reporting
– Company‑wide master data policies and approval flows

Common handoff points across the boundary

Organizations typically define a few key handoffs between MES and ERP across this boundary:

– **Order release**:
– ERP issues or schedules a production order (or batch order).
– MES receives and elaborates it into detailed operation steps and work instructions.
– **Material and inventory updates**:
– ERP holds the official, valuated inventory and item master data.
– MES posts consumption and production quantities back to ERP, often summarized by order, lot, or time bucket.
– **Status and progress**:
– MES tracks detailed WIP status and machine‑level progress.
– ERP receives aggregated status (e.g., order started, 50% complete, completed, closed).
– **Quality results**:
– MES (or a quality execution layer) captures in‑process quality tests and non‑conformances.
– ERP often receives key quality dispositions (e.g., accepted, rejected, blocked) for inventory and financial impact purposes.

The exact location of these handoffs varies by implementation and by how tightly MES and ERP are integrated.

Variability and gray areas

In practice, the MES vs ERP boundary is not absolute. Implementations differ due to system capabilities, legacy solutions, and regulatory expectations. Gray areas often include:

– **Detailed scheduling**:
– Some organizations perform finite, sequence‑level scheduling within MES or a dedicated APS (advanced planning and scheduling) tool.
– Others rely on ERP for detailed scheduling, with MES focused on execution only.
– **Quality management**:
– ERP may host high‑level quality records and quality management processes (e.g., complaints, audit findings).
– MES or specialized LIMS/QMS systems manage execution‑time tests, sampling, and data capture.
– **Maintenance activities**:
– An enterprise asset management (EAM/CMMS) module in ERP may own work orders and costs.
– MES or shop floor systems may trigger and record actual machine downtime, minor maintenance, or setups.

For regulated industries, validation and data integrity considerations may influence where functionality is placed relative to the MES–ERP boundary.

Relationship to standards and reference models

Industry reference models, such as ISA‑95, are often used to discuss the MES vs ERP boundary:

– ERP is generally aligned with higher‑level business planning and logistics activities.
– MES is positioned closer to production operations, detailed scheduling, and execution.

Implementers use such models to describe which functions reside in which layer, but actual system boundaries still depend on local design decisions.

Common confusion and misuse

Because the boundary is implementation‑specific, several misconceptions appear frequently:

– **”MES is just a data collector”** – While MES collects data, the term boundary usually includes decision and control functions (dispatching, enforcement) in MES, not just logging.
– **”ERP can replace MES entirely”** – Some ERP products expose execution‑type features, but the MES vs ERP boundary concept still distinguishes transactional planning from real‑time control, even if both are implemented in one platform.
– **”The boundary is fixed by product labels”** – Vendor branding does not strictly define the boundary. A system sold as “MES” may include planning features, and an ERP add‑on may include execution functions. The boundary refers to functional roles, not product names.

Usage in manufacturing discussions

In industrial operations, the phrase **MES vs ERP boundary** is used when:

– Defining integration interfaces and data models between shop floor and enterprise systems
– Clarifying which team (operations/OT vs IT/enterprise applications) owns specific workflows and data
– Assessing whether new functionality should be implemented in MES, ERP, or another layer
– Describing scope for system replacement or digital transformation projects

The term is descriptive: it captures how responsibilities are divided between MES and ERP in a particular manufacturing environment, rather than prescribing a single correct division.

April 13, 2026
historian

Core meaning

In industrial and manufacturing environments, a **historian** is a specialized time‑series database and software system used to collect, store, compress, and retrieve time‑stamped operational data. It typically ingests high‑frequency data from control systems, field devices, and sensors, and makes this data available for analysis, reporting, and integration with other systems.

A historian commonly stores:

– Process values (flows, temperatures, pressures, levels, speeds)
– Equipment and asset status signals (run/stop, modes, alarms)
– Calculated or aggregated metrics (averages, totals, KPI trends)
– Event time stamps associated with process changes or states

Role in manufacturing and operations

In manufacturing, a historian is used to:

– Capture continuous and batch process data from PLCs, DCS, SCADA, and IoT gateways
– Provide trend and replay views for engineers, operators, and maintenance
– Supply historical signals to analytics, predictive maintenance models, and reporting tools
– Support investigations of deviations, quality issues, and equipment problems through historical traces

Data in the historian is usually organized by tags or points, each representing a specific signal from a device or system. The system often provides compression, buffering, and backfilling to manage large volumes of time‑series data while maintaining performance.

Boundaries and what a historian is not

A historian:

– **Is** a time‑series data infrastructure component focused on time‑stamped operational values
– **Is not** a full Manufacturing Execution System (MES) or ERP and typically does not manage orders, routes, or operators
– **Is not** a general relational database for transactional business data
– **May integrate with** MES, CMMS, LIMS, quality systems, and analytics platforms but does not replace their workflow or business logic

Historians usually store data with minimal business context (for example, “Tag 101: reactor temperature”), while systems like MES or ERP add product, batch, order, and schedule context on top of that raw data.

Common confusion and related terms

– **Historian vs. MES**: A historian stores time‑series signals; MES manages production execution, work orders, and contextual information such as product, route, and operator.
– **Historian vs. SCADA**: SCADA focuses on real‑time monitoring and control; a historian focuses on long‑term storage and retrieval of time‑stamped data. Many SCADA systems embed or connect to a historian.
– **Historian vs. CMMS**: CMMS manages maintenance work, assets, and records; a historian provides operational data that maintenance teams may use for diagnostics or analytics.

Use in predictive maintenance (site context)

For predictive maintenance, historians commonly serve as a primary data source. Models can be trained on and run from historical process and equipment signals (vibration, temperature, current, throughput, etc.) without requiring MES data. However, when historian data is combined with MES or other context sources, organizations can link predicted failures or anomalies to specific products, lots, routes, and schedules, which supports more precise root cause analysis and traceability in regulated environments.

April 13, 2026
IIoT
IIoT stands for Industrial Internet of Things. It commonly refers to the network of connected industrial assets, sensors, control systems, and software platforms that collect, transmit, and use data in manufacturing and other industrial environments.

Core meaning

In industrial operations, IIoT typically includes:
- Physical devices and assets, such as machines, production lines, utilities equipment, and environmental sensors
- Embedded or add-on sensors and edge devices that capture data like temperature, vibration, pressure, status, and production counts
- Industrial networks and protocols used to move data between equipment, local gateways, OT systems, and higher-level IT systems
- Software platforms that store, process, and analyze data, often integrating with MES, ERP, quality, and maintenance systems
IIoT focuses on industrial and operational contexts. It is typically associated with OT (operational technology) environments such as factories, process plants, and warehouses, rather than consumer devices.

How IIoT shows up in manufacturing workflows

Within regulated and complex manufacturing, IIoT commonly appears as:
- Connected machines streaming production and status data into MES or data historians
- Condition monitoring and predictive maintenance solutions reading sensor data from assets
- Energy, utilities, or environmental monitoring systems that feed compliance and performance reports
- Edge gateways that securely connect PLCs and controllers to cloud or on-premise analytics platforms
- Integration points that bridge OT data with quality systems, traceability tools, and ERP planning data
IIoT is often mentioned alongside frameworks such as Industry 4.0 and reference architectures that describe how connected assets, data layers, and business processes align.

What IIoT is not

IIoT is not a single product or a specific standard. It is a general concept and ecosystem that can include multiple vendors, protocols, and architectures. It also does not, by itself, imply any particular level of cybersecurity, compliance, or data governance. Those aspects depend on how IIoT solutions are designed and operated.

Common confusion
- IIoT vs IoT: IoT (Internet of Things) is a broader term covering all connected devices, including consumer and smart home devices. IIoT refers specifically to industrial and operational environments, with stronger emphasis on reliability, integration with control systems, and alignment with industrial standards.
- IIoT vs Industry 4.0: IIoT is one of the enabling technologies used within Industry 4.0 initiatives. Industry 4.0 is a wider concept covering digitalization of manufacturing, including IIoT, advanced analytics, digital twins, and integration across business processes.
- IIoT vs MES/SCADA: MES and SCADA are established system categories with defined roles in production control and monitoring. IIoT platforms often complement these systems by providing additional connectivity, data aggregation, and analytics, but do not always replace them.
Relation to reference architectures

In architectural models used for Industry 4.0, IIoT elements typically appear at the asset and integration layers, linking physical equipment and sensors to information systems, analytics, and business processes across the production lifecycle and organizational hierarchy.
April 13, 2026
Systems integration
Systems integration commonly refers to the practice of connecting separate software, hardware, and automation systems so they can exchange data and operate as a coordinated whole. In industrial and regulated manufacturing environments, it focuses on enabling reliable, traceable information flows across enterprise IT systems and operational technology (OT) on the shop floor.

What systems integration includes

In a manufacturing context, systems integration typically covers:
- Linking enterprise systems such as ERP, PLM, and quality management systems (QMS) with manufacturing execution systems (MES) and plant-floor control systems
- Connecting OT assets, such as PLCs, DCS, SCADA, historians, and data acquisition systems, to higher-level operations and analytics platforms
- Defining and implementing interfaces, data models, and message formats so that systems can exchange information in a consistent and controlled way
- Implementing middleware, integration platforms, or APIs to manage data routing, transformations, and orchestration between systems
- Managing identity, access, and audit trails related to data exchanges, especially in regulated environments
Systems integration addresses both the technical connectivity (networks, protocols, APIs) and the semantic alignment of data (consistent definitions for materials, equipment, batches, and process parameters).

Operational meaning in manufacturing

Operationally, systems integration shows up as automated workflows that span multiple systems. Examples include:
- Transferring production orders from ERP to MES and returning actuals such as quantities, scrap, and consumption
- Feeding process data from equipment or historians into MES or QMS for real-time monitoring, deviation management, or electronic batch records
- Synchronizing master data such as materials, recipes, routings, and equipment hierarchies across ERP, MES, and plant control layers
- Exchanging information between manufacturing systems and business intelligence or operations intelligence platforms for reporting and analysis
Standards such as IEC 62264 and ISA-95 provide reference models and terminology to support systems integration between enterprise systems and manufacturing operations systems, but they do not by themselves guarantee interoperability. Each integration still requires design, mapping, and validation.

What systems integration is not
- It is not a single product or software application. It is a practice and result of combining multiple systems via defined interfaces and data models.
- It is not limited to data migration. Ongoing, bidirectional data exchange and coordination of processes are usually in scope.
- It is not the same as process reengineering, although integration projects often trigger process and data governance changes.
Common confusion
- Systems integration vs. interoperability: Systems integration is the project or activity of connecting specific systems in a specific environment. Interoperability is the capability of systems to work together, often leveraging standards. A plant can use standards and still require custom integration work.
- Systems integration vs. interface development: An interface is a specific technical connection between two systems. Systems integration is broader and covers how multiple interfaces and systems work together to support end-to-end processes.
Link to IEC 62264 context

In the context of IEC 62264, systems integration refers to implementing the standard’s models and terminology to connect enterprise systems (such as ERP) with manufacturing operations systems (such as MES and control systems). The standard provides a common reference for structuring and naming information, which can simplify integration design and communication between IT and OT teams, but the actual integration still depends on plant-specific implementation and validation.
April 13, 2026
reference architecture
A reference architecture is a structured, technology-agnostic blueprint that describes the key components, layers, relationships, and interfaces within a particular problem domain or class of systems. It provides a common map for how things are organized, but does not prescribe a single product, vendor, or implementation.

Key characteristics

In industrial and manufacturing environments, a reference architecture commonly:
- Defines logical layers (for example, physical assets, control systems, MES, enterprise systems, business processes)
- Describes standard interfaces and data flows between OT and IT systems
- Organizes concerns such as security, data models, and lifecycle management
- Aligns with existing standards where possible, without duplicating them
- Is technology-agnostic and does not mandate particular vendors or products
A reference architecture is typically used to:
- Provide a shared vocabulary for engineering, operations, quality, and IT teams
- Support comparison and selection of system designs against a known structure
- Identify integration points between MES, ERP, PLM, historians, and shop-floor systems
- Guide long-term modernization, such as Industry 4.0 initiatives, without dictating detailed designs
Operational meaning in manufacturing

Within regulated manufacturing, a reference architecture commonly appears as:
- Architecture diagrams showing how equipment, PLCs, SCADA, MES, LIMS, QMS, ERP, and analytics platforms connect
- Layered models that separate field devices, control, supervision, operations management, and business planning
- Standardized patterns for data collection, traceability, and audit evidence flow across systems
- Supporting material for internal governance, change impact assessment, and validation planning
It is a planning and communication tool, not an implementation specification. Individual plants or programs adapt it into detailed solution architectures and system designs that reflect specific technologies, vendors, and constraints.

Relation to RAMI 4.0 and other models

RAMI 4.0 (Reference Architectural Model Industry 4.0) is an example of a reference architecture that organizes Industry 4.0 concepts across layers, lifecycle stages, and hierarchical levels. Similar roles are played by:
- ISA-95 models that structure integration between control, MES, and ERP levels
- Reference architectures for industrial IoT or edge computing that describe connectivity and data management patterns
These models offer structured views and terminology that teams can use to align designs and discussions. They do not, by themselves, guarantee regulatory compliance, cybersecurity, or interoperability.

What a reference architecture is not

To avoid confusion, a reference architecture is not:
- A detailed system design or configuration specification
- A validated or approved implementation
- A complete standard operating procedure or work instruction
- A compliance certificate or proof that a system meets regulatory requirements
Common confusion
- Reference architecture vs. solution architecture: A reference architecture is generic and reusable across multiple projects or sites. A solution architecture is specific to a particular implementation, technology stack, and environment.
- Reference architecture vs. standard: A standard defines formal requirements or rules. A reference architecture provides structured guidance and examples, and may reference standards, but is not itself a binding requirement.
April 13, 2026
How does Connect 981 improve work order control without replacing our existing ERP or MES?
Connect 981 improves work order control by acting as an execution and orchestration layer between your existing ERP and MES and the shop floor. It does not replace planning or core transaction systems. Instead, it uses data from those systems to provide clearer, more granular control of work orders where the work is actually performed.

How it improves work order control

Connect 981 commonly enhances work order control in the following ways:
- Digitized dispatch and routing: Translates ERP or MES work orders into clear, step-by-step tasks at each workstation, cell, or line without changing how orders are created in the source system.
- Real-time status and progress: Captures start, stop, completion, and hold events directly from operators or connected equipment so supervisors see actual progress instead of waiting for batch updates or manual reporting.
- Standard work and instructions at the point of use: Links operations in the work order to controlled work instructions, checklists, and data collection forms so each step is executed consistently and documented.
- Integrated data capture and traceability: Records who did what, when, on which equipment, with which materials, and under which revision of instructions, then associates this information back to the originating work order.
- Constraint and exception handling: Provides a structured way to pause, re-route, or adjust work when materials, tools, or approvals are missing, reducing ad hoc workarounds that ERP or MES do not fully capture.
- Feedback loop to planning systems: Shares actual cycle times, yields, and issues so planning and scheduling in ERP or MES can be refined using current performance data.
How it works with, not instead of, ERP and MES

Connect 981 is typically implemented as a complementary layer:
- ERP remains the system of record for customer orders, master data, MRP, costing, and financial postings.
- MES (if present) remains the core execution backbone for routing logic, electronic batch records, or enforcement rules where it is already deployed.
- Connect 981 focuses on usability and coverage in areas where ERP or MES are too rigid, too complex to configure for high-mix environments, or not fully deployed on the shop floor.
This approach avoids a rip-and-replace project. Instead, Connect 981 leverages existing investments and fills practical execution gaps such as operator guidance, local work order re-prioritization, and consistent data capture across diverse lines or sites.

Example in a regulated manufacturing environment

In a regulated plant, ERP may issue work orders and an MES may manage certain validated processes. Connect 981 can:
- Pull work order and routing details from ERP or MES.
- Present operators with controlled digital instructions and required checks at each step.
- Capture electronic signatures, inspection results, and material usage directly against the work order.
- Return summary execution data and exceptions so ERP and MES records remain complete without redesigning those systems.
The result is tighter work order control, improved visibility, and better evidence for audits, all achieved by integrating with existing systems rather than replacing them.
April 13, 2026
Integration Architecture

Core concept

Integration architecture commonly refers to the high-level design of how multiple software and hardware systems exchange data and services within and across organizations. It defines the patterns, technologies, and structural choices used to connect systems such as ERP, MES, LIMS, SCADA, historians, quality systems, and external partner platforms.

In industrial and manufacturing environments, integration architecture focuses on how OT systems on the shop floor interact with IT systems in the enterprise layer, while respecting security, performance, and compliance constraints.

Key elements

Typical elements of an integration architecture include:

– **Integration styles and patterns**
– Point-to-point interfaces
– Hub-and-spoke or broker-based models
– Enterprise service bus (ESB) designs
– API- and event-driven architectures
– File-based and message-queue-based exchanges

– **Integration technologies and components**
– Middleware, message brokers, or ESBs
– API gateways and REST/SOAP services
– Industrial protocols (e.g., OPC UA, MQTT in OT contexts)
– Adapters and connectors for specific systems (ERP, MES, LIMS, PLCs)
– Data transformation and mapping components

– **Information and data flow design**
– Which systems act as sources of record for each data domain
– Direction, frequency, and criticality of data flows
– Synchronous vs. asynchronous communication patterns
– Data formats and canonical data models where used

– **Cross-cutting concerns**
– Security and access control across interfaces
– Monitoring, logging, and traceability of transactions
– Error handling and retry behaviors
– Versioning and change management of interfaces
– Performance, latency, and throughput expectations

Usage in industrial and regulated environments

In manufacturing and other regulated industries, integration architecture is often documented and reviewed to ensure:

– **Separation and controlled interaction of IT and OT**: For example, clearly defined zones and conduits between plant networks, MES, and corporate ERP.
– **Traceable exchange of regulated data**: Such as quality results, batch records, electronic device history records, or serialization data moving between shop-floor systems and quality or regulatory reporting systems.
– **Alignment with reference models**: Many organizations informally align integration architecture with frameworks such as ISA-95 levels (e.g., integration between Level 2/3 systems and Level 4 systems), without implying any certification.

Integration architecture diagrams are frequently used to:

– Communicate how MES, ERP, SCADA, historians, quality systems, and data lakes are connected.
– Show which services or APIs expose master data, production orders, or quality results.
– Document how external parties (e.g., contract manufacturers or logistics providers) exchange data with internal systems.

Boundaries and exclusions

Integration architecture is distinct from, but related to, other architectural views:

– **Not the same as application architecture**: Application architecture focuses on the internal structure of a specific system (modules, layers, components). Integration architecture focuses on how separate systems communicate.
– **Not limited to a single tool or middleware product**: It describes the overall integration design, which may use multiple tools, custom code, and protocols.
– **Not only network architecture**: While it depends on underlying networks, it is primarily concerned with logical interfaces and data flows, not with detailed switch, router, or VLAN design.

Common confusion and related terms

– **Integration vs. interface**: An interface is a specific connection or API between two systems. Integration architecture describes the overall strategy and pattern for many such interfaces across the landscape.
– **Integration architecture vs. enterprise architecture**: Enterprise architecture is broader and covers business, application, data, and technology architectures. Integration architecture is one focused view within that wider scope.
– **Integration architecture vs. data architecture**: Data architecture defines data models, domains, and governance; integration architecture defines how data moves between systems and how those systems interact.

Site context: role in manufacturing systems

Within the context of manufacturing and industrial operations, integration architecture often addresses:

– How production orders and master data move from ERP to MES and then to shop-floor control systems.
– How equipment data, alarms, and process parameters flow from OT assets and SCADA into historians, MES, and analytics platforms.
– How quality and compliance data (e.g., test results, deviations, batch records) are exchanged between MES, LIMS, QMS, and regulatory reporting tools.
– How cloud-based analytics or operations-intelligence platforms consume and publish data in a controlled and auditable way.

In regulated environments, this architecture is typically documented with enough detail to support impact assessment, change control, and periodic review of connected systems.

April 13, 2026