A production monitoring system that was designed without a clear architecture is not a system — it is an accumulation. An OPC UA connection added when the MES arrived, a historian installed when someone wanted trending, a dashboard bolted on when management asked for visibility, three different edge devices from three different vendors sitting under the line because three different projects deployed them at three different times. The result is a monitoring environment that nobody fully understands, that nobody can extend without risk, and that produces data in formats nobody agreed on. Designing production monitoring architecture correctly from the start — or re-architecting what already exists — is the work that separates plants with genuine visibility from plants with an impressive number of screens. Book a session with the iFactory architecture team to review your current monitoring stack and identify the highest-leverage structural improvements.
Production Monitoring System Architecture — Five-Layer Reference Model
From PLC Signal to Management Dashboard: The Complete Architecture Stack for End-to-End Production Visibility
Every production monitoring system — regardless of vendor, protocol, or scale — must solve the same five technical problems. This reference defines the architecture layers, the decisions made at each layer, and the integration standards that connect them.
L5
Application Layer
Dashboards · KPI reporting · AI analytics · ERP/MES integration · Role-based access
REST API · MQTT broker · OData · Webhooks
L4
Platform Layer
Historian · Time-series DB · Unified namespace · Data quality · Model registry
MQTT Sparkplug B · OPC UA pub/sub · AMQP
L3
Edge Layer
Edge compute · Protocol translation · Local buffering · AI inference · Pre-aggregation
OPC UA · Modbus TCP · PROFINET · EtherNet/IP
L2
Control Layer
PLC · SCADA · DCS · HMI · Safety system · Motion controller
4–20mA · 0–10V · Pulse · IO-Link · Wireless HART
L1
Field Layer
Sensors · Actuators · Cameras · Encoders · Flow meters · Vibration probes
Why Architecture Decisions Are Irreversible
The Four Structural Mistakes That Create Monitoring Debt — and How to Avoid Them
Production monitoring architecture decisions made during deployment are functionally irreversible without a significant rework programme. A historian installed on the wrong server cannot be easily moved once 30,000 tag paths are hardcoded into dashboards. A flat OT network without VLAN segmentation cannot be properly secured without a scheduled downtime window touching every device on the network. An edge device with proprietary protocol output locks every future application to a single vendor's integration layer. These are not theoretical risks — they are the accumulated technical debt of plants that designed monitoring system by system rather than architecture first.
01
Flat OT Network
All PLCs, HMIs, historians, and monitoring devices on the same broadcast domain. Created because it is simple to set up and easy to troubleshoot. Prevents security segmentation, allows any compromised device to reach any other, and forces network redesign when Purdue-model compliance or IEC 62443 certification is required. Fix requires downtime-scheduled reconfiguration of every network device.
02
Proprietary Protocol Lock-in
Edge devices or MES platforms that output data in vendor-specific formats rather than OPC UA or MQTT Sparkplug B. Appears harmless at deployment. Becomes critically limiting when a new analytics platform, historian, or dashboard vendor is selected — requiring full re-integration from each data source through a proprietary adapter that the original vendor controls and licenses.
03
No Unified Namespace
Data from each machine stored under a different tag naming convention, in different historian instances, or in incompatible formats. The consequence: every application that needs data from more than one machine requires bespoke data pipeline development. Cross-machine analytics — OEE calculation, line-level throughput, multi-asset predictive maintenance — become expensive engineering projects rather than configuration tasks.
04
Edge Without Buffering
Edge devices that stream data directly to the cloud or historian without local buffering. Works well in normal operation. On network interruption — which is routine in industrial environments — all data from the interruption period is permanently lost. In OEE monitoring, a 15-minute network outage that coincides with a production stoppage creates a gap in the availability data that corrupts the shift OEE calculation.
Layer 1 — Field
Sensor Selection and Deployment: What to Measure, Where to Measure It, and How to Wire It
The field layer is where monitoring architecture meets physical reality. Sensor selection, placement, and signal conditioning at this layer determine the data quality available to every layer above. A well-chosen sensor improperly placed produces worse data than a mediocre sensor well placed. The principle governing field layer design is: measure the process variable that is closest to the failure mode or KPI you care about — not the variable that is easiest to instrument.
| Measurement Type | Signal Standard | Typical Resolution | Key Placement Rule | Common Error |
|---|---|---|---|---|
| Vibration (bearing/shaft) | 4–20mA / IEPE / IO-Link | ±0.1 g to ±50 g, 1–20 kHz | Mounting on bearing housing, in load zone, shortest path to bearing | Mounting on frame — attenuates high-frequency bearing fault signal |
| Temperature (winding/bearing) | PT100 / TC type K or J / 4–20mA | ±0.1°C to ±1°C | Contact or embedded — not surface clip-on for precision measurement | Ambient temperature not compensated — produces false alarms in seasonal variation |
| Pressure (hydraulic/pneumatic) | 4–20mA / IO-Link | ±0.1% to ±0.5% FS | At actuator port — not at pump outlet (pipeline losses obscure true load) | Single point measurement — misses pressure drop that indicates flow restriction |
| Flow (cooling / process fluid) | 4–20mA / pulse / HART | ±0.5% to ±2% FS | 5× pipe diameter straight run upstream, 2× downstream | Installation in turbulent zone — ±15% measurement error from upstream fitting |
| Current (motor load) | CT / 4–20mA / Modbus | ±0.5% to ±1% rated | Single-phase measurement per leg — imbalance detection requires all three | Single-leg CT — misses phase imbalance that indicates winding or rotor fault |
| Vision (quality / presence) | GigE Vision / USB3 Vision | Application-specific | Lighting design before camera selection — lighting determines image quality | Camera selected before lighting designed — image quality compromised structurally |
Layer 2 — Control
PLC Integration for Monitoring: What to Extract, What Not to Touch, and How to Do It Safely
PLC integration for monitoring is one of the highest-risk steps in production monitoring deployment — not because the technology is difficult, but because the consequences of errors are immediate and production-impacting. A monitoring system that inadvertently writes to a PLC output register, saturates the PLC communication processor with polling requests, or introduces a network-level fault that takes down the control network will halt production. The integration must be read-only, rate-limited, and isolated from the control function at the network level.
OPC UA Server (Built-in)
Modern PLCs (Siemens S7-1500, Allen-Bradley ControlLogix 5380, B&R Automation PC) include built-in OPC UA servers. The monitoring system connects as an OPC UA client, subscribing to tag values at a defined publish interval. This is the preferred integration method — it uses the PLC manufacturer's own protocol implementation, requires no additional hardware, and allows the PLC to control the data publication rate independently of monitoring system polling.
Best practice: Set OPC UA publish interval to 500ms–2s for monitoring (not 100ms — avoid saturating PLC comm processor)
Passive Tap / Network Mirror
For PLCs without OPC UA and where adding a communication load is not acceptable, a passive network tap mirrors PROFIBUS or PROFINET traffic to a monitoring gateway that decodes the protocol passively. The PLC never knows the monitoring system exists — zero change to PLC program, zero additional communication load. The limitation is that only data actively being communicated between PLC and SCADA/HMI is visible; internal PLC data blocks not on the network are not accessible without program modification.
Best practice: Use on legacy PLCs where program modification is not permitted — accept limited tag visibility as the trade-off
Edge Gateway with Protocol Translation
An edge gateway device connects to the PLC using its native protocol (Modbus RTU, EtherNet/IP, S7 communication) and translates to OPC UA or MQTT for the monitoring platform. This approach handles legacy protocols and mixed-vendor environments. The critical configuration requirement is rate limiting on the edge gateway's polling of the PLC — uncontrolled polling has caused PLC processor overloads in several documented incidents where monitoring systems were connected without coordination with the controls engineering team.
Best practice: Coordinate polling rate with controls engineer — document maximum PLC comm load as a constraint before configuring
Read-Only Isolation — Non-Negotiable
Regardless of integration method, the monitoring system must be read-only at the PLC interface — enforced at the network level by a DMZ firewall that permits OPC UA reads from the monitoring network to the control network but blocks all write traffic. Software-level read-only settings in the monitoring platform are insufficient — they can be misconfigured. Network-level enforcement cannot be accidentally bypassed. This is an IEC 62443 requirement and a basic operational safety principle.
Mandatory: DMZ firewall between control network and monitoring network — read traffic only, stateful inspection, logged
Layer 3 — Edge
Edge Computing Architecture: What Belongs at the Edge and What Belongs in the Cloud
The edge layer is where the most consequential architecture decisions are made — and where the most consequential mistakes occur. Over-centralising (sending all raw data to the cloud) creates latency, bandwidth, and data volume problems. Over-edging (doing all analytics at the edge) creates maintenance, model deployment, and cross-asset analytics problems. The correct partition is determined by latency requirement and data reduction ratio — not by a general preference for cloud or edge.
Belongs at the Edge
Sub-100ms decisions
Vision inspection pass/fail, emergency stop triggers, quality gate decisions that must complete before the part moves. Cloud round-trip latency (50–200ms) is too slow for control-adjacent AI.
Data reduction
High-frequency raw signals (vibration at 25.6 kHz, camera frames at 60 fps) must be processed to features or events at the edge — sending raw data to cloud is a 100–1,000× bandwidth multiplication that is unnecessary if the right features are extracted locally.
Local buffering
Store-and-forward buffer for network interruptions. Edge devices should buffer a minimum of 24 hours of compressed data per connected machine — preventing data gaps on historian during network maintenance or failure.
Protocol translation
Convert legacy field protocols (Modbus RTU, PROFIBUS DP, BACnet) to OPC UA or MQTT Sparkplug B before the data leaves the plant floor network zone.
Belongs in the Platform (Cloud/On-Premise)
Cross-asset analytics
OEE calculation, line-level throughput, multi-machine correlation, and fleet-level predictive maintenance require data from multiple assets that may be on different edge devices — only the platform layer has the complete dataset.
Long-term storage and trending
12+ months of historical data for trend analysis, seasonal pattern detection, and ML model training. Edge devices do not have cost-effective storage for this volume.
Model training
ML model training on historical datasets requires compute resources beyond what industrial edge devices provide. Train in the platform, deploy inference models to the edge.
ERP and MES integration
Production order context, material traceability, quality record creation, and maintenance work order generation require connection to enterprise systems that belong in the platform layer, not the edge.
Architecture Review Available
iFactory Reviews Your Current Monitoring Stack and Identifies the Structural Changes That Will Have the Highest Impact on Data Quality and Coverage
Most plants have monitoring systems that were deployed layer by layer over years without an overall architecture decision. iFactory's architecture review maps your current stack against the five-layer reference model, identifies structural gaps and technical debt, and produces a prioritised improvement roadmap with implementation cost and timeline estimates.
Layer 4 — Platform
The Unified Namespace and Time-Series Platform: The Architecture Decision That Determines Everything Else
The platform layer is where data from all field, control, and edge layers is collected, standardised, stored, and made available to applications. The single most important design decision in this layer — and arguably in the entire monitoring architecture — is the tag naming standard that defines how every data point is identified in the unified namespace. A well-designed unified namespace means that any application can find any data point from any machine using a predictable addressing scheme. A poorly designed one means that every new application requires a bespoke data mapping exercise against an inconsistent tag library.
Unified Namespace Design
The ISA-95 asset model provides the standard hierarchy: Enterprise → Site → Area → Line → Cell → Equipment → Tag. A unified namespace built on this hierarchy addresses data as: Enterprise/Site/Area/Line/Cell/Equipment/Tag — for example, Plant1/Assembly/Zone3/Line4/Cell2/Motor_A/BearingTemp_DE. Any system that subscribes to this namespace can find the bearing temperature of the drive end bearing of Motor A on Cell 2 of Line 4 in Zone 3 without a custom mapping file. This addressing scheme should be defined before the first monitoring device is configured — not after.
Time-Series Database Selection
Production monitoring data is time-series by nature — every measurement has a timestamp and a value. Standard relational databases perform poorly at time-series workloads (high-frequency inserts, time-range queries, data compression). Purpose-built time-series databases (InfluxDB, TimescaleDB, OSIsoft PI, Aveva Historian) provide 10–100× better storage efficiency and query performance for monitoring workloads. The database selection must account for: tag count (number of monitored signals), data rate (samples per second per tag), retention period (how many months of full-resolution data), and query patterns (ad-hoc analysis vs. pre-aggregated dashboard queries).
MQTT Broker and Sparkplug B
MQTT with the Sparkplug B payload specification is the emerging standard for OT data transport between edge and platform layers. Sparkplug B adds birth/death certificates (devices announce themselves when they connect and disconnect — enabling automatic topology discovery), defined payload structure (every message includes timestamp, quality, and value in a consistent format), and state management (the broker maintains the last known value of every tag, enabling new subscribers to receive current state without waiting for the next transmission). For new monitoring deployments, Sparkplug B is the correct default transport layer between edge and platform.
Data Quality and Governance
Raw data from field sensors contains gaps, outliers, stuck values, and timestamp errors that corrupt any analytics or KPI calculation built on top of them. Platform-layer data quality functions must include: timestamp validation (detecting and correcting clock drift between data sources), range checking (flagging values outside physical possibility — a temperature sensor reading 9999°C is an error, not a measurement), stuck value detection (a sensor returning the same value for more than N seconds when the process is known to be dynamic), and gap detection with fill-strategy selection (last-known-good, interpolated, or explicitly marked as missing depending on the application requirement).
Layer 5 — Application
Dashboard and Analytics Architecture: Giving the Right Data to the Right Person at the Right Time
The application layer is what most people think of when they think of a monitoring system — the dashboards and reports that production operators, supervisors, and managers see. But the application layer is only as good as the four layers beneath it. A well-designed application layer on a poorly architected platform layer produces fast, attractive, wrong dashboards. The application layer design must start with user role definition, not with chart type selection.
Operator / Line Technician
What they need: Current machine state, active alarms, accumulated count vs. target, cycle time. What they do not need: Historical trends, KPI comparisons, energy data.
Refresh: 1–5 seconds
Display: Line-side screen or HMI — no login required during production
Shift Supervisor
What they need: Shift OEE by line, active downtime events with duration, current vs. target throughput, open maintenance requests. What they do not need: Individual sensor readings, historical trend charts.
Refresh: 30–60 seconds
Display: Tablet or control room screen — role-based login, shift context automatically filtered
Maintenance Engineer
What they need: Asset health trends, vibration spectrum detail, predictive alert queue, work order history, failure pattern analysis. What they do not need: Production throughput KPIs.
Refresh: 1–10 minutes
Display: Laptop or engineering workstation — full historical access, export capability
Plant Manager / Director
What they need: Daily/weekly OEE, cost of downtime, quality yield trend, energy consumption vs. budget. What they do not need: Machine-level detail, sensor readings.
Refresh: Daily digest or on-demand
Display: Mobile or browser — summary KPIs, exception-based reporting, trend vs. target
Network Architecture
The OT Network Design That Supports Monitoring Without Compromising Control System Security
The network architecture underlying a production monitoring system must solve a fundamental tension: production monitoring requires data to flow from the control network (where PLCs and SCADA systems live) to the monitoring platform (which may be on an IT network or a cloud service). Security requirements demand that this data flow is strictly one-directional and isolated — the monitoring system must never be able to reach back into the control network and affect machine operation. The Purdue Reference Model, extended with IEC 62443 security zones and conduits, provides the framework for resolving this tension.
IT / Enterprise Network (Level 4)
ERP, MES, historian (enterprise), analytics platform, user dashboards
DMZ — Monitoring Conduit (Firewall pair)
Data diode or stateful firewall permitting OPC UA reads and MQTT publish upward only. No inbound connections from IT to OT. Logged and monitored.
OT Supervisory Network (Level 3)
SCADA, historian (plant), edge gateway management, engineering workstations
Industrial Managed Switch — VLAN segmented
Control Network (Level 2)
PLCs, DCS, safety systems, HMIs — no direct internet access, no IT devices permitted
Physical separation — separate cable infrastructure preferred
Field Network (Level 1)
Sensors, actuators, drives, field devices — hardwired or industrial wireless (WirelessHART, ISA100)
Integration Decision Map
Protocol and Technology Selection Across the Five Layers
Architecture Quality Metrics
Six Indicators That Your Monitoring Architecture Is Structurally Sound
Data Completeness Rate
Target: >99.5%
Percentage of expected data samples that arrive in the historian without gaps. Below 99% indicates network reliability problems, edge buffering failures, or PLC communication issues. Measured per tag and per machine to identify which layer is causing the incompleteness.
Timestamp Accuracy
Target: ±10ms
Maximum deviation between the time a measurement is taken at the field device and the timestamp recorded in the historian. Critical for event correlation across multiple machines — a 500ms timestamp error makes causal analysis of related events impossible. Requires NTP synchronisation across all devices in the monitoring stack.
Tag Namespace Coverage
Target: 100%
Percentage of monitored tags that conform to the unified namespace naming standard. Any tag outside the standard requires a custom mapping when used in a new application — creating ongoing integration debt. Namespace coverage should be verified by automated lint check at the platform layer, not by manual audit.
Edge Buffer Utilisation
Target: <20% capacity
Percentage of local edge buffer storage consumed during normal operation. A buffer running above 50% capacity during normal operation means network bandwidth is insufficient for the data rate — the buffer is being used for rate-levelling, not just for interruption resilience. Should spike during network outages and drain within minutes of restoration.
Application Query Response Time
Target: <3 seconds
Time for a dashboard or analytics query to return results for a standard time range (e.g., last 24 hours of OEE data for 10 machines). Above 5 seconds causes users to reduce dashboard usage — degrading the operational value of the monitoring investment. Typically resolved by pre-aggregation at the platform layer and indexing optimisation in the historian.
New Machine Onboarding Time
Target: <4 hours
Time from physical sensor installation to the first monitored tag appearing in the historian and dashboard for a new machine. A well-architected system with unified namespace, standard edge templates, and pre-configured integration allows onboarding in hours. A poorly architected system requires days or weeks of custom integration work per new machine.
From the Integration Field
“
The most consistent pattern I see in struggling monitoring implementations is that someone made the architecture decisions implicitly — by choosing a product — rather than explicitly by designing the architecture first and then selecting products that fit it. A historian vendor is selected because the salesperson was in front of the right people at the right time. An edge device vendor is selected because they were the cheapest option at the time of a specific project. A dashboard tool is selected because the IT team already had a licence for something. The result three years later is a monitoring stack with three incompatible time-series storage systems, two competing namespace conventions, and an edge layer where no two devices use the same protocol output. Every new capability requires bridging these incompatibilities. What should have been a configuration task — adding a new machine to the monitoring system — becomes a 3-week integration project. The architecture decisions that cause this are almost all made in the first six months of a monitoring programme. Getting them right requires treating the architecture as a design discipline rather than a procurement process.
Markus Søndergaard
Industrial Systems Architect · IT/OT Integration Specialist · 21 years designing production monitoring architectures across automotive, energy, and food manufacturing · Former Head of Manufacturing IT Architecture, Scandinavian industrial conglomerate · ISO/IEC 62443 practitioner
Architecture Team Questions
Production Monitoring System Architecture — Frequently Asked
Should we use OPC UA or MQTT Sparkplug B as the primary transport protocol between our edge layer and platform?
OPC UA and MQTT Sparkplug B solve slightly different problems and are increasingly used together rather than as alternatives. OPC UA is the better choice for the edge-to-supervisory connection — it provides a rich information model, built-in security (certificates, signing, encryption), and direct browsability of the PLC data model, which is essential for engineering and diagnostic workflows. MQTT Sparkplug B is the better choice for the edge-to-platform transport in monitoring-centric architectures — it is lighter weight, scales more efficiently to thousands of simultaneous publishing devices, and the Sparkplug B specification adds the birth/death certificates and consistent payload structure that raw MQTT lacks. In practice, the recommended architecture uses OPC UA between the PLC and the edge gateway, and MQTT Sparkplug B between the edge gateway and the platform broker. For a walkthrough of how iFactory implements this dual-protocol architecture in a manufacturing environment, book a technical architecture session.
How do we handle monitoring for legacy machines that have no PLC or digital output — only mechanical controls and analogue instruments?
Legacy machines with no digital output require retrofit sensing rather than PLC integration. The practical approaches, in order of implementation cost and data richness, are: current monitoring (a current transformer on the main motor supply provides machine running/stopped state and load profile without any modification to the machine itself — the simplest and cheapest retrofit, deployable in under an hour), vibration monitoring (accelerometers mounted on the machine frame provide machine state and mechanical health data without electrical connection to the machine), and analogue signal capture (a data acquisition module connected to existing analogue gauges or transducers converts 4–20mA or 0–10V signals from existing instruments into digital data without changing the instrument or its display). For machines with no analogue outputs and no accessible electrical connection, vision-based monitoring — a camera watching a gauge, indicator lamp, or production counter — can extract machine state from the visual field of existing instrumentation. Most legacy machine monitoring programmes find that current monitoring and vibration monitoring cover 80% of monitoring value at less than 20% of the cost of full digital retrofitting. For a legacy machine assessment for your specific equipment inventory, contact the iFactory support team.
How do we prevent the monitoring system from interfering with or overloading our existing PLCs and control networks?
Three principles protect the control system from monitoring system interference. First, network isolation: the monitoring data collection must happen in a separate network zone from the control network, connected only through a firewall or data diode that permits one-directional data flow outward from the control zone. No monitoring device or server should be on the same VLAN or subnet as a production PLC. Second, rate limiting: OPC UA subscriptions and Modbus polling rates must be configured with the controls engineering team to ensure the total communication load on each PLC communication processor stays below 20 to 30% of its rated capacity — leaving headroom for control traffic and HMI communication. Third, read-only enforcement at the network layer: firewall rules must explicitly block all write traffic from the monitoring network to the control network. Software-level read-only settings in monitoring platforms are a secondary protection, not a primary one. These three principles together ensure that even a misconfigured monitoring system cannot cause a production stoppage through network overload or accidental write.
What is the right data retention strategy for a production monitoring historian — how much data to keep and at what resolution?
A tiered retention strategy balances storage cost against analytical capability. Full-resolution data — every sample at the original collection interval — should be retained for 30 to 90 days for recent trend analysis and incident investigation. Minute-level aggregates (min, max, mean, standard deviation per minute) should be retained for 12 to 24 months for seasonal pattern analysis and long-term KPI trending. Daily aggregates should be retained indefinitely for capacity planning and multi-year performance analysis. This three-tier structure reduces storage requirements by approximately 95% relative to retaining full-resolution data indefinitely while preserving the analytical capability needed for each use case. The total storage requirement for a 500-tag monitoring system using this strategy is typically 2 to 8 TB over a 3-year horizon — modest enough for on-premise deployment and economical for cloud storage. iFactory's platform implements this tiered retention automatically, with retention policy configurable per tag family rather than as a single global setting. Book a session to review the retention configuration for your tag count and data rate.
How should we handle monitoring data from machines supplied by different OEMs with incompatible protocols and data models?
Multi-vendor OEM environments are the norm rather than the exception in manufacturing, and the edge layer is specifically designed to resolve this incompatibility. The approach is to use OEM-specific protocol adapters at the edge gateway to connect to each machine in its native protocol — Modbus RTU for a legacy conveyor controller, PROFINET for a Siemens-automated stamping press, EtherNet/IP for an Allen-Bradley welding cell, proprietary REST API for a newer robot controller — and then translate all of these to a single standard output format (MQTT Sparkplug B or OPC UA) before the data leaves the edge layer. The platform layer then receives all machine data in a consistent format, regardless of what protocol the original machine uses. The unified namespace design ensures that even though the data came from incompatible sources, it is addressed consistently in the historian and dashboard layer. The practical implementation requires OEM-specific adapter configuration at the edge gateway — most industrial edge platforms provide pre-built adapters for the 20 to 30 most common industrial protocols, with custom adapter development required for proprietary OEM interfaces. For an assessment of protocol compatibility with your specific OEM equipment mix, contact our integration engineering team.
Architecture First. Integration Second. Dashboards Third.
Build Your Production Monitoring System on a Foundation That Scales — From Five Machines to Five Hundred
iFactory's production monitoring platform is built on the five-layer reference architecture described in this guide — unified namespace, MQTT Sparkplug B transport, edge-buffered data collection, tiered historian storage, and role-based application layer. It connects to any PLC brand, any sensor protocol, and any existing historian — and it can be deployed on a single line in two weeks and extended across a full plant in three months without architectural rework.
