By Walt Boyes, Editor in Chief
Wireless systems are coming to your plant. Fact is, this is old news. Weve talked about it for a while now. ( See our Field Guide to Industrial Wireless).
You probably already have wireless devices in your plant, because wireless isnt limited to sensor networks. You already have analog wirelesshandi-talkies, maybe some point-to-point analog wireless sensor signals, 802.11 a/b/g/n WiFi, cellphones and maybe even some Bluetooth M2M (machine to machine) connections. You may even have one of the newer digital mesh-based wireless sensor networks.
You may have more than one.
The problem now is how to establish policies, procedures and engineering best practices for using wireless systems effectively. This is because there are three completely incompatible, non-interoperable, and potentially interfering standards in the traditional field device space. These are WirelessHART, ISA100.11a and ZigBee PRO.
Hoarding Their Moldy Peanuts
The ISA100 standards committee, which was formed to help industrial wireless users, especially those in the process industries, has been deadlocked in a struggle for the control of the ISA100.11a standard (see editorial Not Playin Nice) for three years. One faction wants the adoption of the existing WirelessHART standard (HART 7.1), while another faction wants adoption of a standard that is very close to the Honeywell OneWireless proprietary implementation. These two factions have been in a close-in knife fight for years, with no end in sight. A group of end users on the committee have proposed of the adoption of another standard, ISA100.12, which would be the WirelessHART standard. At this writing, it isnt clear what that will do, other than put two mutually incompatible and non-interoperable standards under the ISA100 umbrella. Another group of ISA100 members has acted to try to do the same for ZigBee PRO, which might wind up as ISA100.13.
Until the standards committee gets off its collective posterior and works something out about interoperability and incompatibility (see sidebar for definitions), it is going to be up to end users to set evaluation criteria and policies and procedures and generate engineering best practices.
What should those criteria and best practices be? One of the anonymous end users who responded to this years Control/ISA100 Wireless Survey put it very bluntly:
ISA and my wireless vendor need to specify what plant wireless surveys I must conduct prior to designing my new wireless network. They must tell me how to do it and provide the tools, or they need to do it for me. They need to develop engineering guidelines so I know how to mount my field instruments and field routers to get a reliable wireless network. ISA needs to develop wireless documentation requirements, such as symbology for P&IDs, network diagrams, ISS sheets, tag naming and others, so I can document my system adequately. When I spec and purchase my instruments, I need to know what factory configuration is required to make sure they will plug in and play when turned on. I dont want to be forced into site configuration. My vendor needs to tell me how to configure wireless devices in my off-line project DCS database, including use on displays, engineering config, use in logic, etc. And finally, I need to understand what are the appropriate SAT & FAT tests required for wireless devices, if any.
It would be nice, of course, if ISA100 would generate this information, but it doesnt seem like thats on the horizon any time soon, although there is a team working on it.
Meanwhile, the benefits of wireless in your plant are still greater than the additional pain and effort you will have to go through to manage three completely incompatible standards.
Interestingly, the three standards, WirelessHART, ZigBee PRO, and ISA100.11a all use the same radio and all are mesh networks. What this means is that it is probably practical to have more than one of them in your plant. A pain, to be sure, but practical.
Why is it going to be practical? It will be possible to use multiple IEEE802.15.4 networks in the same air space because they can be made to not interfere with each other by means of channel-hopping, channel-blanking and other firmware capabilities. This does not mean they will interoperate, and they wont be interchangeable, and theres the pain.
The ISA100 committee expects to release an ISA100.11a standard late this year or early next year. Honeywells global director of wireless, Jeff Becker, announced at the 2008 Honeywell User Group Americas, Our implementation of Honeywell OneWireless is going to be convertible by a firmware upgrade to the final ISA100.11a standard.
At least two other companies expect to produce ISA100.11a products by the end of March of 2009.
WirelessHART has somewhat of a lead in this respect. Controls count shows at least 14 vendors will have WirelessHART-enabled field devices, including sensors, transmitters and control elements (valves, etc.) available for purchase by March of 2009. Six companies (ABB, Airsprite Technologies, Emerson Process Management, Endress+Hauser, Pepperl+Fuchs and Siemens Energy and Automation) have announced WirelessHART products available by the end of 2008.
ZigBee PRO devices and software stacks are already in manufacture and could appear at a plant near you (probably in the HVAC systems) any day now.
But as the survey respondent quoted above noted, figuring out the wireless field device standard isnt nearly as important as figuring out how to engineer, specify, purchase and install the devices, and even who will own the networks in the plant.
Start Planning Now
If you are going to install wireless devices, plan ahead, recommends Alan Autenrieth, of Conoco-Phillips Sweeny, Texas, refinery. You have to have a plan, and you have to work to the plan.
List all the kinds of wireless devices you use and intend to use, not just the wireless sensors that will use WirelessHART and ISA100.11a. Those standards are both evolving to include other sensors, RFID tags and the ability to pass other data. Decide if you are going to include wireless operator stations, wireless-enabled calibrators and bar-code readers, and design your network accordingly.
You also need to decide on a plant-wide or even corporate-wide level who owns the wireless networks. Many respondents to the Control/ISA100 survey indicated that they were involved in discussions with IT over this point.
We came to an agreement with IT, Autenrieth said. They own the corporate LAN, and we own the plant floor. We coordinate with them, but were responsible for the wireless network in the plant.
Design for Scalability and Robustness
You may want to begin with the backbone. Honeywells Dave Kaufman urges this method. You dont want to get caught with no more bandwidth, he said, or with having to rip and replace lots of network because you cant scale it up any more. Companies like Apprion, Honeywell, Cisco Systems and others are in the business of providing wireless backbones, not just field-sensor networks.
You may also need to do wireless surveys. Doing the Verizon Mans can you hear me now? walk only works for small systems, like the prototype starter kits many vendors are now supplying for people who want to get their feet wet in wireless.
You also have to design for robustness. We had to design our antenna towers to withstand 120 mile-an-hour winds, Autenrieth noted, and to keep operating when they were swaying.
Robustness means making sure that the devices you install are suitable for the service. Rob Brooks of PPG, Lake Charles, La., talks about having to remove the first set of network nodes he installed because, although they were designed for outdoor service, they were not designed for outdoor service in a caustic soda plant. The caustic fumes dissolved the rubber grommets around the indicator LEDs and damaged the circuit boards. Robustness means deciding whether you will go with battery power, a combination of battery and line power, solar backup or a combination of all three. In the event of emergencies, it is comforting to know that the wireless network will keep working.
Purchasing and Engineering
Once youve gotten beyond the testing phase, you need to move quickly to standardize. We have an approved vendor list, Autenrieth said, and we added the wireless devices and components to it using proper procedures. Now engineering and procurement can work with the same procedures as we use for any sensor or network device purchase.
This is extremely important if you work with an EPC or a system integrator. By moving quickly to establish standards for wireless networking, wireless sensors and other networking appliances, you run substantially less risk of getting an orphan system that isnt compatible with the rest of the plant.
In the Control/ISA100 Wireless survey, temperature and pressure measurement are the big key metrics obtained wirelessly.
Do It Yourself
As far as drawings and specifications are concerned, companies are doing it themselves in the absence of best practices, standards and guidelines from ISA.
For example, how do you show a wireless sensor on the P&ID? We have used the Unguided electromagnetic signal symbol, Brian T. Smith of INEOS-Nova in Sarnia, Ont., wrote in a post to the Controls Manufacturing Community List. See ISA5.1, 1984(R1991) page 28, section 6.2.8 Electromagnetic or Sonic (Notguided)... a Sinewave with no center line (not guided), it is a free download for ISA members. This symbol has been used at the individual field Instruments and receiving Instrument symbols. Nothing is shown regarding the radio communications system details. These may be best shown on other types of drawings.
Control columnist John Rezabek, suggested, Could you use a note to cover wireless devices? (e.g., Note 3: Wireless connection to host) . . . and default to the data link symbol to connect transmitter to indicator?
As a result of this discussion, Bob Szoke, an engineer at Marathon Oil, is using the following approach:
Get Started Now or Not
Wireless is here. Youre going to be pushed to get started, and youll need to figure out things for yourselves, just like you did with fieldbus.
Deciding to do nothing is a valid choice, and with the multiplicity of standards, incompatibility of device networks, and the lack of good engineering best practices, many end users will make that choice.
