Wireless interoperability? What is that?
Last week I was at the ARC Advisory Group conference in Orlando. While my wife was home shoveling snow, I was trying to get a grasp on some of the issues related to wireless field device networks. (For the record, the weather in Florida was pretty crummy.)
One term that keeps coming up is interoperability. At the moment, the two main contenders for the field device space are WirelessHART and ISA100.11a. Both of these are completed protocols, more or less. The former has a head start in the market. The latter still has some organizational/committee procedural details that need to be resolved, but instrumentation supplier companies that are interested in working with one or both have enough available today to get started. Given the conservative nature of this industry, I doubt many are feeling held back by slow technology developments.
The relevant definition of interoperability in this context seems to be that a user will be able to buy equipment from a variety of sources and there will be no sacrifice of functionality. Both groups claim this, and given time there is reason to believe that there will be sufficient equipment selections available for both systems.
That leaves the question as to what the main difference is between the two approaches. Ultimately it probably comes down to questions as to what the respective protocols are supposed to do. WirelessHART has created a complete protocol, one that goes into great detail as to how the devices are supposed to communicate. On the other hand, 11a has set out to create more of a transport mechanism that is able to carry a package of information. It doesn’t care so much what is in the package. Theoretically, the wireless network can carry anything.
A crude analogy would be to compare the two systems to cell phone networks. WirelessHART’s network says, in effect, that all conversations have to be in English. Using that approach, you know all devices will be able to communicate and there will be no room for misunderstanding. There is certainly some appeal to this. I have heard that the global air traffic control system uses English everywhere for reasons that should be apparent. (But don’t quote me on that fact.) On the other hand, some may decide they don’t want to speak English.
The 11a cell phone allows you to chat in any language. Let’s say you have a device that only wants to speak Esperanto. The network doesn’t care. It can carry the conversation, but you have to make sure that the control system application has the ability to understand Esperanto or the message will be meaningless. The more languages you introduce, the more you have to add to the system to be able to do to deal with it. The same applies in the wired world. If most of your devices communicate using 4-20 mA, and you want to bring in something that uses Modbus or Profibus, you have to add appropriate I/O capability. Of course you don’t have to introduce more languages if you don’t want to.
The role profiles within 11a define the structure of how the conversations are to take place. The ability to use application profiles, which are effectively extensions to user object blocks, allows device makers to choose specialized languages as the situation demands. One end user who plans on using 11a said that he is thinking ahead to field devices that don’t exist yet. He doesn’t know what languages he may have to deal with in years to come, so he likes the idea of having a system that can handle anything.
I’d like to think I’m beginning to get a handle on this discussion, but I’m not all that sure. I suppose my question ultimately is why the two systems can’t be brought together (The technical term that keeps getting used is converged.) by creating a WirelessHART application profile within 11a. Could it possibly be that simple?
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.