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.
This is a great idea, with visible no downside. More information is better. How do the end users affect this change? Is there a petition to sign?
Jim –
This is a well written document, and I hope that this can catch some traction! These modifications to existing protocols would be invaluable to water systems.
As you well know, this is something we commonly experience as a small integrator here in Western Kentucky, and I’m sure this is a widespread issue across the country.
I have and will continue to push the SCADAmetrics products to our customers. As it has proven to be an asset in leak detection and overall system performance.
Fortunately, in most applications, we have convinced customers to purchase meters with the highest resolution available and segregate these meters from billing software.
Having the best of both worlds is what manufacturers should be striving towards in 2025 and beyond.
Hello Jim,
Thanks for this opportunity to comment, but I like to say I am coming from the BMS and Energy recording industry and not from the water metering professionals side of things.
My thinking: I am looking for the simplest way to get an encoder type meter translated to Modbus /IP or Modbus RTU.
My industry counts pulses mostly, but there are weaknesses to that with missing pulses, broken wire, re-loaded controller loosing past history, tampering, etc. (Some manufacturers have inputs with scan rates too slow for transistor pulses).
Modbus / IP seems fairly universal. If you can get it to have settings thru a HTML page, be up to 100Mbaud and probably half the physical size, it would be in-line with current control devices of today.
Your point of having the major manufacturers having a more universal data train would be a major accomplishment unto itself. And I would think more amiable towards connectivity with different platforms.
I know there are many forms of flowmeters and interfacing, but I really like using positive displacement meters for varying non-consistent flow measuring. (Restrooms, kitchen water usage; humidifier tank usage; scrubber water replacement usage, etc.)
If you reinvent yourself, don’t forget to also market it towards the BMS industry (like KELE?) and also to the Energy (WAGES) tracking industry, We use Aveva-PI for collecting Energy data here. I would emphasize the fact that the Modbus value always represents the exact meter register value at any given point in time. And flow rate is a handy attribute also.
As always, best wishes on your endeavors,
Thanks, Steve, for your thoughtful response.
The water meter industry status quo has a definite affect upon the BMS sphere, and presents a couple challenges that I hope can be solved via the outlined recommendations:
1) Coarse encoder resolution.
when the encoder type water meter arrives to the campus pre-programmed by the meter manufacturer with coarse resolution, our SCADAmetrics equipment cannot easily discern flow rate.
Flow rate is typically important for BMS and SCADA applications, but the reason the meter manufacturers often omit it is because their baseline utility customers’ billing software sometimes cannot handle the high resolution.
My proposal somewhat threads the needle, in that it allows for low resolution digits to be sent on the wire to the EtherMeter plus the extra high resolution digits appended — using the protocol’s nonbillable field.
The billing systems can ignore the extra non-billable digits, whereas the EtherMeter can (and will) utilize them — thereby not breaking compatibility with the utility reading systems — while at the same time, providing the BMS type systems with the flow rate data that we seek.
2) Not including units and multiplier.
this requires the BMS system EtherMeter user to manually enter (via setup menu) the units and multiplier. if this info were to be embedded into the encoder signal message by default by the meter manufacturer, then EtherMeter setup would become more simplified (because the EtherMeter will automatically self-configure based upon these fields automatically).
Hey Jim,
Excellent write-up and proposal.
Very compelling and I will get with Sensus to hopefully push them to be a front runner in this adoption as it’s a direct adjustment to their protocol and not another’s.
Thanks,
Jim,
….. THIS WAS AN INCREDIBLE PAPER!
What stood out to me most is that you’re not proposing a new protocol or a disruptive overhaul — you’re pointing out that the building blocks are already there in the Sensus protocol, just underutilized. That’s a powerful argument, because it makes the leap to adoption much smaller while unlocking a lot of value that utilities, integrators, and SCADA/AMI vendors are currently leaving on the table.
The five-field minimum you outlined makes sense for a few reasons:
You’re right that misconfigured units or scale factors drive a disproportionate amount of support issues. Utilities shouldn’t be relying on “institutional memory” or custom multipliers at the head-end when those fields could be standardized right from the endpoint.
Extended resolution digits are key here.
The fact that manufacturers have already embraced higher-resolution registers, but we’re still chopping off digits at the transmission layer, is a classic example of the protocol holding back the hardware. Those “non-billable” digits could make a huge difference for continuous leak detection and short-interval consumption analytics.
As you pointed out, rate-of-flow calculations depend on fine resolution data. Having those extra fields standardized across meters and protocols would immediately make water more “SCADA-friendly” without custom engineering every time.
The whole backward-compatibility angle is also critical. By letting legacy billing systems read only what they expect, but still carrying the full dataset forward that in and of itself is realistic path that utilities can adopt incrementally instead of “all or nothing hail mary.” This would usually result in the difference between an idea that sits in a white paper and one that gets full blown OEM traction and translates to in the field changes that make a difference.
Absolutely incredible.
A couple of thoughts and questions your paper sparked for me:
Do you see this shift being utility-driven (from billing frustrations and a push for fewer errors) or vendor-driven (AMI/SCADA platforms proving the ROI of using non-billable digits and multipliers)?
My sense is that vendors might lead, since they can show immediate analytics benefits, but utilities will have to absolutely demand it at scale for manufacturers to make it the default.
OEMs are not easy to gain traction with unless they also see a margin benefit if you will in pushing this.
You noted that Elster always includes units/scale factor, and Neptune always includes extended digits. If the Sensus world formally adopted all three extra fields, we’d essentially have a “lowest common denominator” that already exists across the three major protocols. That seems like a strong case for calling this the true industry minimum.
Beyond billing and SCADA, I wonder if exposing these extra fields opens the door to predictive maintenance or asset health monitoring. For example, utilities could start spotting irregularities in flow resolution that point to mechanical register wear or endpoint configuration drift before it becomes a billing dispute.
In short, this feels like a very practical step forward — one that’s small enough to be realistic, but big enough to actually change the way utilities manage data. I’d love to hear how you see the industry reacting. Do you think manufacturers will quietly embrace it to cut down on support calls, or will it take a concerted push from utilities and SCADA vendors to make it stick? After all, if they aren’t buying, no one is going to make the manufacturing capacity or push to make it happen.