Flow measurement techniques continue to grow and evolve with new methods such as multipath ultrasonic, magnetic and Coriolis increasing at the expense of more traditional technologies such as orifice, weir and other differential pressure (DP)-based techniques. The increased use of these new technologies is partly a result of the increased capability of microprocessors and sensors to enable measurements not possible without enhancements in these areas. Another reason for their adoption is that, in most cases, they also provide higher accuracy and rangeability than DP technologies. But most of these flow measurement techniques tend to require more energy than DP flowmeters, and hence aren't well suited for deployment as wireless devices.
A colleague on one of the international standards teams I belong to indicated at a recent meeting, during a conversation on wireless and batteries, that their company has only been able to find one source for a battery suitable for their wireless transmitters to meet a 10-year service life. This is, of course, with periodic recharging. Other rechargeable batteries tend to have ‘memory’ and other problems resulting in operating life of closer to five years.
A bigger concern with using wireless for flow measurement is the dynamics of the process itself. The majority of flow loops, especially for liquids (incompressible fluids) have very short process response times, often in the order of seconds, unlike temperature and level, which tend to be much longer (arguably measureable in minutes). Therefore, if using a wireless sensor for flow control, you'll need a rapid update rate for the transmitter at a minimum, which of course leads to short battery life, and consequently make the economics for cable look better.
[pullquote]
Of course, it would help if it were possible to develop the perpetual motion machine and scavenge some energy from different flowmeters to maintain or charge the batteries. For example, if the frequency-shedding bar of a vortex meter, or paddle/turbine in those forms of meters, or pulsations in a positive-displacement meter could drive some form of coil while not affecting the measurement proper, this would eliminate the energy concern for each of these forms of meter.
One way to address the response time issue is to increase the capability of the flow device by adding the ability to perform as a single-loop or self-contained flow controller. Then the control loop only requires transmission of the output to the final control element and remote HMI when such a change is required, which isn't likely to be every sensing or update cycle (assuming the control system can accept some degree of dead band on the signal). If the dead band isn't acceptable, then having the transmitter update the control system for historian and measurement purposes every cycle and the output directly to the device “as needed” is a much more complex situation of managing different update rates from one device depending on data type.
An alternative to every-cycle updates that may be acceptable is using a totalization option for the update rate to the control system, which risks losing raw data granularity. With all these features, the transmitter is getting closer to the Open Process Automation (OPA) forum's vision of a device control node (DCN), and closer to a SCADA RTU field controller being monitored and controlled (i.e., changing setpoint) remotely from the central control station. SCADA typically includes wireless but again, with longer update cycles and the need for intelligence at the field end.
As the above discourse indicates, monitoring versus controlling has a significant impact on system design. The apparently simple choice of monitor versus control or custody transfer affects not only the type of sensor required, but as we can see, how that device interacts with the control system and other devices within the control system. Though true for more than flow measurement, the impact is more pronounced with fast control loops such as flow, regardless of how innovative we try to be to overcome the basic principles and reason for which the system is being installed.
About the author: Ian Verhappen