James Mimlitz ‘Slim’, SCADAmetrics
The purpose of this paper is to propose a minimum data transmission standard pertaining to water meter consumption readings. The standard would apply to both water meters, as well as meter-reading endpoint devices.
At present time, there are three (3) popular meter communication protocols: Sensus Protocol, Neptune Protocol, and Elster Protocol. Many meter reading systems are “multi-lingual”, in that they can effectively communicate using all three (3) protocols. This paper focuses upon water meters and reading systems that communicate using “Sensus Protocol”.
At present time, the de facto and most popular standard is “Sensus Protocol” with 2 fields: Billing Totalization and Meter ID.
However, there are compelling reasons to include 3 additional fields – powerful fields that have been defined by Sensus (Xylem) within its eponymous protocol – yet are seldom used in practice. The proposed 3 additional fields (green highlighted), in conjunction with the 2 de facto standard fields (yellow highlighted), are proposed as a new de minimis standard:
(c) Extended resolution digits, (d) meter totalization units, and (e) totalization scale factor are important pieces of meter information that have traditionally been omitted at the individual meter data level(1), and therefore by necessity must be implemented at the top billing/metering system level, and applied uniformly across all meters.
For this reason, whenever an individual water meter’s communication settings are configured outside the expected norm, then serious under- or over-billing errors will result. Problems caused by misconfigured meter communication settings are one of the largest observed consumers of technical support resources at all levels: meter manufacturer, meter distributor, installation contractor, and water utility end-customer.
Through inclusion of the proposed full five (5) data fields within the protocol, meter consumption readings can become truly automated to a “plug and play” level, opening up the possibility of eliminating units and scale-factor errors forever.
Additionally, SCADA (Supervisory Control and Data Acquisition) systems & BMS (Building Management Systems) – as well as advanced AMI systems – ascertain rate-of-flow by processing fine-resolution totalization data – fine resolution data that is has traditionally been omitted or disabled in legacy AMR metering systems.
Fortunately, and perhaps most importantly, the proposed additional 3 fields can be implemented in a manner that enables concurrent use of the expanded dataset, without breaking legacy billing and data collection systems that only process the minimal dataset.
This paper will briefly outline the historical progression of the Sensus Protocol communication standard, as well as provide the rationale for expanding the minimum standard to include these additional fields.
(1) As a note of historical precedence, there are two currently-existing implementations of certain components of these recommendations:
- Elster Protocol always includes meter totalization units and scale factor in its consumption message.
- Neptune Protocol always includes extended resolution digits within its consumption message.
Water Meter Registers – Historical Improvements
Since the 1980’s, water meter manufacturers have designed and built registers to encode the totalized consumption and transmit the data to the reading device in ASCII format. This method was the successor to pulse-based totalizers, and it ensured a higher level of billing accuracy and also provided a method for time-saving, radio-based data collection.
At first, the totalizer resolution was fairly limited to only six (6) totalizer digits. However, over time, the available totalizer resolution has increased, as illustrated in the Figure 1 below.
Improved Water Meter Resolution Hampered by Legacy Reading Systems
As the water metering industry has progressed with respect to accuracy and functionality, in practice much of the meter-to-endpoint data transmission methodology has been held back by the inertia of legacy practices.
Case in point: How often do we see high-resolution-capable water meters pre-programmed to transmit only a subset of the available totalization digits? …essentially “dumbing down” the water meter register?
Why is high-resolution metering data important?
- AMI (Automated Meter Infrastructure) Leak detection. Water flows due to both legitimate usage and leaks cannot be accurately detected and quantified by meters that transmit coarse resolution totalization.
- SCADA (Supervisory Control and Data Acquisition) system and BMS (Building Management System). Realtime control and monitoring systems rely upon high-resolution totalization to ascertain rate-of-flow.
However, perhaps there is no greater endorsement of the value of high-resolution encoded totalization data than that of the major water meter manufacturers themselves – all of whom today, without exception, now offer high-resolution encoded registers.
If high-resolution metering data is so important, why doesn’t every utility pre-program its water meters to transmit all available register digits?
- Legacy Billing Systems. Many of the billing systems and software were developed in conjunction with older meter technology.
- Tradition plays a role: “We’ve always done it this way.”
- Valid desire to avoid breaking compatibility with older equipment and systems.
Enhancement 1: Non-Billable Digits Field
Is there a way to install water meters which are programmed to high-resolution within existing utilities, in a way that provides an incremental path toward full-resolution AMI, yet does not break compatibility with existing older equipment and systems?
YES – and the path has been provided by Sensus (Xylem) via a seldom-used feature within its eponymous protocol: Rather than discarding unutilized (for now) high-resolution digits, the truncated digits should be made available for future use by moving them to the ‘NB’ (non-billable digits) field of the Sensus protocol, as follows:
In the example illustrated in Figure 3, a legacy billing and software system will interpret the reading as “123456”, thereby not “breaking” compatibility. Future systems may (and should) feature the ability to parse, import, and process the extra non-billable digits for advanced purposes, such as leak-detection, detailed usage analysis, SCADA monitoring, and BMS monitoring.
Generally, legacy meter reading and billing systems that do not support the Non-Billable field of the Sensus protocol will likely ignore this field – although this behavior should be field-validated before mass deployment.
Enhancement 2: Registration Units and Multiplier Fields
Not all water meter manufacturers feature the same resolution for equal-sized meters. Is there a way to avoid billing and monitoring errors due to incorrect scaling?
As an example, one major water meter manufacturer transmits high-resolution, 8-digit totalization from a 4” gallon registration meter in increments of Gallons x1. Another major water meter manufacturer transmits its high-resolution, 8-digit totalization from a same-size 4” gallon registration meter in increments of Gallons x10. Can interpretation errors be easily avoided? YES – and again the path has been provided by Sensus (Xylem) via another seldom-used feature within its eponymous protocol: the Multiplier and Units Fields, as follows in Figure 4a:
Legacy meter reading and billing systems that do not support Multiplier and Units fields of the Sensus protocol will likely ignore these fields – although this behavior should be field-validated before mass deployment.
Combining All Five (5) Enhanced Fields
Finally, and to provide backward-compatibility to legacy billing systems and forward-compatibility to advanced billing, SCADA, and BMS systems, all 5 Sensus Protocol fields can (and should) be combined. This is illustrated in Figure 5a below, and note that the five (5) pieces of information again paint a complete picture of totalization.
Again – Legacy meter reading and billing systems that do not support Non-Billable Units, Multiplier and Units fields of the Sensus protocol will likely ignore these fields – although this behavior should be field-validated before mass deployment.
Conclusion
For the past 40+ years, the communication standard for reading water meters has largely consisted of the Sensus Protocol. This standard has successfully served the water meter industry as a whole, by providing a method for inhomogeneous makes and models of water meters and reading systems to successfully communicate together.
The de minimis implementation of two (2) fields: Billing Totalization and Meter ID) has been the dominant format, generally due to utility billing system limitations. However, even as meter registers have evolved to provide improved resolution, in practice much of the meter-to-endpoint data transmission methodology has remained stalled at this de minimis level.
The de minimis level is problematic, though, in that it excludes three (3) important pieces of information that can be used to:
- Eliminate Billing Errors due to Meter Configuration Errors
- Implement Leak-Detection algorithms within the context of an AMI system
- Implement Rate-of-Flow Monitoring within SCADA and BMS Systems
In this paper, a step forward was proposed that enhances the minimum standard by including: (a) extended resolution digits, (b) meter totalization units, and (c) totalization scale factor. The proposed step does not require inventing a new protocol, but rather leverages existing components of the generally-accepted, industry-standard Sensus Protocol.
The new, proposed minimum data transmission standard defined a backwards- and forward-compatible technique that will enable water meters to concurrently transmit both the limited picture – and the complete picture – of totalization for compatibility with both legacy and modern analysis and billing systems.
Documentation
Would you like to download a PDF copy of this document? — Click Here
Want to Discuss?…
Hopefully, this paper will spark a conversation. If you’d like to discuss, please feel free to add your comments below.