IIoT architecture reviews usually happen on top of vendor slides. But the architecture diagrams on slides are almost always beautiful — the differences on the shop floor come down to the details. Here is how to evaluate the UNS, OPC UA, and IIoT platforms by practical criteria.
First, Don't Mix Up the Roles — OPC UA and the UNS
The most common confusion is casting OPC UA and the UNS as competitors. They live at different layers.
- OPC UA — the standard for talking directly to equipment. It provides both request-response (read/write) and subscription, with a rich information model. It is "the language of equipment."
- UNS (Unified Namespace) — a publish-subscribe hub that mirrors the asset hierarchy as a topic structure on top of MQTT and Sparkplug B. Every system in the enterprise subscribes to data through the same addressing scheme. It is "the language of the organization."
A healthy architecture usually uses both: southbound (equipment), collect and re-serve data over OPC UA and other field protocols; northbound (enterprise-wide), open the data up through the UNS.
The Eight Axes of Practical Evaluation
1. Protocol coverage — Ask against your line's complete list, not the three protocols in the demo. Locally common PLCs (LS, Mitsubishi), CNC (FOCAS), semiconductor (SECS/GEM), power (DNP3, IEC 61850) — the question is not "how many protocols do you support" but "how many items on our equipment list do you support."
2. Information model and semantics — Are tags organized on a hierarchy (ISA-95)? Are relationships between assets (an ontology) expressed as well? Collection without semantics is the beginning of a data swamp.
3. Real-time behavior — Tail latency (collection latency in ms) and sustained throughput (msg/s, ev/s) as numbers, not averages. "Supports real time" is an adjective, not an evaluation item.
4. Reliability — When the network drops, where does the data survive (store-and-forward capacity, retransmission)? When a gateway dies, what takes over (redundancy, failover time)?
5. Security and deployment constraints — Does it operate fully within a closed network or air gap? How deep do authentication, TLS, and audit trails reach? Whether cloud is mandatory becomes a disqualifier in some industries.
6. Openness — The number and documentation quality of REST APIs, publish-subscribe openness (UNS), and the new criterion of the AI era — can it be opened to AI safely, read-only?
7. Scalability — Does the architecture stay the same going from 10,000 tags to 100,000, from one plant to five? Is a consolidated multi-site view standard, or custom work?
8. Operability — Does the platform instrument itself (pipeline health, latency, uptime statistics)? Can failures be diagnosed from the platform's logs? An architecture evaluation without operations is only half an evaluation.
A Checklist Used in the Field
- We received a driver-coverage table against our equipment list
- We measured collection latency and throughput in a PoC with our own data
- We pulled the cable — there was no data gap after recovery
- We shut down one gateway — and measured the failover time
- We confirmed it installs and operates without internet access
- We mapped our own coding scheme onto the asset hierarchy and ontology
- We were shown a real round trip with MES/ERP (recipe download, production results upload)
- We saw the pipeline bottleneck ourselves on the operations statistics screen
Conclusion
The essence of architecture evaluation is not comparing diagrams but demonstrating failure conditions. Unplug it, power it off, put it under load. PlantPulse® was designed against these eight axes — 42 drivers, ontology and UNS, 8ms and 510,000 ev/s, store-and-forward and HA, air-gap completeness, 150+ APIs and read-only MCP, multi-site, self-instrumentation — and we invite you to evaluate it by the same standards.
Topic reference: How to Evaluate UNS, OPC UA and IIoT Architecture in Practice (Medium · Coformation)