ISA100 Gives Up on Convergence

No Deal Between ISA 100 and Wireless HART Standards. Back to the Drawing Board

By Dick Caro

2 of 2 1 | 2 > View on one page

No other methods to find a technical path to converge the two protocols have been proposed, and the subcommittee has been disbanded.

Alternative to Convergence

One of the early results of the ISA100.12 meetings was a recommendation by a small group of end users that suppliers could ship products that would be configured by the supplier at the factory, or later by the end user, to operate on either WirelessHART or ISA 100 Wireless. We called this the "dual-boot" solution. Because this was not a communications protocol solution, it was not issued as a work product of the committee. However, since the ISA100.12 committee has now abandoned its convergence search, perhaps users' needs can be satisfied by a dual-boot vendor offering.

There are three ways to accomplish a dual-boot product:

  1. The field instrument can be shipped with both WirelessHART and ISA 100 Wireless communications stacks embedded in ROM. At the time of configuration or provisioning, one of the options to select is the desired communications stack that would then be loaded from ROM. The cost of this method would be a slightly larger ROM.
  2. The vendor would ship the field instrument with its favorite communications stack pre-loaded into the instrument memory. During configuration or provisioning, the user would be offered the option to download an alternative communications stack. Since update of the communications stack is required to perform regular maintenance anyway, this would not add any cost to the device. The vendor would only be required to support the download and instantiation of both communications stacks.
  3. The field instrument can listen to attempts to solicit it to join a network, use the join frame structure to identify the network protocol, and then begin to use the appropriate communications stack.

The advantages of dual-boot are that a user would need to inventory only one wireless instrument for each function (pressure, temperature, flow, level, etc.) that would work on either network. Since no additional hardware is required, the cost difference should be negligible. The disadvantage would be for the instrument company that would be required to support both communications stacks.

Will the instrument companies offer dual-boot wireless field instruments? Not unless users demand them. Instrument companies have no incentive to offer dual-boot instruments. However, continuous pressure from the users can change this situation when at least one major supplier agrees to supply dual-boot devices.


Users do not like the fact that ISA100 has abandoned the WirelessHART convergence effort. Their anger should be redirected to their suppliers of wireless instrumentation and systems in the form of product demands by writing the required functionality into their purchase specifications for wireless instrumentation and DCS.

The fact that their favorite DCS supplier can't interface/support their chosen wireless network is a business decision of the supplier. User demand can change such business decisions. When user organizations write specifications for new DCS or instrumentation systems, they should specify the wireless protocol they need or to specify functionality that they need, and not be forced to specify only the one network supported by their favorite supplier.

Waiting for a single wireless standard is pointless. It will not happen with the current generation of hardware using IEEE 802.15.4 radios. Meanwhile, both ISA 100 Wireless and WirelessHART can meet most current wireless needs, and there is no reason to wait before using wireless. 


ISA100 was formed in 2004 to develop the standards for wireless networks used for industrial automation, including process control applications. By 2007, there was general agreement within ISA100 on the technology to be employed by the standard. In 2008, the HART Communications Foundation (HCF) announced the development of the HART 7 specification that included a wireless option called WirelessHART. HCF supplied some technical information to the ISA100 standards committee to help in aligning their work with the wireless protocol of HART 7. However, the ISA100 committee had already made technical decisions that prevented use of the methods embedded within HART 7, thus assuring that the two networks would not be able to interoperate. The ISA100 technical committee determined that changing these protocol elements to those of HART 7 would have made the protocol non-conforming to the Technical Requirements Document that had been created from the examination of hundreds of use cases compiled by the ISA100 User Working Group.

When the ISA100.12 was formed, it was charged with finding a technical path to converge the two different standards. It decided that the only way to obtain this technical path was to issue a RFP, and then evaluate the results. The User Working Group helped to establish the evaluation criteria by forming CURT (Common User Requirements Team.) Many of the CURT requirements reflected features/functions that were part of the original ISA100 Technical Requirements and were already present in ISA 100 Wireless, but not present in the current version of WirelessHART.

The three responses to the RFP were prepared by the following vendor cooperatives:

  • Team H: Honeywell, Yokogawa, Invensys, General Electric, Masoneilan, Yamataki and Fuji. Proposed the addition of an application suite similar to that specified in IEC 62591 (WirelessHART) to ISA 100 Wireless (IEC 62734.)
  • Team E: Emerson, ABB, Siemens and Endress+Hauser. Proposed some additions to IEC 62591 (WirelessHART) patterned after features/functions of IEC 62734.
  • Team G: General Electric. Proposed a common network management entity that would hide the fact that there were two different networks installed in the same plant facility.

When the Proposal Evaluation Team (Eval) met to understand the technical details of each proposal and to determine how each of the CURT requirements were met, it became clear that the Team H proposal met all user requirements as presented, except that it was not backward-compatible with installed WirelessHART devices. The Team E proposal was found to be incomplete in some areas. As discussions continued, the Eval accepted some missing elements to the Team E proposal when some of their advanced developments already in progress were presented. With these advanced developments, the Team E proposal was determined to meet all CURT requirements, except that it would not be backward- compatible with installed ISA 100 Wireless devices. Since the Team G proposal could use any version of WirelessHART or ISA 100 Wireless, including the newly proposed versions, it was also found to meet all of the CURT requirements. There was no basis for protocol selection based on the only criteria available to evaluate the proposals.

Discussions in the Evaluation Team were highly focused on the marketing effect, not the technology. Due to the competition in the wireless instrumentation market, any compromise agreements were impossible in these meetings. It was decided to document the Evaluation Team efforts by showing these disagreements in the archives of the committee working papers. Having no further methods to obtain a technical path to convergence, ISA100.12 found that its work was complete without a desired result. ISA100 voted to disband ISA100.12.

2 of 2 1 | 2 > View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments