MES Software: Vendors, Features & Costs Compared 2026
MES software compared: vendors, functions per VDI 5600, costs (cloud vs. on-premise) and implementation. Honest market overview 2026.
By Mark Kobbert · Last updated: April 2026
What is OPC UA?
OPC UA (Open Platform Communications Unified Architecture) is a machine-to-machine communication protocol for industrial automation, developed and maintained by the OPC Foundation. It was released in 2008 and standardised internationally as IEC 62541. OPC UA replaces the older "Classic OPC" specifications (OPC DA, OPC HDA, OPC A&E), which were tied to Microsoft Windows and COM/DCOM. OPC UA is platform-independent — it runs on Windows, Linux, embedded systems and cloud environments. It defines not only how data is transported, but also how data is modelled: every variable, every alarm, every method on a machine can be described with a standardised information model that any OPC UA client can interpret without custom configuration. For manufacturing, OPC UA is the protocol that answers the question: "How do I get structured, secure, real-time data from a modern PLC into an MES or cloud platform — without building a proprietary interface for every machine?"
The SYMESTIC Cloud MES platform uses OPC UA as its primary connectivity protocol for modern controllers, with a dedicated OPC UA Cloud Connector included in every subscription tier.
What problems does OPC UA solve that Classic OPC could not?
Classic OPC (the specifications released between 1996 and 2005) solved the original problem — reading data from a PLC without writing a custom driver for every controller manufacturer. But it created new problems that limited its use outside the local Windows PC on the factory floor:
| Limitation of Classic OPC | Technical cause | How OPC UA solves it | Why it matters for MES |
|---|---|---|---|
| Windows-only | Classic OPC relied on Microsoft COM/DCOM — a Windows-specific inter-process communication mechanism. No COM on Linux, no OPC. | OPC UA uses its own binary TCP protocol (opc.tcp://) or HTTPS. Runs on any OS: Windows, Linux, embedded RTOS, or directly in a cloud service. | A cloud-native MES like SYMESTIC runs on Azure (Linux containers). Classic OPC would require a Windows gateway in between. OPC UA connects directly. |
| No built-in security | DCOM security was difficult to configure and provided no message-level encryption. Most plants ran Classic OPC with security disabled. | OPC UA has a native security model with X.509 certificates for authentication, message signing, and AES-256 encryption. Security is part of the specification, not an add-on. | Machine data travelling from the shopfloor to a cloud MES crosses network boundaries. OPC UA's built-in encryption protects the data in transit without requiring a VPN. |
| Flat data model | Classic OPC DA exposed a flat list of tag names (e.g., "Press5.Temperature"). The meaning and structure of the data was defined by each vendor differently. | OPC UA uses a rich information model: objects, variables, methods, references, and data types are organised in an address space that describes the machine's structure semantically. | When every machine describes itself the same way, the MES can discover and interpret data automatically — reducing the configuration effort per machine from days to hours. |
| No firewall-friendly transport | DCOM required dynamic port ranges, which IT departments blocked by default. Getting Classic OPC through a firewall was a perpetual battle between OT and IT. | OPC UA uses a single, configurable port (default: 4840 for TCP, 443 for HTTPS). It can also operate in a Pub/Sub model over MQTT, which is inherently cloud-friendly. | Connecting machines to a cloud MES requires data to pass through firewalls. OPC UA's single-port design and outbound-only connection patterns (via MQTT or reverse-connect) make this feasible without opening inbound ports. |
What are the core components of OPC UA architecture?
OPC UA is not a simple "read a tag" protocol. It is a framework with several architectural layers, each defined in the IEC 62541 specification series:
| Component | What it does | Manufacturing relevance |
|---|---|---|
| Information Model | Defines how data is structured. Every OPC UA server exposes an "address space" — a tree of nodes representing objects (e.g., a machine), variables (e.g., temperature), methods (e.g., start cycle), and their relationships. Nodes have attributes like data type, engineering unit, and range. | The MES browses the address space and discovers available data points automatically. At Brita, OPC UA connectivity to modern line controllers enabled alarm data capture without manual tag mapping. |
| Transport Layer | Defines how data moves between client and server. OPC UA supports three transport profiles: UA TCP Binary (fastest, most common on the shopfloor), HTTPS/JSON (web-friendly), and Pub/Sub (for cloud and multi-subscriber scenarios, using MQTT or UDP multicast). | UA TCP Binary is used for low-latency machine-to-gateway communication. Pub/Sub over MQTT is used for gateway-to-cloud communication in the SYMESTIC architecture — allowing outbound-only connections through firewalls. |
| Security Model | Three layers: Application authentication (X.509 certificates identify client and server), User authentication (username/password or certificate per user), Message security (signing and/or encryption per message, using security policies like Basic256Sha256 or Aes128-Sha256-RsaOaep). | Machine data flowing to a cloud MES must be authenticated and encrypted. OPC UA provides this at the protocol level — no need for separate VPN tunnels or custom encryption layers. |
| Services | 37 defined service sets (as of IEC 62541-4) for browsing, reading, writing, subscribing, calling methods, managing sessions, querying history, etc. The client calls services; the server responds. | The "Subscribe" service is the most important for MES: the client subscribes to data changes, and the server sends only changed values. This reduces network traffic and enables real-time monitoring without polling. |
| Companion Specifications | Industry-specific information models standardised jointly by the OPC Foundation and domain organisations. Examples: OPC UA for Machinery (VDMA 40001-1), OPC UA for Plastics and Rubber (EUROMAP 77/83), OPC UA for PackML, OPC UA for Weighing, OPC UA for Woodworking. | Companion Specifications mean that an injection moulding machine from manufacturer A exposes the same data structure as one from manufacturer B — both follow EUROMAP 77. The MES reads the same node IDs, reducing machine-specific integration effort. |
How does OPC UA connect machines to a cloud MES in practice?
The practical connectivity architecture in a cloud MES deployment has 4 layers. This is the architecture that SYMESTIC implements with its customers:
| Layer | Component | What happens | Protocol used |
|---|---|---|---|
| 1 | PLC / Machine controller | The machine controller (Siemens S7-1500, Beckhoff TwinCAT, Allen-Bradley, Fanuc, etc.) runs an OPC UA server — either built into the PLC firmware or as an external software module. | OPC UA server embedded in PLC. Modern controllers from Siemens (S7-1500 with firmware ≥ V2.0), Beckhoff (TwinCAT 3), B&R, and others include OPC UA servers natively. |
| 2 | Edge Gateway | A lightweight device on the shopfloor network connects to the PLC's OPC UA server as a client, subscribes to defined data points (cycle counts, states, alarms, process parameters), and forwards the data to the cloud. | Shopfloor side: OPC UA Binary (client-to-server, intra-plant network). Cloud side: MQTT or HTTPS (outbound-only, encrypted). At Carcoustics, IXON IoT devices served as edge gateways with MQTT to Azure. |
| 3 | Cloud IoT Hub / Message Broker | The data arrives at a cloud message broker (e.g., Azure IoT Hub) that handles device authentication, message routing, and buffering. | MQTT or AMQP. TLS-encrypted. The SYMESTIC platform runs on Microsoft Azure and uses Azure IoT Hub as the ingestion layer. |
| 4 | Cloud MES Application | The MES application reads the data from the message broker, processes it in real time (OEE calculation, alarm detection, order mapping), and makes it available on dashboards and via API. | Internal cloud protocols (service bus, database writes). The SYMESTIC production metrics module, alarms module, and process data module each consume the data stream independently. |
The critical design decision: the edge gateway initiates the connection outbound — from the plant network to the cloud. No inbound ports need to be opened in the plant firewall. This is the pattern that satisfies IT security requirements in most manufacturing environments. At Kamps (food industry), OPC UA connectivity was used to connect highly automated bakery lines directly.
What happens when a machine does not support OPC UA?
OPC UA is available on modern controllers. But most plants are brownfield environments — a mix of modern PLCs with OPC UA and older machines from the 1990s or 2000s that have no OPC UA server, no Ethernet port, or no digital interface at all. This is the reality at the majority of SYMESTIC customers.
The solution is a tiered connectivity approach:
| Machine type | Connectivity method | What data is captured | Installation effort |
|---|---|---|---|
| Modern PLC with OPC UA (Siemens S7-1500, Beckhoff TwinCAT 3, B&R, etc.) | OPC UA client on edge gateway reads directly from the PLC's built-in OPC UA server. | Full data: cycle times, piece counts, machine states, alarms, process parameters (temperature, pressure, force, speed), program numbers. | 2–4 hours per machine. No PLC programming required — the OPC UA server exposes existing PLC variables. |
| Older PLC with Ethernet but no OPC UA (Siemens S7-300/400, older Allen-Bradley, Mitsubishi, etc.) | Edge gateway with native PLC protocol driver (S7 protocol, EtherNet/IP, MC protocol) — the gateway translates from the PLC's native protocol to the cloud transport. | Same as above, but requires manual mapping of PLC memory addresses to data points. At Schmiedetechnik Plettenberg, this approach was used for the mixed machine park. | 4–8 hours per machine. Requires knowledge of the PLC program and data block structure. |
| Machine with no digital interface (older mechanical presses, legacy equipment, standalone machines) | Digital I/O gateway: hardware sensors (inductive, optical, current transformers) connected to a digital input module that converts physical signals to data. At Klocke, all lines were connected via DI gateways without LAN infrastructure. | Basic data: machine running/stopped, cycle count, piece count. Sufficient for OEE calculation. | 1–2 hours per machine. No PLC access required. No production interruption. |
OPC UA is the preferred method when the machine supports it — it delivers the richest data with the lowest configuration effort. But it is not a prerequisite for an MES. At Neoperl, SPS-based alarm capture was used alongside OPC UA. At Meleghy, SAP integration and OEE capture work across mixed connectivity methods. The MES is protocol-agnostic at the application layer — the data arrives through different pipes, but the dashboards, KPIs and analyses work the same way regardless of the source protocol.
FAQ
What does "OPC" actually stand for?
The original OPC specifications (1996) used the acronym "OLE for Process Control" — a reference to Microsoft's OLE/COM technology. When OPC UA was developed (starting in 2003, released 2008), the dependence on Microsoft technology was eliminated. The OPC Foundation now treats "OPC" as a standalone brand name and uses the backronym "Open Platform Communications" in current materials. The correct full name is "OPC Unified Architecture" or simply "OPC UA." The notation "OPC-UA" with a hyphen is common in colloquial use but not the OPC Foundation's official format.
Is OPC UA the same as MQTT?
No. They serve different roles and can be complementary. OPC UA defines both the transport and the data model — it knows what a "temperature" or an "alarm" is because the information model describes it semantically. MQTT is a lightweight publish/subscribe transport protocol — it moves messages efficiently but has no built-in data model. In a typical cloud MES architecture, OPC UA is used on the shopfloor (PLC to gateway) for its rich data model, and MQTT is used for gateway-to-cloud transport for its simplicity and firewall friendliness. Since OPC UA Part 14 (Pub/Sub), OPC UA can itself use MQTT as a transport — combining OPC UA's data model with MQTT's cloud-friendly transport. This is the pattern SYMESTIC uses with its OPC UA Cloud Connector.
Do all major PLC manufacturers support OPC UA?
Yes — all major industrial automation vendors now include OPC UA server capabilities in their current-generation controllers. Siemens (S7-1500 since firmware V2.0, S7-1200 since V4.2), Beckhoff (TwinCAT 3), B&R (Automation Runtime), Rockwell/Allen-Bradley (FactoryTalk Linx Gateway), Mitsubishi (MELSEC iQ-R series), Omron (NX/NJ series), ABB, Schneider Electric (Modicon M580), Bosch Rexroth (ctrlX CORE), and others. The breadth of adoption is driven by Companion Specification requirements: when EUROMAP 77 mandates OPC UA for injection moulding machines, every injection moulding machine manufacturer must implement it. This industry-driven adoption cycle is what makes OPC UA the de facto standard for machine-to-MES communication.
What are the most important Companion Specifications for discrete manufacturing?
Companion Specifications standardise OPC UA information models for specific machine types. The most relevant for SYMESTIC's customer base include: OPC UA for Machinery (VDMA 40001-1 — a base specification that all machine types can extend), OPC UA for Plastics and Rubber Machinery (EUROMAP 77 for injection moulding, EUROMAP 83 for extrusion), OPC UA for Machine Tools (VDMA OPC UA for Machine Tools), OPC UA for PackML (packaging lines — relevant for Klocke-type pharma packaging), and OPC UA for Robotics. These are published jointly by the OPC Foundation and the respective industry association. Each defines a standard set of variables, alarms, and methods that every machine of that type must expose — making MES integration predictable and repeatable.
Related: ISA-95 · IIoT · Industry 4.0 · MES: Definition & Functions · Cloud MES vs. On-Premise · SYMESTIC Production Metrics · SYMESTIC Alarms Module · SYMESTIC Process Data · OEE Explained
About the author
Mark Kobbert
CTO of SYMESTIC. Built the cloud-native MES architecture on Microsoft Azure that ingests data from 15,000+ machines in 18 countries. Designed the OPC UA Cloud Connector that bridges shopfloor controllers to the SYMESTIC platform. B.Sc. Wirtschaftsinformatik (SRH Heidelberg). · LinkedIn
Start working with SYMESTIC today to boost your productivity, efficiency, and quality!
