View Full Version : Question about HSE field devices
markie
December 19th, 2006, 03:12 AM
I noticed that there is no field devices (transmitters and actuators) available for HSE directly. Is that mean HSE not suit for process measurement and control?
Mike Stathopoulos
January 2nd, 2007, 12:03 PM
Hello,
Up to this point, no vendor has submitted an HSE field device for interoperability testing and registration, but that will change soon.
We have one vendor scheduled to test their HSE field device. The Foundation requires at least two separate vendors be able to pass interoperability testing in order for the devices to be registered and legally marketable. I believe this will happen fairly soon and once these devices are on the market, other vendors will follow suit.
As for the suitability of HSE field devices for process measurement and control, I believe they are. Of course, the devices would be more suitable for some applications and not for others. I would have to let those with more expertise in diverse process control applications to further comment on the feasibility of HSE field devices in process control.
Best regards,
Mike
Mike ONeill
January 3rd, 2007, 04:08 AM
I think that the reason (there are no HSE field devices (transmitters and actuators)) is that HSE is a bit of an overkill as far as they go, and also adds problems (like access to local power). Field units that are capable of providing large amounts of useful data, such as multi-stream analysers, will be prime candidates for HSE. Also, most HSE field units will be bridges (linking devices) and connect H1 segments locally.
rezabejd
January 3rd, 2007, 08:04 AM
Mike's point about power is a big factor. I have a few COTS (commercial off-the-shelf) devices that support power-over-Ethernet, but that's using the extremely distance-limited "copper" CAT 5 or CAT 6 cable. When plants run HSE (or any Ethernet network) most will be running fiber, which to my knowledge has no capability to supply power. H1, on the other hand, can be supplied using redundant power in the house and supports copper up to 1900 meters (per spec, but will go farther).
The other huge factor is lack of host support for HSE. It has been a relatively slow slog getting H1 versions of some common 4-20 mA devices. Few manufacturers are willing to take on the expense of developing a product that can talk to 1 or 2 systems (versus 17 that support H1 to one degree or another). I know one that had at least something on the drawing board (or on a marketing power-point slide) but I have yet to see much in the way of actual product.
Finally, I question the need. I know there's some teeth-gnashing by those who have to wait a minute for the lower-priority methods to run, for example when calibrating a valve positioner over H1. When H1 was first starting to catch on in a big way, there were a few people who were predicting that valve positioners were soon going to become "web servers", leveraging ubiquitous (and cheap) Ethernet technology. Presently, wireless is being promoted as the panacea that will allow quick and easy interaction with instruments & valves, at least for diagnostics and "methods" like calibration. No product yet and there are some significant security, availability, and standards issues. I believe I'll be pulling copper wire to valve positioners until I retire, not to say that some clever way of getting chores like calibration out of the process control network wouldn't have value. Questions like expense (how much will it cost to install and maintain) and complexity (will I have to train everybody again to use it) are also yet to be answered and weighed by those of us who vote with our dollars. At the moment, I am content with the features available using H1 communications and methods. EDDL (Enhanced Device Descriptor Language, I think?) is expected to dramtically improve the ability of diverse hosts to support methods and diagnostics on devices that are not from their shop (i.e. calibrate a Fisher valve from Yokogawa DCS). As a customer, I'm happy the supplier community is investing their development efforts there.
vBulletin® v3.8.7, Copyright ©2000-2012, vBulletin Solutions, Inc.