White paper Platform comparison 10 min read

Edge Platform vs IoT Platform

Understand the difference between local operational execution and broad device-data management.

An edge platform and an IoT platform often overlap, but they begin with different responsibilities. An edge platform is primarily concerned with executing and operating work near physical equipment. An IoT platform is commonly concerned with connecting, managing, and using data from many devices. A practical architecture may need either one or both-provided the local critical path and integration boundary are clear.

// Definitions

Start from the operational responsibility

An edge platform is the local operating layer around physical systems. It connects to equipment, runs local tasks and specialist processing, retains data at the site, evaluates events, applies rules, monitors the runtime, and exposes controlled paths to users and external systems. Its central design question is: can this local workload continue to meet its operational contract when remote services are unavailable?

An IoT platform is a broader category. It commonly provides device registration, connectivity, telemetry ingestion, messaging, dashboards, fleet visibility, integrations, and sometimes rules or analytics. Many IoT platforms are cloud-centred, but they may include local gateways or agents. Their central design question is often: how can an organisation connect, manage, and use information from many distributed devices?

The categories are not mutually exclusive. Some IoT platforms extend into local execution; some edge platforms provide IoT protocols and fleet visibility. The useful distinction is not a label on a procurement document, but which platform owns device connectivity, local processing, data retention, event authority, and lifecycle operations for each workload.

// Comparison

Compare the platform starting points

Area	Edge platform emphasis	IoT platform emphasis
Primary purpose	Operate local workloads near equipment with known timing, storage, and recovery requirements.	Connect, observe, manage, and use information from a population of devices.
Execution location	Runs at the site, device, line, building, or local gateway.	Often centralised, though may use gateways or edge agents for field connectivity.
Device interaction	Direct access to local protocols, media streams, field buses, and adjacent processes.	Usually normalises messages and telemetry from devices or gateways into a common service.
Local resilience	Designed so local acquisition, processing, storage, and rules can continue through an upstream outage.	Varies by product and gateway design; cloud-centred workflows depend on a remote path for the services they use.
Data handling	Keeps raw, high-rate, or sensitive inputs local and publishes selected results.	Collects and manages telemetry at scale; often emphasises central ingestion, visualisation, and downstream integrations.
Operational model	Components, tasks, events, actions, resource health, local configuration, and site recovery.	Device inventory, provisioning, message routing, dashboards, user access, and fleet-level workflows.
Typical strength	Time-sensitive physical operations and reliable local execution.	Wide device visibility, standardised telemetry, and cross-device or enterprise integration.

Neither pattern alone guarantees a complete system. An edge runtime without a clear upstream data contract can become an isolated appliance. An IoT service without a local execution design can leave physical operations exposed to network and latency constraints.

// Where edge leads

Use an edge platform when local operation is the first requirement

Work must continue during disconnection. Recording, measurement, local analysis, rules, or a bounded operational response cannot pause while a WAN path is unavailable.
Raw data is high-rate or site-sensitive. Video, audio, images, waveforms, and dense telemetry should be processed or retained near the source before a selected result is exported.
Field protocols are part of the workload. The platform needs direct handling of cameras, Modbus equipment, serial lines, MQTT devices, local files, or specialist processes.
Local context determines meaning. A result must be interpreted together with machine state, a nearby event, a local dashboard, or an on-site operator workflow.
Recovery has to be local and specific. Operators need to diagnose a source, task, rule, storage boundary, or runtime resource without treating the site as an opaque device.

// Where IoT leads

Use an IoT platform when the primary challenge is the device estate and its data

Many devices need a common telemetry contract. The organisation needs consistent identifiers, topic conventions, message schemas, and a shared view across locations.
Central integration is the main outcome. Device state must flow into reporting, enterprise applications, data warehouses, customer services, or cross-site analytics.
Fleet-level visibility matters more than a local real-time path. The workload is principally about inventory, status, provisioning, trends, or central alerting.
Field devices already speak a suitable message protocol. Sensors and gateways can publish structured data without a complex local processing or media pipeline.
Centralised rules are acceptable. A short delay or temporary loss of the workflow does not create an unacceptable local operational outcome.

Even in these cases, do not assume the physical system itself is cloud-native. A device may require local buffering, protocol adaptation, security controls, or fallback behaviour before it can safely participate in a central IoT service.

// Complementary architecture

Use the edge as the local operating layer and IoT services as selected consumers

A common architecture puts the edge platform at the device boundary and uses an IoT platform or message ecosystem for shared telemetry and enterprise workflows. The edge node connects to equipment, normalises local state, executes time-sensitive processing, stores evidence, and turns conditions into events. It then publishes a defined data package: a measurement, status transition, quality result, alarm, file reference, or aggregate.

Banalytics component, task, event manager, and action pipeline — At the edge, a connected component feeds tasks; tasks produce events; Event Manager rules select the action or integration that should follow.

That separation limits coupling. The local node continues its required work even if an upstream consumer is unavailable, while the IoT side receives consistent, contextualised outcomes. The downstream consumer can change without rewriting device-level logic, and the edge deployment can change without exposing every raw implementation detail to other systems.

// Banalytics scope

An edge platform with practical IoT connectivity

Banalytics is primarily an edge orchestration and monitoring platform for cameras, sensors, and physical systems. Its local Agent provides components for connected resources, tasks for local processing, Event Manager rules, actions, storage, browser dashboards, runtime monitoring, and controlled remote access. Capability is delivered as independently versioned modules, allowing a deployment to add only the local functions it requires.

It also covers common IoT-facing integration patterns. Modbus Line connects and polls one or many industrial devices on a serial or network line, tracks state and errors, and produces device-state events. The embedded MQTT Server provides a local broker for sensors, gateways, scripts, and Banalytics components, with configuration options for authentication, TLS, persistence, and runtime statistics.

These capabilities do not make every IoT platform redundant. They provide an explicit local boundary where physical devices can be operated and their results prepared for any approved external consumer. The right integration contract still needs to name topics or APIs, payload schema, ownership, rate, retention, security, and behaviour during a broken upstream connection.

// Hybrid platform

Banalytics combines edge execution and IoT functions in one local platform

Banalytics is hybrid in an architectural sense: the same local Agent can carry the responsibilities normally associated with an edge runtime and the practical IoT functions required to connect, normalise, route, observe, and publish device information. This removes an unnecessary boundary between the system that performs local work and the system that exposes its structured outcomes to other devices, users, and services.

Hybrid capability	Edge function on the Agent	IoT function on the same platform
Connected physical assets	Operate local cameras, media, field devices, files, and processing tasks near the source.	Connect sensors, gateways, and controllers through MQTT, Modbus, ZeroMQ, and defined external interfaces.
Local state and action	Execute tasks, evaluate events, store evidence, and apply authorised local rules during an upstream outage.	Publish device state, measurements, alerts, and outcomes to subscribed local or external consumers.
Messaging and integration	Keep local processing and time-sensitive paths close to equipment.	Run an embedded MQTT broker when appropriate, expose APIs and integration actions, and route selected messages by contract.
Operations and visibility	Monitor runtime CPU, memory, storage, tasks, media activity, and local service health.	Provide dashboards, event history, remote browser access, and multi-site visibility for authorised users.
Lifecycle	Install and run only the modules needed at a specific site.	Maintain independently versioned capabilities and publish compatible integration outputs as the site evolves.

The hybrid model is especially useful where a sensor-only IoT integration grows into a local operational workload, or where a camera, machine, or building system needs both immediate edge processing and standard IoT-style data exchange. The system does not need to send raw inputs to a second platform merely to create a usable device event or telemetry message.

For a practical multi-Agent implementation of this hybrid boundary, see Edge Orchestration Platform. Its sensor-to-RC-vehicle example combines local Modbus acquisition, Python processing through ZeroMQ, MQTT data exchange, and a separate Agent that retains the vehicle-side device and action boundary.

This does not mean Banalytics replaces every enterprise IoT suite, data warehouse, digital-twin service, or cloud device-management product. Those may remain the right consumers for selected outputs. Banalytics provides the local edge and IoT boundary that makes those integrations deliberate, observable, and resilient.

// Selection checklist

Ask six questions before choosing the platform boundary

What must happen locally? List the acquisition, storage, processing, and response paths that cannot wait for a central service.
Which devices and protocols are in scope? Confirm whether a direct local connection, a gateway, or a message interface is required for each one.
What is the smallest useful upstream result? Define the structured event, measurement, file reference, or summary a central IoT service actually needs.
Who owns the operational state? Decide whether local rules, central workflows, or both may trigger an action, and preserve the authority boundary.
How will the estate be operated? Specify monitoring, update, access, recovery, and support responsibilities for both the local node and the central service.
Can the integration fail safely? Test an upstream outage and verify that the local workflow and data boundary behave as designed.

Edge platform versus IoT platform is not a binary selection. It is an architectural division of labour. Put execution and responsibility near the equipment when the physical process demands it; use IoT services where fleet-wide data management and shared integration add value.