Every edge IIoT vendor pitch sounds roughly the same right now: connect the machines, normalize the data, publish it into a Unified Namespace, let MES and analytics subscribe instead of integrate point-to-point. The demos look alike. The MQTT Sparkplug B payloads look alike. Where these platforms actually diverge — and where plants get burned after the pilot works and someone tries to scale it to twelve lines across three plants — is the licensing model underneath.
Per-tag, per-node, per-connection, per-gateway: these aren’t just billing details. They’re architectural incentives. A per-tag model punishes you for high-density sensor data. A per-connection model punishes you for a sprawling brownfield network with forty different PLC families. Pick the wrong model for your plant’s actual data topology and you can end up paying multiples of what a competing tool would have cost for identical functionality.
The players and their default posture
HighByte (Intelligence Hub) built its reputation on a modeling-first approach — you define ISA-95-style asset structures and normalize disparate source data into a common model before it hits the UNS. Its commercial packaging has moved toward node- and instance-based licensing tied to the scale of the deployment rather than raw tag count, which suits its buyer profile: engineering teams doing serious contextualization work, not just pass-through publishing.
Litmus (Litmus Edge) leans into an application-marketplace model — a base edge platform plus add-on modules (protocol drivers, ML inferencing, visualization) that are licensed somewhat independently. That gives you granular control over what you’re paying for, but it also means your effective cost depends heavily on how many modules a given use case actually needs, which is harder to estimate from a feature sheet alone.
Element, the Software AG-lineage platform now positioned around Cumulocity IoT and edge integration, tends to carry the enterprise-IoT pricing DNA of its parent ecosystem — device- and data-volume-oriented commercial constructs that make more sense if you’re already standardized on that broader stack, and less sense as a standalone edge historian bolted onto an otherwise vendor-neutral UNS.
Kepware Edge (PTC) is the connectivity incumbent’s answer to the edge-native trend. Classic KEPServerEX pricing was heavily driver- and channel-based — you paid for the specific protocol connectors you needed. Kepware Edge shifts some of that toward a more containerized, subscription-oriented posture, but the lineage still shows: think in terms of connections and driver packs, not raw tag volume.
Ignition Edge (Inductive Automation) is the outlier worth understanding on its own terms. Ignition’s core platform uses an unlimited-tag, unlimited-client licensing philosophy at the server level, and Ignition Edge extends that down to gateway-class hardware at the line or cell level, typically licensed per edge instance rather than per tag or per connection. For plants with dense tag counts per machine, this is the model that breaks the cost curve in your favor — assuming you’re comfortable in the broader Ignition ecosystem.
Why per-tag pricing quietly becomes the expensive option
Per-tag licensing looks cheap in a pilot. One line, a few hundred tags, a modest monthly or annual fee — fine. The problem is that UNS architectures are explicitly designed to multiply tag counts over time: every new sensor, every derived calculation, every MES work-order status you publish back down to the edge adds tags. A model that charges per tag charges you for exactly the behavior a mature UNS rollout is supposed to encourage. Plants that scale past a single pilot line under a per-tag license often find the cost curve steepens faster than the value curve, because contextualized data — the whole point of a UNS — inherently means more published points, not fewer.
Per-node or per-instance pricing flips that incentive. You pay for where the software runs, not how much it says, so contextualization is “free” once you’ve paid for the gateway. That rewards architectures with a small number of well-modeled edge nodes feeding rich payloads, which is exactly the design pattern most UNS reference architectures recommend anyway.
Building an honest 3-year model
Feature-list comparisons fail here because they ignore growth. Before picking an edge layer, model three things across a realistic three-year horizon, not just year one:
- Tag growth rate. Estimate tags per asset today, then project what a mature contextualization effort adds — derived tags, calculated KPIs, MES-write-back points routinely double or triple the raw sensor count.
- Node/gateway count at full rollout, not pilot scale. A cost that looks trivial at one gateway can look very different multiplied across every line in every plant in the network.
- Connector and driver sprawl. Brownfield plants with a long tail of legacy PLCs, mixed fieldbus protocols, and one-off serial devices should model per-connection costs against their actual device inventory, not an idealized homogeneous fleet.
Run each vendor’s stated model against those three numbers, not against the demo tag count. The platform that wins on sticker price for a ten-tag pilot is frequently not the one that wins at production scale, and the inverse is just as often true — a higher pilot cost can represent a flatter, more favorable curve later.
Who fits where
In our assessment, HighByte suits engineering-led teams that want to invest real effort in data modeling and are willing to pay for that as an instance-scaled platform decision rather than a per-point metering exercise. Litmus fits teams that want modularity and are disciplined about scoping exactly which application modules they need, since undisciplined module sprawl is where its cost model gets away from people. Element makes the most sense for organizations already committed to the broader Software AG / Cumulocity ecosystem, where the edge layer is one piece of a larger IoT platform decision rather than a standalone historian choice. Kepware Edge remains a reasonable fit for shops that already have deep KEPServerEX driver investments and want continuity more than a pricing revolution. Ignition Edge tends to suit plants with dense per-machine tag counts and existing or planned Ignition server infrastructure, where the unlimited-tag philosophy compounds in your favor as the UNS matures.
None of these are wrong choices in the abstract — they’re different bets on how your data footprint will grow. The mistake isn’t picking any particular one of these five. It’s picking one based on a pilot-scale feature bake-off and discovering the licensing model doesn’t match your actual growth curve only after you’ve committed budget, integration work, and operator trust to the platform. Model the tag growth first. Then shop.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
