ISA100 Gives Up on Convergence

Dick Caro is a principal at CMC Associates and a member of the Process Automation Hall of Fame. He was co-chair of ISA100.12. Learn more about Caro by visiting his Google+ profile.After spending almost four years to find a technical path to converge the WirelessHART specification (IEC 62591) with that of ISA 100 Wireless (ISA/ANSI 100.11a, IEC 62734), the ISA100.12 WirelessHART Convergence Subcommittee has abandoned its work without finding a single convergence solution. The subcommittee had prepared a request for proposal (RFP) asking any organization or group of organizations to propose a technical solution for creating a single specification for a wireless process control network. The hoped-for network specification would replace both WirelessHART and ISA 100 Wireless, but would define ways to address backwards compatibility. Three proposals were received:

• Team E—Based on WirelessHART (IEC 62591); many features of ISA 100 Wireless (ISA100.11a or IEC 62734) added to meet user requirements.
• Team H—Based on ISA 100 Wireless with a HART-based application layer added.
• Team G—Specified a common network management entity that would allow the union of networks based on both WirelessHART and ISA 100 Wireless.

An evaluation team was formed to determine which, if any, of the proposals was acceptable. The selection criteria were based on a set of common user requirements (CURT) developed with the User Working Group. The evaluation team prepared a matrix showing how each user requirement could be met by each of the three proposals. The following is a summary of the evaluation team's findings:

• Team E's proposal could meet all user requirements, but only after certain agreed-upon extensions to the current WirelessHART standard and the Team E proposal were added. No backward compatibility with ISA 100 Wireless recommended.
• Team H's proposal could meet all user requirements after the addition of an application function layer patterned after the one used in the HART specification. No backward compatibility with WirelessHART recommended.
• Team E's proposal could meet all user requirements because it would allow both the existing and extended WirelessHART and ISA 100 Wireless networks to interoperate through a common network manager. No backward compatibility with either WirelessHART or ISA 100 Wireless.

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.

In the end, no proposal addressed the core problem: definition of a single network specification that could replace both WirelessHART and ISA 100 Wireless and offer backward compatibility with both prior existing networks. The basic incompatibilities between the two networks remained, and neither proposal team could accept the requirements to modify their own base network to adopt the other proposal method.

The following summarizes the basic technical incompatibilities preventing interoperability between WirelessHART and ISA 100 Wireless:

1. Time synchronization: ISA 100 Wireless uses the IEEE 1588 method for distributed network time that is also used by IEEE 802.15.4e, the latest version of the personal area network standard. WirelessHART uses a fixed slot time interval of 10 ms and derives time from that base.
2. Slot time: While the ISA 100 Wireless protocol separates slot times from time synchronization, allowing variable slot times, WirelessHART depends on a single slot time to support time synchronization.
3. Meshing methods: WirelessHART uses a dynamic proprietary method to form mesh associations. ISA 100 Wireless also forms mesh associations dynamically in a proprietary way, including the formation of duocast links. WirelessHART supports redundant paths for the mesh, but does not transmit to the redundant node during the same slot time. The duocast method used by ISA 100 Wireless sends redundant messages to the primary node and the duocast node in the same slot time.
4. Network addressing: WirelessHART uses network addresses based on a unique number series originating with the HART Communications Foundation. The low-order 16 bits are in the device, while the high order 48 bits are in the gateway. ISA 100 Wireless is similar except that the number series originates with the IEEE Standards Registration Authority. In addition, ISA 100 Wireless fully supports Internet Protocol version 6 (IPv6) at the link layer.
5. Transport Layer: WirelessHART created a unique transport layer to assure end-to-end delivery of messages. ISA 100 Wireless uses the Internet-standard UDP method to assure end-to-end delivery of messages.

Unless all five of these differences are resolved, interoperability between ISA 100 Wireless and WirelessHART is not possible without messages being stored in a gateway common to both networks, and forwarded to a receiving node on the other network. Direct communications between nodes on different networks is not possible.

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.

Conclusions

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. 

History

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.