Every platform below is marketed on real-time monitoring. None publishes how long, at worst, a value takes to reach an operator’s screen.
An industrial IoT platform connects machines, PLCs, SCADA and MES systems, historians, databases and enterprise applications, stores what they report, evaluates rules against that data, and presents the result to people. It sits above the control layer and does not replace it. Bounded-cycle-time logic stays in a programmable controller below every product on this list.
The OPC Foundation’s ISA-95 companion specification (OPC 10030, 2013) puts systems like these at Level 3, which it describes as covering SCADA systems “for monitoring the process and providing operator control” and data historians. Level 2 beneath it is where responses are “measured in sub-seconds” on PLCs and distributed control systems.
The five below are ordered by architectural model, not by rank: a SCADA-first server on owned hardware, a managed hyperscaler service, a low-code application platform, an open-source self-hosted stack, and an edge-native DataOps product. The comparison runs on three axes: where each spends its latency budget, what each guarantees in writing, and which decisions that latency supports.
Where Python Fits into Industrial IoT
Python is commonly used around industrial IoT platforms for data preparation, API integrations, anomaly-detection models, reporting, and automation scripts. Depending on the platform, developers may exchange data through REST APIs, MQTT, OPC UA clients, JDBC/ODBC connections, or vendor SDKs. Python usually complements the platform rather than replacing its device connectivity, storage, alarm management, or operator-interface capabilities.
What Makes Industrial Monitoring “Real-Time”
No single number answers that, and the standards bodies say so directly. NIST’s Guide to Operational Technology Security (SP 800-82r3, September 2023) states that “the units of real time are highly application-dependent and must be explicitly stated”. The OPC Foundation is more specific: “each level has its own definition for real-time. Level 3 systems consider real-time to mean information available a few seconds after shop floor events occur.”
So real-time at the controller means sub-seconds – and real-time at the platform above it means a few seconds. Both are correct. Only one is what a buyer pictures.
Where the Latency Budget Goes
A quoted “update rate” can mean any of four clocks: how often the source is sampled, how often the server publishes, how often the platform ingests, and how often the screen redraws. OPC UA Part 4 treats the first as a target rather than a promise, calling the sampling interval a “best effort” cyclic rate that is “usually not synchronized” with the underlying system.
Polling adds arithmetic of its own. For a polling interval of T, the forwarding delay falls between one transmission time and one transmission time plus T. A poller therefore costs half a poll cycle on average and a full one at worst, however fast everything downstream is.
Two questions follow that nothing here answers. How old is the number on the screen? No vendor and no independent study publishes a measured sensor-to-screen data-age distribution for any of these five. The stages are known and the arithmetic checks out – the end-to-end figure does not exist in public. Which platform is fastest? Also unanswerable. Four of the five publish nothing about delivery time, the fifth publishes a configured request rate, and there is no bounded worst case anywhere in the set.
What to Require of a Platform for Monitoring and Automation
Automation here means rule-driven action, notification, command dispatch and workflow execution. All five document it. None documents closed-loop control, and NIST is explicit about why the two do not share a network: “Control and non-control traffic have different requirements, such as determinism and reliability.”
Two requirements are worth writing into an evaluation. The first is a documented answer to what happens when a value stops arriving. Eclipse Sparkplug 3.0 (2022) requires a host application to mark every metric from a dead node as STALE, delivered through the MQTT Will Message so it fires even on an ungraceful disconnect. A platform that keeps rendering the last received value with no quality flag is already outside a published standard.
The second is alarm rationalisation, meaning which conditions deserve an alarm at all, not the ability to fire an alert. The UK Health and Safety Executive, citing page 37 of the EEMUA 191 guide, sets the long-term average alarm rate in normal operation at “no more than one every ten minutes” and “no more than ten displayed in the first ten minutes following a major plant upset” (CHIS6, March 2000).
HSE’s illustration is the 1994 Texaco Milford Haven explosion: “in the last 11 minutes before the explosion the two operators had to recognise, acknowledge and act on 275 alarms”, and “the control room displays did not help the operators to understand what was happening”.
Any anomaly detector has to fit inside that budget, and none of these five publishes a false-positive rate or an evaluation protocol against which a buyer could judge whether it will.
1. Ignition (Inductive Automation)
Ignition is a SCADA-first server running on hardware the buyer owns. It is sold per server, and one perpetual licence “gives you an unlimited number of clients, tags, and connections”.
It has what the other four lack: an acquisition cadence the integrator types in. The Tag Groups page defines Rate as the “base update rate for tag execution, in milliseconds”, with a worked example running from 500 ms to 30 seconds. That example is not a specification – the rate is a request rate, not a bounded delivery time. Nothing promises that a 250 ms tag group will deliver within 250 ms under load.
Anomaly detection: none claimed anywhere in the documentation. In a category where nearly every competitor advertises machine learning, that is honesty. Alarm modes are setpoint, bit-state and bad-quality conditions with deadbands, a margin that stops a hovering value re-raising the alarm.
Watch-out: the monitoring surface is a separate purchase. The Ignition Platform edition is $1,200 on the published price list, and Alarm Management is a $3,200 Solution Suite on top of it, with Industrial Historian at $3,500 and Application Building at $13,500.
2. AWS IoT SiteWise
SiteWise is the managed hyperscaler option, and its real asset is the asset model: “declarative structures that standardize the format of your assets”, making a fleet of similar equipment comparable across sites. SiteWise Edge continues “collecting and processing data during internet outages” for up to 30 days.
Its latency behaviour has two tiers. Transforms run per incoming data point and are available “within a few seconds”, while metrics are tumbling-window aggregations, computed over fixed non-overlapping intervals, whose “interval time must be between 1 minute and 1 week”. Raw values arrive fast. Anything SiteWise computes across time cannot be fresher than a minute.
SiteWise is the only vendor here that publishes a number for its own dashboard, on the pricing page: “Your SiteWise monitor dashboard automatically refreshes every five seconds to help ensure that you are visualizing data close to real time.” AWS says close to real time – not real time. The same worked example plots one-minute aggregates, so the screen re-fetches each point roughly twelve times before it can change.
Watch-out: both batteries-included features a monitoring buyer evaluates on have moved. SiteWise Monitor “is not available to new customers” and is “entering maintenance mode”, though AWS states plainly that “AWS IoT SiteWise and Amazon Managed Grafana continue to be fully supported” and that only the visualisation layer is affected. Native alarms “detect in AWS IoT Events”, and the same page carries the notice that “AWS ended support for AWS IoT Events”, so a new buyer builds the CloudWatch replacement chain AWS documents. Anomaly detection integrates with Amazon Lookout for Equipment, discontinued on 7 October 2026.
3. Iotellect
Iotellect is a low-code platform rather than a finished application. It describes itself as an industrial data management platform such as Iotellect for building custom solutions that “connect machines, PLCs, SCADA/MES systems, historians, databases, and enterprise applications in one environment”.
What it offers is reach across tiers. The same server runs on industrial PCs, Linux PLCs and gateways down to a 1 GHz CPU with 512 MB of RAM. Event correlation runs on edge, cloud and on-premise instances alike, with correlators that “can be easily moved from edge to cloud and back whenever practical”.
Its alarm rationalisation is detailed. State triggers carry configurable hysteresis on activation plus separate rearming hysteresis, conditions can be checked against dynamically adjusted baselines such as a monthly average, and escalation rules bind to the number of active alerts and their lifetime. Connectivity covers OPC UA, OPC DA/HDA/AE, Modbus, Siemens S7 “and dozens of other protocols”. Anomaly detection uses named supervised and unsupervised algorithms, with no pre-trained model, no published accuracy figure and no published latency figure.
Pricing is a fixed subscription: $99, $499 and $1,999 per month, with an enterprise tier on request.
Watch-out: there is no operator interface out of the box. “The only off-the-shelf UI of Iotellect is the interface for platform administrators, DevOps engineers and low code developers.” Every screen an operator looks at is something the buyer builds first.
4. ThingsBoard
ThingsBoard is the open-source entry, Apache 2.0 in Community Edition. Its strongest documented property here is that the rule engine is not a cloud service: “the Rule Engine continues to process messages when the Edge is disconnected from the server. Devices are processed, alarms are raised, and data is written to the local database without interruption.” For a site whose connectivity cannot be guaranteed, that is the clearest statement here.
Alarm rules support a duration condition that suppresses short spikes, and alarm timing follows the data, not the server: “This reflects the telemetry timestamp, not the server processing time.” Industrial protocols live in a separate component, the IoT Gateway, which “either polls the device on a schedule or subscribes to updates, depending on protocol capabilities”. Modbus freshness is bounded by that poll interval.
Anomaly detection is not a rule-node type at any edition. It is Trendz Analytics, priced separately from $29 per month, and it “supports only unsupervised clustering-based algorithms”. No platform latency figure is published.
Watch-out: the published SLAs are scoped. Uptime commitments cover Public Cloud at 99.5% and Private Cloud at 99.95%, and the 24-hour response SLA begins at the Pilot self-hosted licence, so the free Community Edition, where most evaluations start, has documented access to neither.
5. Litmus Edge
Litmus Edge does its work at the plant, as an edge platform that “transforms raw OT data into trusted operational data” before anything leaves the site. It publishes what most vendors leave vague: a connection guide of 173 per-device configuration pages across roughly 45 vendor and protocol families, a hardware sizing table, and a public entry price. Alerting and Node-RED automation are included at every tier, and flows can write back to equipment: “you can start and stop a device from a flow, write to a topic, or trigger events”.
The unit of configuration is worth comparing with Ignition directly. Litmus’s OPC UA poll driver asks for a “Polling Interval: Enter a value in seconds”, its subscription driver has no tag-level interval at all, that poll driver carries its own deprecation notice, and the replacement driver’s granularity is not documented publicly. The lesson is not that one product is quicker. It is that the two ask for different units because they are built for different jobs, and the unit of configuration is a better question to put to a vendor than the word real-time is.
Anomaly detection appears as one of the “Built-In Statistical Functions” beside Moving Window and Gaussian Filter, switched off in the entry tier, and the machine-learning path runs a buyer-supplied model. No latency figure is published.
Watch-out: programmatic access is a top-tier feature. “SDKs, Rest API And Data API Access To Litmus Edge And Litmus Edge Manager” is unavailable in both Foundation and Growth, alongside Digital Twins and Kafka broker access. Foundation itself starts at $1,500 per month.
Edge, On-Premise or Cloud
NIST frames deployment as a timing question rather than a cost question: “Some systems may require computation to be performed as close to sensors and actuators as possible to reduce communication latency and perform necessary control actions on time.” Where a human can be in the loop, the problem is monitoring and any of these models can serve it. Where a human cannot, the problem belongs to a controller and no dashboard solves it.
Ignition documents shared-database and REST patterns rather than named MES or ERP connectors, and SiteWise routes through AWS services without evaluating external alarms itself. ThingsBoard reserves its AWS, Azure and Kafka integrations for the Professional Edition, Litmus itemises connectors including Databricks and Kafka, and Iotellect exposes IoT analytics and machine data integration “through any supported protocol, such as HTTP, MQTT, or JDBC/ODBC, as well as via open-source Java/.NET/C++ APIs”.
What to Test Before Buying
Cost at scale cannot be compared here. Published entry points differ by two orders of magnitude, none is like-for-like, and none is a total cost of ownership. And silence in a public document is not a commitment. For ThingsBoard and Litmus Edge, no publicly published latency commitment was located, which is not the same as a vendor declining to offer one in a negotiated contract.
If Python will be part of the architecture, test how easily the platform exposes current and historical data to external scripts. Verify authentication, API limits, timestamp handling, data-quality indicators, MQTT or REST support, and whether Python applications can continue operating during temporary network interruptions.
No vendor publishes the number that matters, so the proof of concept has to produce it. Require every value on an operator screen to carry a source timestamp and a quality flag that survives to the screen, then pull the link and watch what the screen does, as Sparkplug specifies. Keep alarm evaluation at the edge, so a change in a cloud service cannot strand the safety-adjacent part of the deployment. Then record the measured age distribution and keep it.
Real-time is not a feature to compare. It is a number to measure.
