Interested in linking to "SP100 Committee Listens to WirelessHART"?
You may use the Headline, Deck, Byline and URL of this article on your Web site. To link to this article, select and copy the HTML code below and paste it on your own Web site.
By Dick Caro, CMC Associates and ISA SP 100 committee member
For the first time, the ISA SP100 standards committee was presented with some details about WirelessHART at its May 2007 meeting in Austin, Texas. The WirelessHART specification was scheduled to be voted on by the HART Communications Foundation’s membership in June 2007.
Product plans are already in place for the WirelessHART protocol. Products from major suppliers of process control instrumentation are expected to be announced soon after the WirelessHART specification is available and field-tested. In addition to field instruments that support WirelessHART, “small modules” that enable a wired HART instrument to communicate data via the WirelessHART network will be available.
While protocol specifications for WirelessHART are very close in many ways to the planned protocol for SP100.11a Release 1, they’re not identical. Both protocols have been developed independently, with WirelessHART having a narrow focus and SP100.11a having a more general, broader focus. Both have decided to use the same radio technology—IEEE 802.15.4:2006 chips that are also used for ZigBee. This choice of a similar commodity radio chip is like the choice of using commodity Ethernet chips for Foundation fieldbus HSE, Profinet and Modbus/TCP. However, the protocols used for the upper communications layers aren’t the same, which makes it impossible for either network to carry signals from the other.
The committee’s User Working Group debated the effect of the information about the incompatibility between WirelessHART and SP100.11a. Users have always stated a need for one wireless data communications standard in their plants, and this situation would result in two incompatible protocols installed in the same plant areas and operating in the same radio frequency band. There seemed to be only three possible alternatives: request that WirelessHART adopt the SP100.11a protocol; request that SP100.11a adopt a protocol compatible with WirelessHART; or do nothing and allow both protocols to be installed and manage the co-existence issues, if any.
The users debated what they should recommend to the SP100 meeting. It’s useful to follow their line of reasoning as they investigated each of their three alternatives:
How can both of these networks operating in the same 2.4 GHz frequency band avoid interference with each other? Analysis of the proposed Data Link Layer (DLL) services document for SP100.11a shows a well-conceived method for avoiding interference from other devices sharing the same 2.4 GHz spectrum in the plant including WirelessHART, ZigBee and WiFi. ZigBee doesn’t use channel-hopping; therefore, SP100 will dynamically avoid any ZigBee channel in frequent use. SP100’s 15-16 channels are designed to avoid overlap with any WiFi channels that may interfere. Although WirelessHART and SP100 use the same channels, and both use channel-hopping, the channel-hopping sequences are not the same. This means that any interference will result in the SP100 device retrying that message on a different channel that isn’t likely to be the same as the next channel used by WirelessHART. For these reasons, WirelessHART and SP100 will most likely coexist without problems in most situations.
The User Working Group has now agreed to make no recommendations to SP100 or to WirelessHART regarding the potential competition for bandwidth in their plants. The situation, while not meeting the group’s basic requirement for a single wireless protocol, is tolerable and will usually cause only limited problems on an application-by-application basis. Early adopters who do experience any problems will complain to their suppliers, who are expected to make changes to resolve any problems that do actually appear, either by channel assignment or by future revisions of their products.
During the debate on WirelessHART, the point was made that SP100 is intended to be a single “universal” network for the wireless transport of information from all types of industrial wired protocols including HART, Foundation Fieldbus H1 and HSE, Profibus’ PA, DP and Profinet, and Modbus RTU and TCP.
The proposed SP100 Application Layer technology supports HART messages over the wireless network along with data for other protocols providing this “universal” capability for the user, whereas WirelessHART is narrowly focused, only supplying HART data over its unique wireless network. It has also been communicated earlier to the SP100 committee that the Technical Steering Committee of the Fieldbus Foundation has voted to base its future wireless protocol on SP100. A similar response is expected from Profibus International, which previously stated its position to not develop its own wireless protocol, but to influence the design of SP100 to meet its needs.
While most of the field instrumentation suppliers present at the Austin meeting have declared their intent to market both WirelessHART and SP100.11a networks and products, they’ve added that they’ll also make products that support HART protocols in a SP100.11a-compliant wireless network. This means that users will have a wireless network choice for communicating HART protocols with field instruments: a) a WirelessHART only network, b) a SP100.11a only network, or c) both types of networks. Also, it’s expected that some suppliers will make “small modules” available to connect wired HART instruments to an SP100.11a network to capture the diagnostics and communicate them to host systems.
In other news at the Austin meeting, the primary agenda was resolving all problems preventing completion of the standard. At this point, all of the editors are working on creating Principles of Operation (PoO) for each network layer. To complete this document, the scope of the protocol for each layer must be completely defined. This revealed several gaps between layers that were to be resolved during this meeting. This has now occurred, although the resolution is not yet documented in the draft specifications for the respective layers. In general, the document editing work is one or two months behind the original schedule of a completed first draft document by the end of October 2007. Given this, a special editors’ meeting was called in June to get back on schedule for completing the PoO document, which is critical to completing a draft standard by October.
The Application and Gateway specifications, first presented in detail at the Karlsruhe meeting, are now nearing completion as the result of the Austin meeting. The Application Layer has been divided into a Lower Application Layer (LAL) that provides all of the normal AL functions, such as read and write to remote devices, and an Upper Application Layer (UAL) based on EDDL as defined by IEC61804-3 and the draft ISA S104 standard. This allows field devices to exchange data using the common attributes or parameters shared by HART, Foundation Fieldbus and Profibus-PA. These attributes will also be recognized by OPC. Also, the UAL will support a tunneling protocol that will allow transport of other protocols such as Modbus RTU and TCP and CIP common to EtherNet/IP, ControlNet and DeviceNet.
The SP100 Gateway protocol is also being defined to connect directly to any of the supported networks using EDDL with a minimal interface to be specified by each of the supporting organizations. Networks requiring the tunneling support of SP100 will require a Gateway application suited to their own needs where the use of EDDL does not apply, but the wireless portion will be a part of SP100.
Based on these discussions at Austin, the objective of SP100 is to become the universal wireless network for industrial communications supporting HART protocols as well as others. For the process industries, SP100.11a Release 1 is being designed to carry EDD information from smart field devices through the wireless network directly to host systems/networks that are already designed to receive information in this form. By agreement, some of the future standards work necessary for use in factory automation applications needs higher speeds and less object definition, so the standard is also being designed with the tunneling of protocols to serve all of the dominant networks used in these industries.