Mestric logo

Sharing is caring

Learn with us! We want to give you an easy-to-follow guide to manufacturing processes and show you the best optimization process.
Section dividerSection divider
Technician wiring automation control panel
August 10, 2026

Automation system architectures: a practical guide for engineers

Automation system architectures fall into three classification axes, and knowing which axis to apply first determines every downstream decision. The production-model axis groups architectures as fixed, programmable, flexible, or integrated, based on volume and product-mix requirements. The hierarchical axis maps functions across five layers (Levels 0–4 of the automation pyramid), from field sensors up to ERP. The control-theory axis distinguishes open from closed loop, continuous from discrete, linear from non-linear, and single-input single-output (SISO) from multi-input multi-output (MIMO). Together, these three axes give you a structured way to assess any plant or project.

When comparing architectures across the article, the key dimensions are:

  • Best for (volume/mix): what production profile the architecture suits
  • Cost and implementation complexity: capital outlay, engineering hours, and commissioning risk
  • Scalability and maintainability: how well the architecture grows and how easy it is to modify
  • Real-time/latency suitability: whether the architecture can meet determinism requirements
  • MES/ERP integration: how readily the architecture connects to Level 3 and Level 4 systems

Key takeaways

Matching your production model to the right architecture family, then validating against control-loop requirements and MES integration needs, is the decision sequence that prevents the most costly rework.

Point Details
Map production model first Fixed, programmable, flexible, or integrated: your volume and product-mix profile determines the architecture family before any other criterion.
Control-loop requirements drive controller placement Update rate and SISO/MIMO classification determine whether a standard PLC, motion controller, or DCS is technically eligible for each loop.
MES belongs at Level 3 ISA-95 places MES between SCADA and ERP; define the data contract before hardware is ordered to avoid the most common integration overruns.
Prefer open standards OPC UA and IEC 61131-3 compliance protect long-term flexibility and reduce vendor lock-in across all architecture classes.
Mestric as the MES layer Mestric connects to existing PLCs and SCADA systems via OPC UA, delivering real-time OEE, quality, and downtime data at Level 3 without replacing your control infrastructure.

Table of Contents

How production model shapes the types of automation system architectures

Industrial automation literature consistently groups architectures into four production-model categories. Each class reflects a different answer to the same question: how much does your product mix change, and how often?

Fixed (hard) automation

Fixed automation is built for a single product at very high volume. The control sequence is embedded in the mechanical or electrical design itself, so changeover is either impossible or prohibitively expensive. Automotive body stamping lines and beverage filling lines are the canonical examples. Capital cost is high, but unit cost at volume is the lowest of any class.

Programmable automation

Programmable automation uses a stored programme, typically on a PLC or CNC controller, to define the sequence. Changing the programme changes the product, though physical tooling changes are still needed. Batch chemical plants, injection-moulding shops, and medium-volume machining cells all fit here. The architecture is more flexible than fixed automation, but changeover still takes hours rather than minutes.

Flexible (soft) automation

Flexible automation adds rapid, software-driven reconfiguration. Robotic assembly cells with vision guidance, flexible manufacturing systems (FMS), and CNC machining centres with automatic tool changers are typical examples. South Shore Controls describe this class as suited to high-mix, medium-volume production where changeover time must be measured in minutes. The trade-off is higher per-unit cost and more complex control software.

Robotic arm in flexible automation cell

Integrated automation

Integrated automation connects every production function, from order management through to dispatch, in a single digital architecture. MES, ERP, SCADA, and field controllers share a common data model. Semiconductor fabs, pharmaceutical packaging lines, and advanced food-processing plants increasingly operate this way. The architecture demands the most engineering investment upfront, but it is the only class that supports closed-loop feedback from enterprise data back to machine parameters.

Comparing the four classes

Class Best for (volume/mix) Cost and complexity Scalability and maintainability Real-time/latency MES/ERP integration
Fixed Very high volume, single product High CAPEX, low OPEX Low: changes require physical rework Excellent: hardwired determinism Minimal: limited data extraction
Programmable Medium volume, limited variants Moderate CAPEX, moderate OPEX Moderate: programme changes feasible Good: PLC scan times typically fall within the low millisecond range. Moderate: standard PLC data interfaces
Flexible High mix, medium volume Higher CAPEX, higher OPEX High: software-driven reconfiguration Good to moderate: depends on motion needs Good: open fieldbus and OPC UA support
Integrated Any volume, full digital integration Highest CAPEX and engineering effort Highest: modular and data-driven Varies by layer: edge handles real-time Native: MES/ERP integration by design

Key procurement considerations:

  • Fixed lines carry the highest rework risk if product specifications change within the asset’s lifecycle.
  • Programmable architectures often create vendor lock-in through proprietary PLC programming environments; specify IEC 61131-3 compliance to preserve portability.
  • Flexible and integrated architectures require a clear MES data contract before commissioning, or integration costs will escalate.

How the automation pyramid maps functions across five layers

The automation pyramid, formalised in the ISA-95 enterprise-to-control hierarchy, assigns every function and component to one of five layers. Understanding which layer owns which function prevents the most common architectural mistake: placing control logic at the wrong level and then fighting data-latency or ownership problems later.

Level 0 — Field devices: Sensors, actuators, drives, and instruments. These devices measure and affect the physical process directly. Temperature transmitters, flow meters, servo drives, and pneumatic valves all live here.

Level 1 — Control: PLCs, safety controllers, and motion controllers execute control loops and sequence logic. Scan times at this level are typically in the low millisecond range for standard PLC tasks; motion control often requires sub-millisecond update rates.

Level 2 — Supervisory: SCADA systems and HMI panels aggregate data from Level 1 controllers, display process state, and allow operators to adjust setpoints. This layer does not close control loops directly; it supervises them.

Level 3 — MES/production management: The Manufacturing Execution System sits here. It receives production orders from Level 4, dispatches work to Level 2, and collects real-time OEE, quality events, and downtime logs. ISA-95 defines the data models and interface contracts for this layer.

Level 4 — Enterprise/ERP: Business planning systems (SAP, Oracle, Microsoft Dynamics) manage orders, inventory, and financials. Data flows upward from Level 3 in near-real-time; planning data flows downward as production schedules.

Component-to-layer mapping:

  • Sensors and actuators → Level 0
  • PLCs, edge controllers, safety PLCs → Level 1 (with some supervisory functions at Level 2)
  • SCADA, HMI, historian → Level 2–3 boundary
  • MES → Level 3
  • ERP, business intelligence → Level 4

One practical complication: modern edge devices increasingly bridge Levels 1–3 by running lightweight analytics and pre-processing data before it reaches SCADA. This is useful for bandwidth reduction, but it creates data-ownership ambiguity. Define clearly which system is the system of record for each data class before you deploy edge analytics.


Control-system classifications that drive architecture decisions

Control systems are classified along four axes, and each axis has direct consequences for controller selection, network design, and where in the pyramid a function must run.

Open loop vs closed loop

An open-loop system applies a fixed output without measuring the result. A conveyor running at a fixed speed regardless of load is open-loop. A closed-loop system measures the process variable, compares it to a setpoint, and adjusts the output accordingly. A PID temperature controller is the standard example: the controller reads the thermocouple (measurement), subtracts the setpoint (error), and drives a heater or valve (output) to minimise that error.

Closed-loop architecture is almost always necessary wherever disturbances affect product quality. NPTEL control-engineering material cautions that failing to recognise when a process needs feedback can produce unstable or uncontrollable behaviour, particularly when process gain or dead time changes with operating conditions.

Engineering warning: Using open-loop control where load disturbances are significant risks product quality drift and, in some processes, safety incidents. Mitigation requires adding measurement (sensors), designing a feedback path, or using feedforward compensation when disturbances are measurable but not correctable in real time.

Continuous vs discrete

Continuous-time systems process analogue signals without interruption; discrete-time systems sample signals at a fixed rate. PLCs are inherently discrete: they execute a scan cycle and update outputs once per cycle. The sampling rate must be at least twice the highest frequency of interest (Nyquist criterion), so fast processes require faster scan times and more capable hardware.

Linear vs non-linear

Linear systems obey superposition and are amenable to classical PID tuning. Non-linear systems, such as pH control, exothermic reactors, or hydraulic actuators, require gain-scheduling, model-predictive control (MPC), or other advanced strategies. Specifying a standard PLC with a PID block for a strongly non-linear process is a common design error.

SISO vs MIMO

A single-input single-output loop controls one variable with one actuator. Most PLC-based architectures are built from many independent SISO loops. MIMO control handles interactions between variables simultaneously, as in distillation column control or coordinated multi-axis motion. MIMO typically requires a DCS or dedicated motion controller with the computational headroom to solve the control problem in real time.

Determinism and real-time requirements:

  • Standard PLC scan times are usually in the low millisecond range, suitable for most discrete and process control tasks.
  • Motion control often requires sub-millisecond update rates, requiring dedicated motion controllers or real-time Ethernet (EtherCAT, Profinet IRT).
  • SCADA polling: 100 ms to several seconds, not suitable for closing control loops

Pro Tip: Before selecting a controller platform, list every control loop with its required update rate and classify it as SISO or MIMO. Loops requiring sub-millisecond updates must run on dedicated motion hardware, not a standard PLC. This single step prevents the most expensive late-stage redesigns.


Common deployment architectures and where each fits

Real plants rarely implement a single pure architecture. The Industrial Automation Authority identifies several primary system types, each suited to different plant scales and process characteristics.

Centralised DCS

A Distributed Control System uses a single, integrated engineering database shared across all controllers, operator stations, and historians. Plants with many PID loops, such as oil refineries, chemical plants, and power stations, favour DCS because the integrated environment reduces configuration errors and simplifies loop tuning. The trade-off is higher initial cost and a single-vendor dependency that can be difficult to exit.

PLC islands with SCADA supervisor

Discrete manufacturing plants typically deploy PLC islands, each controlling a cell or line, with a SCADA system providing supervisory visibility across all islands. This architecture is modular: adding a new cell means adding a new PLC without touching the rest of the plant. The challenge is data consistency. Each PLC island may use a different data model, so the SCADA layer must normalise data before passing it to MES.

SCADA with remote terminal units (RTUs)

Water utilities, gas pipelines, and electricity distribution networks use RTUs at geographically dispersed sites, with SCADA providing centralised monitoring and control over wide-area networks. Latency is higher than in a local plant network, so this architecture is unsuitable for fast control loops. Safety-critical functions must run locally at the RTU, not in the central SCADA.

Programmable automation controllers (PACs)

PACs combine PLC-style discrete logic with PC-based processing power, supporting mixed logic, motion, and process control in a single platform. They suit mid-size plants that need more computational flexibility than a standard PLC but do not require a full DCS. National Instruments CompactRIO is a well-known example.

IIoT and edge–cloud architectures

Modern plants increasingly deploy edge computing nodes that pre-process data from Level 0–1 devices before sending aggregated results to cloud analytics platforms. Red Hat’s automation portfolio architecture describes patterns such as self-healing infrastructure and automated deployment factories that are directly applicable when designing the orchestration and analytics layers above the plant floor. For higher-level orchestration involving AI services and cross-domain workflows, multi-agent patterns are becoming relevant as plants integrate predictive quality and scheduling agents.

Integration challenges when mixing architectures:

  • PLC islands and DCS pockets in the same plant create data-model conflicts; use OPC UA as a common information model layer.
  • Gateway devices translating between fieldbus and Industrial Ethernet introduce latency; measure and budget this before specifying.
  • Phased migration from legacy PLC islands to an integrated architecture works best when you freeze the MES data contract first, then migrate controllers one cell at a time.

Typical latency expectations by architecture:

  • Hardwired safety loop: < 10 ms
  • EtherCAT motion network: < 1 ms
  • Profinet IRT: < 1 ms
  • Standard Industrial Ethernet (EtherNet/IP, Profinet RT): 1–10 ms
  • OPC UA over standard Ethernet: 10–100 ms
  • Cloud analytics round-trip: 100 ms to several seconds

Which communication protocols suit your architecture?

Industrial communication protocols fall into three families: legacy fieldbuses, Industrial Ethernet variants, and higher-level interoperability standards. Choosing the wrong protocol for a layer is one of the most common causes of integration rework.

Protocol Family Typical latency Topology Common industries MES/SCADA compatibility
Modbus RTU/TCP Legacy fieldbus / Ethernet 10–100 ms Point-to-point, star Process, utilities, HVAC Wide: most SCADA systems
Profibus DP Legacy fieldbus 1–10 ms Bus Process, discrete manufacturing Good: via Profibus master cards
EtherNet/IP Industrial Ethernet 1–10 ms Star, ring Discrete, automotive, food Very good: native SCADA/MES drivers
Profinet RT/IRT Industrial Ethernet < 1 ms (IRT) Star, ring Automotive, machinery Very good: Siemens-ecosystem native
EtherCAT Industrial Ethernet < 1 ms Ring Motion, robotics, packaging Moderate: gateway to OPC UA needed
OPC UA Interoperability standard 10–100 ms Any (transport-agnostic) All industries Native: designed for MES/ERP
MQTT (over IT network) IIoT messaging Variable Broker-based IIoT, cloud analytics Good: broker bridges to MES
WirelessHART / ISA100 Wireless fieldbus 10 ms Mesh Process, oil and gas Moderate: via gateway

Pro Tip: Segment your network into at least three zones: field/control (Levels 0–2), supervisory/MES (Levels 2–3), and enterprise/IT (Level 4). Use a hardened gateway or data diode at each boundary. Never expose PLC programming ports to the corporate IT network. This is the single most impactful security measure you can take before an IIoT deployment.

On wireless and time-sensitive networking (TSN): WirelessHART and ISA100.11a are appropriate for monitoring loops where latency of tens to hundreds of milliseconds is acceptable, such as tank level or temperature trending. They are not suitable for closing fast control loops. IEEE 802.1 TSN extensions to standard Ethernet are beginning to appear in industrial switches and promise deterministic latency over standard IT infrastructure, but adoption in UK plants is still early.


How to choose the right architecture for your plant

The right architecture matches your production model to a control topology, then validates the choice against integration and lifecycle criteria. Factory automation guidance for plant managers consistently shows that skipping the validation step is where projects overrun.

Step 1: Define your production model. Is your plant fixed, programmable, flexible, or integrated? If you cannot answer this, map your product SKU count against annual volume per SKU. High volume, few SKUs points to fixed or programmable. High mix, moderate volume points to flexible or integrated.

Step 2: List every control loop and classify it. For each loop, record the required update rate, whether it is SISO or MIMO, and whether it is safety-related (SIL-rated). This list determines which controller platforms are technically eligible.

Step 3: Map geographic dispersion. A single-site plant with all equipment within 500 metres can use Industrial Ethernet throughout. A multi-site or geographically distributed operation needs WAN-tolerant architectures (SCADA + RTU, cloud-edge patterns).

Step 4: Assess existing equipment and vendor lock-in tolerance. If 80% of your field devices speak Profibus, a full migration to EtherNet/IP is a multi-year programme. Identify which legacy protocols must be supported via gateways and which can be replaced in the current project scope.

Step 5: Define MES and ERP data requirements. Specify what data the MES needs, at what frequency, and in what format. This becomes the integration contract that every controller and SCADA system must satisfy.

Step 6: Evaluate OPEX vs CAPEX trade-offs. DCS and integrated architectures carry higher upfront cost but lower long-term engineering cost. PLC islands are cheaper to install but more expensive to integrate and maintain at scale.

Checklist for vendor and contractor evaluation:

  • Maximum PLC scan time and proof of determinism under full I/O load
  • Redundant I/O and controller failover time (specify maximum acceptable switchover time)
  • OPC UA server certification and data delivery SLA to MES
  • IEC 61131-3 compliance for all PLC programming environments
  • SIL certification evidence for any safety-rated loops (IEC 61508 / IEC 61511)
  • Documented network segmentation plan and cybersecurity baseline

Running a rapid architecture-selection workshop:

  1. Assemble: process engineer, controls engineer, IT/OT network lead, MES owner, and plant manager.
  2. Present the production-model classification and ask each stakeholder to vote on which class describes the plant today and in five years.
  3. Walk through the control-loop list and flag any loops that require sub-millisecond update rates or SIL ratings.
  4. Map the agreed architecture to the automation pyramid and assign system ownership per layer.
  5. Identify the three highest-risk integration points and assign an owner and a test criterion to each.
  6. Document the agreed architecture in a one-page decision record before the meeting ends.

Where MES fits in your automation architecture

MES belongs at Level 3 of the automation pyramid and is the operational bridge between real-time control and enterprise planning. It receives production orders from ERP, dispatches work instructions to SCADA and PLCs, and collects the data that makes real-time performance tracking possible.

Key integration points for MES:

  • Production orders: received from ERP (Level 4) via ISA-95-compliant interfaces or REST APIs
  • Real-time OEE: calculated from machine state data collected from PLCs and SCADA via OPC UA or MQTT
  • Quality events: triggered by in-line measurement systems at Level 0–1 and passed to MES for SPC analysis and disposition
  • Downtime logs: captured automatically from PLC state changes, eliminating manual paper-based recording
  • Cost accounting: cycle time and material consumption data fed to ERP for accurate job costing

Practical benefits of a well-integrated MES:

  • Faster root-cause analysis for downtime events, because machine state data is timestamped and correlated automatically
  • Automated quality checks reduce the lag between a defect occurring and a corrective action being triggered
  • Automated reporting replaces manual shift-end data entry, reducing transcription errors and freeing supervisors for higher-value tasks
  • Tighter cost accounting, because actual cycle times and scrap rates feed ERP rather than estimated standards

Integration architecture notes:

  • OPC UA is the preferred protocol for PLC-to-MES data transfer; it provides a standardised information model and built-in security.
  • MQTT brokers are increasingly used for high-frequency telemetry from edge devices to MES analytics modules.
  • Data mapping between PLC tag names and MES data objects must be defined and tested before go-live; this is consistently the most time-consuming integration task.

MES at Level 3 is not optional in an integrated architecture. Without it, production orders, quality data, and downtime events remain siloed in individual PLC historians and spreadsheets, and the enterprise never gets the feedback loop it needs to improve scheduling, quality, and cost. Automotive production tracking is one of the clearest examples: plants that connect MES to their line controllers gain the ability to correlate machine parameters with quality outcomes in real time, something no manual system can replicate.


An engineer’s perspective on what actually goes wrong

The highest-impact early moves on any automation architecture project are fixing measurement fidelity, establishing loop ownership, and defining the MES data contract. Everything else is secondary.

Most projects that overrun do so for one of three reasons. First, scope creep at the control layer: engineers add loops, interlocks, and reporting requirements after the architecture is frozen, and the network and controller capacity was never sized for the final load. Second, insufficient network segmentation: IT and OT networks are bridged without a hardened gateway, and the first security incident forces an unplanned redesign. Third, over-reliance on vendor-specific tools without verifiable data export: a proprietary historian or SCADA system that cannot deliver OPC UA or a standard database export creates a lock-in that is expensive to escape.

Common project mistakes to avoid:

  • Specifying controller hardware before completing the control-loop list and update-rate analysis
  • Treating OPC UA as a nice-to-have rather than a contractual requirement in the MES integration specification
  • Skipping end-to-end data-flow testing from Level 0 sensor to Level 3 MES before go-live
  • Assuming that a DCS vendor’s MES module is equivalent to a purpose-built MES platform

Quick wins in the first 60–90 days of an architecture project:

  • Audit every existing control loop: verify that the sensor is calibrated, the loop is closed, and the setpoint is current. Fixing a drifting measurement costs almost nothing and immediately improves process stability.
  • Assign a named owner to every loop and every data feed. Ownership gaps are where integration failures hide.
  • Draft the MES data contract: a one-page document listing every data point the MES needs, its source, its update frequency, and its acceptable latency. Circulate it to the controls team and the MES vendor before any hardware is ordered.
  • Test your network segmentation with a simple port scan. If you can reach a PLC programming port from the corporate Wi-Fi, fix it before the IIoT deployment begins.

Mestric connects your architecture to real operational results

Choosing the right architecture is only half the work. The other half is ensuring that the data your plant generates actually reaches the people and systems that can act on it. That is where Mestric fits.

Mestric

Mestric is a purpose-built MES platform designed to sit at Level 3 of your automation pyramid and connect directly with your existing PLCs, SCADA systems, and field devices. You get real-time OEE, downtime analysis, quality monitoring, and cost analytics in a single interface, without replacing your control infrastructure. For plants moving from PLC islands to an integrated architecture, Mestric provides the MES layer that makes integration worthwhile, turning raw machine data into production KPIs your management team can act on. The platform supports OPC UA and standard industrial protocols, so it works with the hardware you already have. Book a demonstration to see how Mestric connects to your plant floor and what your production data looks like when it is properly organised.


Sources

The following standards and resources are the authoritative references for specifying and verifying automation architectures in the UK and internationally.

Standards to cite in specifications:

Practical reading and reference material:

How to use standards in specifications:

Cite exact clauses rather than standard titles alone. For safety loops, specify the target SIL level, the required proof-test interval, and the diagnostic coverage class. For integration, require OPC UA server certification to a named companion specification (e.g., OPC UA for Machinery). For PLC programming, require IEC 61131-3 compliance and specify which languages are permitted. Mandating testable, measurable requirements in contracts is the only way to hold vendors accountable at factory acceptance testing.


crossmenu