{"id":3790,"date":"2025-09-21T22:37:21","date_gmt":"2025-09-22T04:37:21","guid":{"rendered":"https:\/\/scadametrics.com\/blog\/?p=3790"},"modified":"2025-10-01T20:52:20","modified_gmt":"2025-10-02T02:52:20","slug":"minimum-sensus-protocol-2025-a-proposed-minimum-data-transmission-standard-for-water-meter-consumption-readings","status":"publish","type":"post","link":"https:\/\/scadametrics.com\/blog\/?p=3790","title":{"rendered":"“Minimum Sensus Protocol 2025” \u2013 A Proposed Minimum Data Transmission Standard for Water Meter Consumption Readings"},"content":{"rendered":"
\"James

James Mimlitz ‘Slim’, SCADAmetrics<\/p><\/div>\n\n\n\n

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.<\/p>\n\n\n\n

At present time, there are three (3) popular meter communication protocols: Sensus Protocol<\/strong>, Neptune Protocol<\/strong>, and Elster Protocol<\/strong>. Many meter reading systems are \u201cmulti-lingual\u201d, in that they can effectively communicate using all three (3) protocols. This paper focuses upon water meters and reading systems that communicate using \u201cSensus Protocol\u201d<\/strong>.<\/p>\n\n\n\n

At present time, the de facto and most popular standard is \u201cSensus Protocol\u201d with 2 fields: Billing Totalization and Meter ID.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

However, there are compelling reasons to include 3 additional fields \u2013 powerful fields that have been defined by Sensus (Xylem) within its eponymous protocol \u2013 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<\/em><\/strong>:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

(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)<\/sup>, and therefore by necessity must be implemented at the top billing\/metering system level, and applied uniformly across all meters.<\/p>\n\n\n\n

For this reason, whenever an individual water meter\u2019s 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.<\/p>\n\n\n\n

Through inclusion of the proposed full five (5) data fields within the protocol, meter consumption readings can become truly automated to a \u201cplug and play\u201d level, opening up the possibility of eliminating units and scale-factor errors forever.<\/p>\n\n\n\n

Additionally, SCADA<\/strong> (Supervisory Control and Data Acquisition) systems & BMS<\/strong> (Building Management Systems) \u2013 as well as advanced AMI systems<\/strong> \u2013 ascertain rate-of-flow by processing fine-resolution totalization data \u2013 fine resolution data that is has traditionally been omitted or disabled in legacy AMR metering systems.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

\n\n\n\n

(1)<\/sup> As a note of historical precedence, there are two currently-existing implementations of certain components of these recommendations:<\/p>\n\n\n\n