# IIoT Platform Selection: Capabilities and Evaluation Criteria

> The industrial IoT platform market is crowded and loud: every vendor claims edge-to-cloud, digital twins, and AI. Yet the platform decision is one of the most…

- Canonical URL: https://wiki.aspotomasyon.com/article/iiot-platform-selection
- Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki)
- Category: Modern Connectivity
- Published: 2026-08-11 · Updated: 2026-09-13
- Reading time: 5 min · Language: English

The industrial IoT platform market is crowded and loud: every vendor claims edge-to-cloud, digital twins, and AI. Yet the platform decision is one of the most consequential and expensive choices in a digitalization program — platforms are adopted for a decade, and migrating between them is a project in itself. This article cuts through the marketing with a functional view: what an IIoT platform actually does, what the architecture options are, and how to evaluate candidates against the plant's real use cases.

![A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg)

*A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.*

## What an IIoT Platform Does

An IIoT platform is the software backbone between the plant and the applications that use its data. The functional layers:

- **Connectivity** — device/gateway onboarding, protocol support (MQTT/Sparkplug, OPC UA, Modbus, vendor protocols), and connection management at scale.
- **Device and asset management** — device registry, configuration, firmware updates, and the asset hierarchy (site → line → machine → point) that organizes everything else.
- **Data management** — ingestion, time-series storage, quality and context handling, and data access (APIs, SQL, export).
- **Application services** — dashboards, rules/alerts, analytics, and integration interfaces (REST, webhooks, connectors).
- **Administration and security** — identity, roles, multi-tenancy, audit, and the security controls that make the platform trustworthy.

The depth of each layer varies enormously between products — from lightweight dashboards-in-a-box to full industrial data platforms with edge runtimes.

## Architecture Options

| Architecture | Strengths | Weaknesses |
| --- | --- | --- |
| SaaS (multi-tenant cloud) | Fast start, zero infrastructure, provider-managed security and updates. | Data leaves the plant (legal/sovereignty checks), recurring cost, provider lock-in. |
| Private cloud / self-hosted | Data control, custom integration depth. | You operate it: updates, security, scaling — a small IT department in itself. |
| Edge-first platform | Data processed at the plant, cloud optional; low latency, resilience to connectivity loss. | More engineering; the edge is part of the OT surface (see the cloud/edge security article). |
| Hybrid (edge + cloud) | The industrial standard: edge for collection/control-adjacent processing, cloud for scale and analytics. | Two environments to operate; integration quality decides the outcome. |

The evaluation should be anchored in the *target architecture* — where the data must live, who operates what, and how the platform fits the plant's OT security model — before comparing feature lists.

## Evaluation Criteria That Matter

1. **Protocol and integration depth** — native Sparkplug B? OPC UA client/server? Fieldbus gateways? The integration cost with the installed base is the platform's largest hidden price.
2. **Data model quality** — can the platform represent the plant's asset hierarchy and data context (units, quality, timestamps), or is it a flat tag bucket? Context is what makes the data usable later.
3. **Openness** — export capability (all data and configuration, documented), APIs, and the absence of proprietary locks: assess the exit cost as seriously as the entry cost.
4. **Security posture** — the platform's security model (identity, encryption, audit), its certifications, and its fit with the plant's IEC 62443 zoning.
5. **Operational model** — who runs it (vendor, plant IT, automation), the update cadence, and the support terms; a platform without an operational owner is a ghost.
6. **Cost model** — per-device, per-message, per-user, or bundled; model the bill on the plant's real data volume (see the cloud integration article for the cost drivers).
7. **Ecosystem** — the application ecosystem (analytics, visualization, industry solutions) and the community; the platform's ecosystem is its long-term value.

## The Evaluation Process

1. **Define the use cases first** — the three to five concrete applications (remote monitoring of site X, OEE analytics, alarm notification) with their data needs; the use cases are the platform's acceptance test.
2. **Shortlist on architecture** — filter by the target architecture and the integration profile; five candidates is enough.
3. **Run a pilot with real data** — connect one real asset (or a simulator) with the actual protocol, build the use case dashboard, and test the operational details: onboarding, alerts, data export.
4. **Score against the criteria with evidence** — a weighted scorecard filled from the pilots, not from sales calls; include the exit-cost question.
5. **Reference calls** — talk to plants of similar size and industry running the platform for 2+ years; ask about the operational reality, not the features.

## Common Mistakes

- Choosing by dashboard beauty — dashboards are the cheapest layer to build; data access and integration are the expensive ones.
- Platform-first, use-case-later — the classic: buy the platform, then search for problems; the result is an expensive dashboard museum.
- Ignoring the operational cost — the platform's monthly cost is the visible part; the integration, training, and operations effort is usually larger.
- Lock-in by neglect — no data export tested, no configuration export, and the platform becomes the plant's memory with no way out.

## Summary

IIoT platform selection is architecture first, features second: decide where the data lives and who operates it, then evaluate integration depth, data model quality, openness, security, operations, and cost against concrete use cases with a real pilot. The platform is a decade-long partner — choose it like a hiring decision, with evidence, references, and an exit plan.

## Apply this to your project

- Specify payload structure, units, identity, time semantics, access permissions, and protocol versions.
- Test backlog growth, connection loss, duplicate delivery, and restart behavior at the consuming application.
- Document how operators see failures and how the system distinguishes replayed data from current process state.

[Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance.

![Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-review.svg)

*Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.*

## Primary references and further reading

Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results.

- [OASIS — MQTT 5.0 specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html)
- [Modbus Organization — Protocol specifications](https://www.modbus.org/modbus-specifications)
- [Eclipse Foundation — Sparkplug 3.0 specification](https://sparkplug.eclipse.org/specification/version/3.0/)

---

Cite the canonical article: https://wiki.aspotomasyon.com/article/iiot-platform-selection (IIoT Platform Selection: Capabilities and Evaluation Criteria, ASP OTOMASYON, updated 2026-09-13).