ISA100.11a vs WirelessHART: Wireless Industrial Networks Compared

Every process plant has the same quiet problem: hundreds of measurement points that nobody wired, because the cable tray, the hot-work permit and the shutdown window cost more than the transmitter. Wireless instrumentation solves that, and for process automation the decision usually reduces to ISA100.11a vs WirelessHART, the two IEC-standardized, time-synchronized mesh networks built for slow-but-critical field data. They share a radio, a band and a family resemblance. They differ in how they treat the network layer, who owns the application, and how much freedom an architect gets in exchange for complexity.

That difference matters more in 2026 than it did in 2012. Plants now want their battery sensors to feed historians, digital twins and analytics without a protocol zoo in between, while cybersecurity rules tighten around every gateway. This article compares the stacks layer by layer, explains how TDMA and channel hopping deliver reliability, walks through security and key handling, gives worked sizing numbers, and ends with a selection matrix and failure-mode list.

What this covers: history and standards (IEC 62591 and IEC 62734), reference architecture, the stack from radio to application, timeslots and hopping, routing, security, gateway sizing, coexistence with Wi-Fi, BLE and 5G, a decision matrix, and what goes wrong in the field.

Last Updated: October 2026

Context and Background

Wired HART arrived in the late 1980s as a digital signal superimposed on a 4-20 mA loop, and it is still the most widely installed smart-instrument protocol in process plants. Our HART protocol field-device integration guide covers that wired baseline. The installed base of HART transmitters produced a clear commercial question: how do we reach the devices whose diagnostics we cannot afford to wire?

Two answers appeared in the second half of the 2000s. The HART Communication Foundation (now part of FieldComm Group) released HART 7 with WirelessHART in 2007, and it became IEC 62591. The ISA100 committee of the International Society of Automation published ISA100.11a, approved in 2009 and issued as ANSI/ISA-100.11a-2011, later published by the IEC as IEC 62734. Treat the exact publication years as approximate when you cite them in a procurement document, and check the current IEC catalog edition; the standards have been maintained and republished since.

Both standards solve the same environmental problem. Process plants are reflective, full of steel vessels, pipe racks and moving equipment, and the 2.4 GHz band is shared with Wi-Fi, Bluetooth and microwave ovens in the control building canteen. A single radio link in that environment will fail often enough to matter. The answer in both standards is the same recipe: precise time synchronization, scheduled transmissions so that devices sleep most of the time, frequency hopping so that no single channel carries the risk, redundant routes through a mesh, and a central manager that watches link health and adapts.

What the two standards do not share is philosophy. WirelessHART is a vertically integrated profile: radio, data link, network, transport and the HART application are specified together, so any certified device works with any certified gateway. ISA100.11a is a toolkit: it specifies the data link, a 6LoWPAN IPv6 network layer, UDP transport and a transport security layer, but deliberately leaves the application layer open, so that HART, Modbus, PROFIBUS or other objects can ride on it. The Silicon Labs ISA100 white paper makes the same point, noting that the standard does not specify an application layer and that solution builders must ensure interoperability among vendors.

That gives a first-order prediction worth keeping in mind: WirelessHART wins on out-of-the-box multi-vendor interoperability and ecosystem size; ISA100.11a wins on architectural flexibility, at the price of more engineering decisions. The rest of the article tests that prediction against the details. For readers building the data path above the gateway, our comparison of OPC UA, MQTT and Sparkplug B covers the northbound options that both gateways typically feed.

Reference Architecture: Two Standards, One Shape

Direct answer: WirelessHART and ISA100.11a both build a centrally managed, time-synchronized mesh. Field devices and routers relay data through an access point or backbone router to a gateway. A network manager sets the TDMA schedule and routes, a security manager issues keys, and the gateway presents data to the DCS, PLC or historian.

Figure 1: Shared reference architecture for ISA100.11a and WirelessHART, from field device to host and twin.

Figure 1 reads left to right. Field devices (pressure, temperature, level, flow, valve positioners, discrete switches) are the leaves. Some also route, relaying neighbors’ packets. WirelessHART adds the wireless adapter, a small battery- or loop-powered unit that attaches to a wired HART device and gives it a radio. Dedicated routers, with no sensing duty, extend coverage where the mesh is thin. Everything converges on one or more access points and then a gateway.

The control plane sits beside the data plane. The network manager builds superframes and communication links, assigns the hopping sequence and chooses graph routes. The security manager generates and distributes keys and applies the join policy. In most real products both run inside the gateway chassis, which is why gateway reliability dominates availability. Emerson’s WirelessHART system engineering guide names loss of power as the primary cause of gateway failure and recommends UPS-backed gateways with redundant host connections.

Roles in WirelessHART

The WirelessHART roles, as the Silicon Labs white paper lists them, are the gateway, the access point that interfaces the gateway with the wireless network, field devices that also route, wireless routers, wireless adapters and wireless handhelds used for commissioning. The network manager normally runs on the gateway, which also serves as security manager. There is no ambiguity about who does what, and that is by design: the spec was written so that independent vendors can implement each role and still interoperate.

Roles in ISA100.11a

ISA100.11a distinguishes I/O devices (which may or may not route), dedicated routers, the system manager (the ISA100 name for what WirelessHART calls the network manager), the security manager, a system time source, the gateway, the backbone router and a provisioning device. The backbone router is the notable addition. It connects the 802.15.4 subnet to an IPv6 backbone, translating 16-bit short addresses to 128-bit IPv6 addresses, compressing headers and handling fragmentation and reassembly. That lets one system manager oversee several radio subnets joined by a wired backbone, which is how ISA100 deployments grow beyond a single access point.

Why centralization is a feature here

Centralized scheduling feels old-fashioned next to self-forming consumer meshes, but it is the reason for the determinism. Because one entity allocates every timeslot and every route, it can guarantee that two transmitters never collide on the same channel at the same moment and that each path has a defined backup. The cost is a single logical point of failure and a dependency on the manager’s quality: a gateway with a poor scheduler produces a poor network no matter how good the radios are. When you compare vendors, you are largely comparing network manager software.

Stack Comparison from Radio to Application

Both standards use the IEEE 802.15.4 physical layer at 2.4 GHz: O-QPSK modulation with direct-sequence spread spectrum, 250 kbit/s, up to 10 dBm transmit power, channels 2 MHz wide spaced 5 MHz apart. WirelessHART uses 15 channels worldwide because the top channel is not allowed everywhere; ISA100.11a defines 16 channels and allows the last to be disabled where it is not permitted. Above that shared radio, the stacks diverge.

Figure 2: Protocol stacks side by side. WirelessHART integrates the HART application; ISA100.11a layers IPv6 and UDP and leaves the application open.

Data link: TDMA in both, flexible slots in ISA100

WirelessHART uses a fixed 10 ms timeslot. In that slot a transmitter sends one packet and the receiver acknowledges inside the same slot, which is why the slot is long enough for a maximum frame, turnaround and an acknowledgement. Slots are grouped into superframes of configurable length that repeat.

ISA100.11a also uses TDMA and superframes, but timeslot length is configurable rather than fixed, typically in the 10 to 15 ms range according to a Honeywell-authored 2011 Control Engineering article (a vendor source, so treat it as indicative). The system manager sets it when a device joins. The standard adds Duocast, in which multiple receivers can acknowledge in the same slot, improving the chance that at least one acknowledgement survives. Flexible slot timing is a double-edged feature: it lets designers tune for latency or battery, and it makes cross-vendor timing assumptions harder.

Network and transport layers

WirelessHART defines its own network and transport layer, with graph and source routing, sessions and end-to-end acknowledgements, and an application layer that is the HART command set. A WirelessHART device is, in effect, a HART device with a radio and a wireless-specific management layer. That is why existing asset-management tools and HART knowledge transfer so directly.

ISA100.11a uses IETF RFC 4944 (6LoWPAN) to carry IPv6 over 802.15.4 and RFC 768 UDP for transport. Routing inside the radio subnet is mesh-under: the data link layer routes with short addresses, graph routing as the primary scheme and source routing as a supplement, so the subnet appears to IP as one link. Each node is individually addressable end to end. The cost of that elegance is header overhead; compression helps but a 127-byte 802.15.4 frame leaves limited payload once security and headers are counted, and larger application payloads are fragmented across slots.

Application layer

This is where the standards stop being siblings. WirelessHART carries HART commands, including a mechanism for conveying wired-HART device data through wireless adapters. ISA100.11a standardizes an object model and services but not a mandatory process-automation profile, and the ISA100 ecosystem supports tunneling or native objects for HART, Modbus and other protocols. The upside is flexibility, and the downside is that two certified ISA100 devices may need extra profile alignment to share data meaningfully.

Comparison at a glance

Attribute	WirelessHART (IEC 62591)	ISA100.11a (IEC 62734)
Radio	IEEE 802.15.4-2006, 2.4 GHz, 250 kbit/s	IEEE 802.15.4-2006, 2.4 GHz, 250 kbit/s
Channels	15	16, last one can be disabled
Timeslot	Fixed 10 ms	Configurable, roughly 10-15 ms (vendor source)
Hopping	Per-slot hopping, blacklisting	Slotted, slow and hybrid modes, per-link adaptive
Network layer	WirelessHART native	IPv6 over 6LoWPAN (RFC 4944), UDP
Routing	Graph and source routing	Graph and source routing, mesh-under
Application	HART commands	Open: HART, Modbus and others tunneled or native
Management roles	Network manager, security manager, gateway, access point	System manager, security manager, gateway, backbone router
Interoperability model	Tightly specified profile	Flexible, profile alignment needed
Primary steward	FieldComm Group	ISA100 Wireless Compliance Institute

Deeper Analysis: Timing, Hopping, Routing and Security

TDMA and channel hopping in practice

Time division multiple access means the network is a shared clock. Every device knows, from a schedule pushed by the manager, in which slot to transmit, in which to listen and on which channel offset. Clock drift is corrected by timestamp exchange in acknowledgements, so a device that has not heard from its time parent for too long assumes it has lost sync and starts searching again. That search is expensive: a device scanning for advertisements keeps its radio on, and battery life collapses. Many “mystery battery drain” tickets are really repeated sync loss.

Hopping is the defense against narrowband interference and multipath fading. In WirelessHART the channel changes after every timeslot according to the hopping pattern and the slot counter, and badly congested channels can be blacklisted. A retry for the same packet lands on a different channel, which is why a single microwave oven or Wi-Fi access point degrades capacity a little instead of killing a link.

Figure 3: Per-slot channel hopping, acknowledgement-driven retry on a different channel and path, and health reporting that lets the manager blacklist channels or reroute.

ISA100.11a offers three channel-access modes. Slotted hopping changes channel every slot, like WirelessHART. Slow hopping holds one channel over several merged slots, which lets CSMA-CA contention-based access coexist inside the schedule and reduces the radio retuning overhead for devices that need to listen for longer. Hybrid mode mixes the two, so a network can use slow hopping for aperiodic or low-latency traffic and slotted hopping for the periodic backbone. The channel selection is adaptive link by link, so a bad channel is avoided only where it is actually bad. That is more precise than a network-wide blacklist and requires more manager intelligence.

Worked example: how many slots does a network need?

The following numbers are illustrative, to show the mechanics, not vendor specifications. Take a WirelessHART network with 10 ms slots. One second contains 100 slots per channel offset and, with 15 channels, up to 1,500 slot-channel pairs per second if the schedule uses every channel offset in parallel (in practice, spatial reuse and interference limits reduce that). A device reporting every 4 seconds, with a three-hop path, needs about three transmissions per report plus redundancy. Assume two scheduled attempts per hop: six slots per report per device, plus a share of advertisement and management slots.

For 100 devices at 4 seconds, that is 100 x 6 = 600 slots every 4 seconds, or 150 slots per second, around 10 percent of a single-offset 100 slot/s superframe times 15 offsets. Raise the update rate to 1 second and the demand quadruples to 600 slots per second against the same ceiling. That is 40 percent of the idealized ceiling. Because neighboring transmitters cannot all share every offset without colliding, and because management traffic, retries and advertisements take their share, the usable ceiling is far lower, so latency rises and spare capacity shrinks fast. This matches the vendor guidance below that gateway capacity falls as update rates quicken, and it shows why the number of devices per gateway is really a number of slots per gateway.

Routing: graphs and sources

Both standards prefer graph routing. A routing graph is a set of directed edges that gives every device at least two ways forward. The manager builds graphs from topology and link-quality reports (RSSI, packet success ratio, retry counts) and downloads them to devices, so a device with a failed neighbor simply uses the alternative edge without asking anyone. Source routing, where the sender lists the hops in the packet header, exists as a fallback and for management traffic. ISA100.11a can maintain separate graphs for event, bulk and periodic traffic, which is a practical way to keep a firmware download from delaying an alarm.

The engineering consequence is that redundant paths are a design requirement, not a bonus. Emerson’s engineering guide expresses it as the “Rule of Three”: each device should have at least three neighbors within effective range, giving at least two communication paths. It pairs that with the “Rule of Five” (at least five devices within range of the gateway) and a percentage rule (about 25 percent of devices within range of the gateway, rising to about 50 percent if more than 20 percent update faster than every two seconds). These are one vendor’s rules of thumb, but they transfer well to ISA100 designs because the physics is identical.

Range and link budget

Effective range depends on obstruction. The same Emerson guide gives indicative figures for its own radios: about 30 m under heavy obstruction, about 76 m medium, about 152 m light, and about 228 m clear line of sight with 10 mW EIRP-class antennas mounted at least 2 m above ground. It also recommends at least 60 percent path stability as a floor and 70 percent for control or sub-two-second monitoring. Ground-level mounting, metal enclosures and tank walls cut those figures sharply. A site survey with vendor tools beats any rule.

Security: keys, quarantine and the manager

WirelessHART security rests on AES-128 and three key classes. A join key authenticates a device the first time it talks to the network; it is unique per device, write-only (no HART command reads it back) and, in good practice, replaced by the network manager immediately after joining. A network key is shared mesh-wide at the data link layer so every hop can authenticate packets without being able to read payloads. Session keys are pairwise between endpoints, so one device cannot read another’s payloads. Control Global notes a typical device holds six keys, five of which should differ per device. Devices can sit in quarantine until an operator verifies manufacturer, model and tag. Emerson’s guide advises treating join keys like passwords and keeping them out of design databases.

ISA100.11a splits protection into transport-layer end-to-end security and data-link hop-by-hop security. Symmetric keys encrypt traffic, while asymmetric keys can be used during commissioning (over-the-air provisioning options exist). The security manager sets policy and handles key generation, distribution and lifecycle. The Silicon Labs paper notes the mechanisms are configurable and optional, a flexibility that deserves a warning: an installed system is only as secure as the policy actually enabled. Verify it on the commissioned network instead of trusting the datasheet.

For both, the weakest link is usually not the cipher but the gateway and the management plane. A compromised gateway exposes plaintext, because the end-to-end session terminates there. Map the gateway into a conduit and zone under IEC 62443, and for regulated vendors note the new obligations in the EU CRA, NIS2 and IEC 62443 mapping.

Gateway sizing and update rates

The Emerson guide supports update rates from 1 second to 3,600 seconds and sizes a gateway by its fastest update rate. Its example says a gateway can serve 100 devices when every device updates every 8 seconds or slower, and that rates faster than 4 seconds can reduce device capacity, so you should check the vendor’s specifications and planner. Silicon Labs, in a different context, cites about 80 devices running without performance impact and up to 250 with trade-offs in latency, throughput or battery life for WirelessHART, and about 50 devices per backbone router and about 500 per system manager for ISA100.11a. These figures come from three sources with different assumptions, so do not average them. Use them as proof that capacity is a function of update rate and topology, not a constant.

The worked sizing example from the Emerson guide is useful: 154 points with 40 percent spare capacity led to three gateways. Separate gateways per process unit also simplifies fault isolation and aligns each network ID with a unit boundary. Redundant gateways double the count from the sizing formula.

Control, not just monitoring

Both standards were designed for monitoring and open-loop applications first. Closed-loop control over a mesh is possible but constrained: the Emerson guidance suggests an update rate three to ten times faster than the process time constant depending on the loop type, and says downstream messages to a wireless control device should arrive within about 30 seconds in a well-built network. That is fine for slow temperature or level loops and wrong for fast flow control. Latency under 100 ms is cited for star-like, single-hop paths by Silicon Labs, but a mesh with retries and three hops will not sustain that consistently. Safety functions are a different matter again; ISA100.11a with PROFIsafe can reach SIL 2 per the Silicon Labs paper, but nobody should design a trip around a shared-band radio without a proper safety case.

Ecosystem, Interoperability and Adoption

Who ships what

WirelessHART is stewarded by FieldComm Group, which runs registration and conformance testing so that devices from different manufacturers join any registered gateway. In practice, the catalog is broad: transmitters, discrete switches, valve positioners, vibration and corrosion monitors and wireless adapters from many vendors, plus gateways from the large automation suppliers. ISA100.11a is supported by the ISA100 Wireless Compliance Institute (WCI), which certifies devices, and its commercial weight sits with a smaller group of suppliers, historically strongest with Yokogawa and Honeywell in particular regions and industries. I have not found current, independently audited installed-base counts for either standard, so treat any share figure you see in marketing as a claim to verify, not a fact.

Interoperability is a real cost line

With WirelessHART, interoperability is mostly a purchasing question: is it registered? With ISA100.11a, a certified device guarantees radio and network behaviour, but object models and profiles can differ above that. Silicon Labs states plainly that the standard’s flexibility leaves interoperability to solution builders. Budget for an integration test bench if you plan to mix vendors on an ISA100 network.

Coexistence and convergence

The two standards do not interoperate on the air. Both occupy 2.4 GHz and both hop, so they can share a plant without destroying each other, but they are separate networks with separate gateways. Many large operators therefore run a dual-gateway architecture and normalize data at the host or on an edge platform rather than at the radio. Two rules help: give each network a distinct channel plan where the vendor tools allow it, and keep the combined density of 802.15.4 radios in one area within what the manager tools can model.

Plants should also plan for competing 2.4 GHz traffic. Wi-Fi channels 1, 6 and 11 overlap most 802.15.4 channels; hopping across all channels loses a few slots to a busy Wi-Fi channel, while channel blacklisting reclaims capacity at the cost of fewer hopping choices. Bluetooth Low Energy hops too and adds a modest, usually tolerable load. For the wider radio picture, including private 5G and Wi-Fi 7 on the factory floor, see our private 5G vs Wi-Fi 7 vs TSN decision guide.

Where newer radios fit

Neither standard competes with Wi-Fi or 5G for throughput. The relevant newer options are narrower. 5G RedCap and later 3GPP releases (see 5G RedCap for industrial IoT) target mid-rate devices with cellular management. LoRaWAN and Wi-Fi HaLow suit long-range, lower-assurance telemetry (long-range IoT selection guide). Ethernet-APL covers the wired side for new intrinsically safe devices. None of them replicate the combination of deterministic scheduling, years of battery life, hazardous-area certified devices and process-industry acceptance that the two mesh standards have. The 2.4 GHz mesh standards are mature rather than fashionable, which in process plants is a virtue.

Figure 4: A practical selection flow for ISA100.11a vs WirelessHART, ending in site survey and security zoning regardless of the choice.

Selection matrix

Situation	Better fit	Reasoning
Large installed HART base, asset management already HART-aware	WirelessHART	Same command set, adapters retrofit wired devices
Multi-vendor device mix with minimal integration effort	WirelessHART	Registered, tightly specified profile
Greenfield site wanting native IPv6 end to end	ISA100.11a	6LoWPAN and backbone routers fit IP architecture
Need to carry Modbus or other objects over the same radio network	ISA100.11a	Open application layer, tunneling supported
Vendor already standardized on Yokogawa or Honeywell ecosystem	Often ISA100.11a	Product catalog and support follow the supplier
Small team, limited RF engineering skill	WirelessHART	Fewer decisions, strong vendor design rules
Very large single-site network under one manager	Depends on vendor	Check actual tested limits, not datasheet maxima

Figure 4 and the matrix agree that the decision is rarely made on radio performance, because the radios are alike. It is made on the installed base, the gateway vendor, the device catalog you need and your architecture for the northbound data path.

Trade-offs, Gotchas, and What Goes Wrong

Treating the datasheet device count as a design value. Capacity is a function of update rate, hop count and the slot budget. A network sized at 100 devices for 8-second updates does not scale to 100 devices at 1 second. Gateways that quietly accept more devices than the schedule can serve show it as rising latency and missed updates, not as an error.

Single-neighbor devices. A device behind a tank, in a pit or inside a metal cabinet with one neighbor has no redundant path. The first time that neighbor’s battery dies or a truck parks in front of the link, the device vanishes. The Rule of Three exists because of this failure.

Gateway as a single point of failure. Because the network manager and security manager usually live in the gateway, a power or software fault takes down the whole wireless network. Use UPS power, redundant gateways for critical measurements and redundant host connections. Test failover rather than assuming it.

Battery life surprises. Battery life depends on update rate, the number of children a router serves, and join or resync behavior. A device placed as a bottleneck router can drain its battery several times faster than a leaf device. Check the vendor’s battery estimator against the real topology and refresh intervals, and treat fast update rates as a deliberate cost.

Join key hygiene. Join keys stored in a spreadsheet or a design database are an authentication bypass waiting to happen. Use per-device keys where possible, rotate them after join, and use quarantine so that new devices are reviewed before they enter the production mesh.

Gateway compromise. The radio cipher protects the air, but the gateway sees plaintext and bridges into the control network. A flat network behind the gateway or an open OPC or Modbus server is the real attack surface. Treat it as an IEC 62443 conduit, restrict northbound protocols to what is needed, and monitor management traffic.

Interference blind spots. Hopping handles transient interference well and sustained wideband noise poorly. A dense Wi-Fi deployment, a badly placed video-transmitting drone or a cheap 2.4 GHz repeater can degrade path stability below the 60 to 70 percent guidance. A spectrum survey before and after commissioning, plus periodic path-stability reports, catches this early.

Over-trusting wireless for control. Wireless adds latency and variability that a wired loop does not have. Use it for monitoring, diagnostics, slow open-loop or slow regulatory control, and design sensible fail-safe behavior when data goes stale.

Mixed-vendor ISA100 surprises. Because ISA100.11a leaves the application layer open, devices that join the same radio network may still expose different objects. Prove the data path from device to historian in a pilot with the exact device models you will buy.

Anti-pattern: choosing on protocol fashion. “IP all the way down” is attractive but does not by itself reduce cost for a plant whose gateway ends in a DCS card. Choose the standard that your DCS vendor, maintenance team and device catalog can support for fifteen years.

Practical Recommendations

Start with the plant, not the protocol. Inventory the measurements you want, their required update rates and their locations, then check which device types each ecosystem actually offers. If your control system and instrument supplier have a clear wireless offering, that usually settles the question, because the network manager’s quality and support matter more than small protocol differences. Unless you have an IP-native architecture goal or a specific multi-protocol requirement, WirelessHART is the lower-risk default for HART-centric plants, and ISA100.11a is a considered choice for sites that value open networking and already work with a supporting vendor.

Do an RF survey and a topology plan before ordering. Place gateways and routers to satisfy redundancy rules, set update rates deliberately, and size gateways with the vendor’s planner instead of device counts. Plan for the data path above the gateway as well: decide how readings reach the historian, the UNS and the digital twin, and how timestamps and quality codes are preserved. For the northbound design, see our guides on OPC UA historian to digital twin ingestion and OPC UA security certificates and hardening.

Treat security as part of the design. Enable the strongest key and join policy your products support, use quarantine, rotate join keys, and monitor management traffic. Isolate the gateway in its own zone and restrict conduits.

Checklist

[ ] Inventory points, update rates, hazardous-area classes and required accuracy
[ ] Confirm device catalog coverage for both candidate ecosystems
[ ] Decide one network per process unit, with separate network IDs
[ ] Run a spectrum and RF survey; record Wi-Fi and BLE neighbors
[ ] Apply neighbor rules: three neighbors per device, five near the gateway
[ ] Size gateways at the fastest update rate, with 30 to 40 percent spare
[ ] Verify path stability of at least 60 percent, 70 percent for fast or control use
[ ] Specify UPS power and redundant gateways for critical measurements
[ ] Enable quarantine, per-device join keys and key rotation
[ ] Place the gateway in an IEC 62443 zone with defined conduits
[ ] Prove the data path to the historian and twin in a pilot
[ ] Track battery, path stability and join events as ongoing KPIs

Frequently Asked Questions

What is the main difference between ISA100.11a and WirelessHART?

Both use 802.15.4 radios at 2.4 GHz with TDMA, channel hopping and mesh routing. The main difference is above the data link. WirelessHART integrates its own network layer and the HART application, so devices interoperate under one profile. ISA100.11a uses 6LoWPAN IPv6 and UDP and leaves the application layer open, which gives more flexibility but needs more integration work to ensure vendors line up.

Are ISA100.11a and WirelessHART compatible with each other?

Not over the air. Their network and management layers differ, so devices from one standard cannot join the other’s mesh. They can coexist in the same plant on the shared 2.4 GHz band because both hop, and many operators run separate gateways for each, merging data at the DCS, an edge platform or a historian interface rather than at the radio level.

Which standard is more secure?

Neither is inherently weaker. Both use AES-128 with per-device join credentials, network-level and end-to-end protection, and a security manager that handles keys. WirelessHART specifies keys more tightly, while ISA100.11a makes mechanisms configurable, so the deployed policy matters. In both, the gateway and management plane are the realistic attack surface. Apply IEC 62443 zoning and verify the enabled settings after commissioning.

How many devices can one gateway support?

It depends on update rate and topology. One WirelessHART vendor guide gives 100 devices per gateway when all update every 8 seconds or slower, with capacity reduced by faster rates. A Silicon Labs paper cites about 80 devices without impact and 250 with trade-offs for WirelessHART, and about 50 per ISA100 backbone router and 500 per system manager. Always confirm with the vendor’s capacity planner.

Can WirelessHART or ISA100.11a be used for closed-loop control?

For slow processes, yes, with care. Guidance from one vendor suggests update rates three to ten times faster than the process time constant and notes downstream messages to a wireless control device may take up to about 30 seconds in a well-built network. Fast loops, interlocks and safety trips should stay wired or use appropriate safety-rated communication and a documented safety case.

Do 5G or Wi-Fi replace these mesh standards?

Not for battery-powered process instruments. Wi-Fi and 5G deliver much higher throughput but have different power, certification and deterministic-scheduling profiles. They suit cameras, mobile workers, AGVs and edge compute. The mesh standards remain the established choice for low-rate, long-battery-life, hazardous-area sensing, and many plants will run them alongside Wi-Fi or private 5G, each in its own role.