Chapter 3｜OPC UA & MES Architecture
The previous chapter explained the different roles of ERP, MES, and machine connectivity. At the backend level, the questions become more concrete: How should different machine brands be connected? Where should real-time data be consolidated? Should the frontend connect directly to the database?
This chapter uses the flow OT → Edge → PMC Server / Database → API → Apps to explain the data path from the injection molding machine to the application layer.
3.1 Backend Data Architecture for Injection Molding
If a factory operates only one machine brand and one controller generation, integration is relatively simple. Real plants usually contain a mix of old and new machines, and each controller may expose different data, formats, and communication methods.
For that reason, MES should not contain a separate low-level integration for every machine. It is more maintainable to handle machine differences at the OT/Edge layer and provide a consistent data source to upper-level applications.
Injection molding machines, PLCs, sensors, and shop-floor devices.
Reads protocols, files, and machine interfaces and normalizes the data.
PMC provides the real-time data endpoint; the database stores history that needs to be retained.
Publishes data in fixed resource formats for other systems.
MES, reporting, dashboards, scheduling, warehouse, and mobile applications.
Figure 3.1-1: Backend architecture for injection molding data
3.1.1 OT Layer (Operational Technology)
The OT layer is the physical production equipment. A mixed factory may contain machines from Nissei, Shuenn Jaan, EdeX, YC, CLF, and other manufacturers.
The issue is not simply the number of brands. Each machine may expose data differently. One machine may support OPC UA, another may provide Modbus or PLC access, while an older machine may only provide TXT, CSV, or files in a shared folder.
3.1.2 Edge Layer
The Edge layer keeps machine-specific differences close to the shop floor.
If a machine already provides an OPC UA Server, an OPC UA Client can connect directly. If the machine only provides PLC registers or files, a gateway or edge program reads and converts them.
The Edge layer can also perform basic processing, such as change-only writes, offline flags, simple cycle-time calculations, or filtering, instead of sending every raw value to upper layers.
3.1.3 IT / Application Layer
Once equipment data is normalized, MES and other applications should not have to know whether the original source was Modbus, OPC UA, or a file.
They should work with a consistent device ID, tag, value, timestamp, and status, exposed through a standard interface.
- MES: Links equipment data with the work order, product, mold, and operator.
- Production Dashboard: Displays current status, cycle time, cycle count, and downtime.
- Reports: Queries historical production periods, utilization, and abnormalities.
- Mobile Applications: Provide selected information to supervisors and shop-floor personnel.
3.1.4 Summary
The main benefit of a layered architecture is not that the diagram looks complete. The benefit is that equipment integration and application development are less tightly coupled.
When a new machine is added, most work stays in OT/Edge. When a new application is added, it can reuse the existing API or standardized data interface.
3.2 Multi-Brand Connectivity and OPC Gateway
OPC UA is often used as a common interface for industrial connectivity, but not every injection molding machine provides OPC UA natively.
In practice, native OPC UA machines can connect directly, while other equipment is normalized through a gateway or data-conversion program.
3.2.1 OPC UA Architecture and Functions
OPC UA is useful because it can represent more than a flat tag value. It organizes equipment, objects, variables, events, and relationships in an Address Space.
Instead of seeing only “Tag 001 = 31.8,” the client can know which machine the node belongs to, what type of data it represents, and its data type.
- Cross-platform: Client and Server can run on different operating systems and devices.
- Security mechanisms: Certificates, signing, encryption, and user authentication are available, but must be configured correctly.
- Information model: Objects, variables, events, and node relationships can describe equipment structure.
- Subscriptions: Clients can subscribe to required nodes instead of repeatedly polling the complete data set.
3.2.2 IIoT Gateway vs. Edge Computer
The terms Gateway and Edge Computer are often used interchangeably, but their typical focus can be separated.
| Area | IIoT Gateway | Edge Computer |
|---|---|---|
| Main Job | Protocol conversion, data acquisition, forwarding | Acquisition plus local processing and application logic |
| Typical Use | PLC, RS-485, Modbus device integration | Local database, analytics, or more complex production logic |
| Compute Requirement | Usually lower | Can use higher CPU, memory, or accelerator resources if justified |
| Data Processing | Transform, normalize, forward | Filter, calculate indicators, run local software |
| Selection Principle | Edge is not automatically better. Select according to device count, data volume, and actual application needs. | |
3.2.3 Multi-Brand Connection Patterns
Do not assume a machine brand always uses one protocol. Confirm the actual controller and the interfaces available on the specific machine.
1. Native OPC UA Machine
If the machine includes an OPC UA Server, the OPC UA Client can connect directly and read the nodes exposed by the manufacturer. Available nodes, update behavior, and EUROMAP / OPC 40077 support still depend on the actual model and options.
2. PLC / Modbus Equipment
If the controller provides Modbus TCP, Modbus RTU, EtherNet/IP, or another PLC interface, a gateway can read the documented registers and convert them to the standard data structure. A correct register map is essential.
3. File-Export Equipment
Some older machines or vendor software export TXT, CSV, or other files. A server process can monitor the folder, parse new files, and write the results into a database.
The update rate may be slower than direct communication, but stable file output can still be useful for cycle time, cycle counts, or settings.
4. Other Controllers
EtherNet/IP, PROFINET, vendor APIs, or other methods should be handled according to the actual controller. The machine brand alone is not enough to determine the protocol.
3.2.4 Connection Matrix
| Equipment Situation | Possible Data Source | Recommended Approach | Verify Before Implementation |
|---|---|---|---|
| Newer Injection Molding Machine | OPC UA / vendor Ethernet interface | Prefer the manufacturer's standard interface | Nodes, license, version, options |
| Older File-Output Equipment | Shared folder, TXT, CSV | Monitor and parse files on a server | Export interval, field definitions, overwrite behavior |
| PLC-Controlled Machine | Modbus / EtherNet/IP / similar | Read through a gateway or industrial PC | Address map and access permissions |
| Vendor-Specific System | Vendor file, API, or communication program | Prefer documented vendor interfaces | Format stability and vendor support scope |
3.2.5 Summary
There is no single connection method that fits every machine in a multi-brand plant.
New machines can prioritize OPC UA. Older equipment can use PLC data, file output, or vendor interfaces. The goal is to normalize these sources into consistent device IDs, tags, values, and timestamps.
3.3 Centralized OPC UA PMC Server
After machine data becomes accessible, the next question is whether MES should connect directly to every individual machine.
A centralized PMC Server provides a unified real-time endpoint so upper-level systems do not need to handle every low-level machine difference independently.
3.3.1 PMC Server as the Central OPC UA Endpoint
PMC Server can be deployed on an industrial PC, organize data from different machines, and publish it through a unified OPC UA Address Space.
For the upper layer, the important point is that the final interface is consistent even when the original source was Modbus, a text file, or another vendor protocol.
- Central publication: Provides a unified OPC UA endpoint.
- Device organization: Uses stable Device IDs and data structures.
- Subscriptions: Clients subscribe only to required nodes.
- Connection management: Allows monitoring of clients, subscriptions, and node status.
3.3.2 Data Flow: OT → PMC → IT
- OT: Machines, PLCs, or gateways generate equipment data.
- PMC Server: Normalizes the data into a unified OPC UA Address Space.
- OPC UA Client: UaExpert, a data collector, or another application subscribes to nodes.
- Database: Values that require history are written to SQL Server, MySQL, or another datastore.
- Application: MES, reporting, and other apps use real-time or historical data.
Figure 3.3-1: PMC Server provides a unified equipment-data endpoint
3.3.3 Client Validation and Historical Storage
UaExpert is useful for validating that the OPC UA Server is available and for browsing the node structure.
Machines can be organized by machine ID and then grouped into Heater, Injection, Cycle, Mold, or other categories. Actual node names depend on the Address Space defined by the Server.
Figure 3.3-2: UaExpert can validate OPC UA nodes and live values
Historical analysis normally requires a database. A collector subscribes to the OPC UA data and writes timestamp, Device ID, Tag, Value, quality status, and other required fields into the database.
Navicat or another database tool is used to query and maintain the database. It is not the manufacturing data-acquisition system itself.
Figure 3.3-3: Historical data can be queried after it is written to the database
3.3.4 Summary
The purpose of the centralized OPC UA Server is to reduce direct coupling between applications and machines.
Real-time data can flow through OPC UA, while historical data is stored according to retention requirements. This separation makes later MES, reporting, and analytics applications easier to manage.
3.4 RESTful API and Data Access Control
Once production data reaches the database, the simplest approach is to let every application connect directly to SQL.
That can work for a small internal tool, but as the number of applications grows, database credentials, schema changes, and permissions become more difficult to control.
A RESTful API layer separates frontend applications from the physical database tables.
3.4.1 Why Use a Standardized API?
- Reduce database exposure: Frontends do not need direct database credentials.
- Reduce coupling: The API can keep a stable external structure even if tables change.
- Permission control: Each application gets only the data and actions it requires.
- Consistent data source: Web, MES, and mobile applications can reuse the same resources.
3.4.2 RESTful API: Resource-Oriented Access
An API does not need to expose every database table. Resources should be designed around actual application needs.
GET /devicesReturn the device listGET /devices/{id}Return a specific deviceGET /devices/{id}/statusReturn current machine statusGET /devices/{id}/cycle-timeReturn current or latest cycle timeGET /production-sessions/{id}Return a production-session recordPOST, PUT, and DELETE should only be implemented when the business process requires them. Real-time equipment data is often read-only from the application perspective.
3.4.3 JSON Schema and Data Types
JSON is convenient for frontend/backend exchange, but JSON alone does not guarantee that fields are correct.
A schema or program model can define field types, required fields, units, and allowed ranges.
Manufacturing APIs should avoid unnecessary string conversion. If pressure is numeric, send a number rather than the string "50.00".
{ "id": "A-ShuennJaan160Ei.HoldPressure.Point1.Pressure", "tagName": "HoldPressure.Point1.Pressure", "group": "SetValue", "name": "Hold Pressure Stage 1", "value": 50.00, "timestamp": "2026-08-25T10:32:15+08:00", "device": { "id": 1, "name": "A-ShuennJaan160Ei" }}The timestamp is essential. A manufacturing value without the time at which it was acquired is much less useful for traceability.
3.4.4 Swagger UI: Documentation and Testing
Swagger UI helps developers understand and test the API.
With an OpenAPI specification, endpoints, requests, responses, data types, and authorization methods can be documented in one place.
- Reduces dependence on manually maintained Word API documents.
- Makes frontend/backend changes easier to synchronize.
- Shows example requests and responses.
- Helps isolate whether a problem is in the API or the frontend.
Figure 3.4-1: Swagger UI for API documentation and testing
3.4.5 Summary
The API layer prevents every frontend application from depending directly on the physical database schema.
The database stores data. The API defines the application-facing contract. New dashboards, mobile apps, or reports can then reuse the same interface.
3.5 Backend Architecture Summary
The main goal of the architecture is simple: once data leaves the equipment, every layer should have a clear responsibility.
1. OT: Confirm What the Machine Can Actually Provide
New machines may expose OPC UA. Older machines may provide only PLC data or files. Do not assume all machines have the same tags.
2. Edge / Gateway: Keep Equipment Differences at the Bottom
The gateway normalizes protocols and file formats so MES does not need to know whether the original source was Modbus, OPC UA, or a text file.
3. PMC Server: Provide a Unified Real-Time Endpoint
Upper-level OPC UA clients find devices and nodes from one Server instead of connecting separately to every machine brand.
4. Database: Store the History That Is Actually Needed
Not every millisecond-level signal has to be stored forever. Retention and sampling should follow actual use cases. Cycle time, cycle count, machine status, and important production intervals should be linkable to the work order.
5. API: Make the Data Reusable
MES, production reporting, scheduling, warehouse, and mobile systems use fixed API resources instead of being tightly coupled to the database.
Once the work order, machine, mold, and time relationships are stable, the same foundation can be extended to anomaly alerts, OEE, energy analysis, or predictive maintenance.