A New and Smart Gas Meter with Blockchain Validation for Distributed Management of Energy Tokens

Abstract

The design philosophy of a new smart gas meter is presented, based on an ultrasonic sensor employing LoRa and/or NB-IoT protocols and blockchain technologies to overcome the data integrity and security issues with a completely modular design. The architecture is organized into two separate blocks, the former for measurement and the latter for communication, and it presents original characteristics with respect to the state of the art. The accuracy of measured data is studied, paying attention to the fluid dynamic effects of the geometrical layout on the flow rate ultrasonic sensor and the environmental temperature and pressure for variable gas flow rate values. As for data security issues, the proposed solution is critically analyzed with reference to the data string organization and the procedure by which the data are stored and prepared for transmission into the blockchain. Finally, a local network of counters is designed and simulated in order to check the compliance of the provided hardware and software solutions with the predicted computational load.

1. Introduction

Integrity, transparency, and availability of data from gas flow meters are important requirements not only to avoid inaccurate billing and fraud, but also for more efficient energy consumption management. New smart metering technologies could respond to this need, offering automatic, real-time data gathering and transmission, if combined with IT techniques for data security [1]. Smart metering allows the formulation of bills based on actual use rather than estimates, which is a fundamental aspect with legal implications.

Furthermore, from a sustainability perspective, implementing smart metering in natural gas distribution presents a number of benefits for both distribution companies and customers, allowing for a more thoughtful use of natural gas, reducing operational costs due to remote reading, enabling the identification of abnormal consumptions or device malfunctions, and subsequently preventing unexpected breakouts and dangerous situations.

A smart meter must integrate the following components and functionality:

•

The measuring system, together with pressure and temperature transmitters to convert the gas volume to reference conditions. All measured variables are communicated to the Central Processing Unit (CPU) via a digital signal.

•

A Central Processing Unit (CPU) that processes, records, and prepares the data for transmission to the Central Data Acquisition System via a dedicated communication protocol.

•

A communication device required to transmit the measured parameters to the Central Data Acquisition System.

•

A remote-controlled valve, required to remotely shut off the gas supply in the event of anomalous data (possible leaks) in residential applications.

•

Power supply, since electronic components are used. For safety reasons, battery power should be used.

The reliability of the measurement information is a requirement that must be guaranteed at every point along the data path, especially when longer distances are covered, starting from the origin, where the sensor generates the raw data; this requirement involves the integration of many aspects and technologies [2].

In the first stage of the measuring process, monitoring interfering quantities and parameters representative of the continuity and regularity of operation can be a useful tool for ensuring quality and safety.

In particular, the automatic correction of influencing parameters for the intrinsic conversion of measurement results to reference temperature and pressure conditions is a significant opportunity from the point of view of measurement accuracy.

Of course, the metrological characterization of new metering devices is a necessary preliminary step to optimize the measuring setup and to account for the effect of thermal and fluid dynamic parameters on the measurement accuracy.

In general, traditional mechanical bulk meters, based on diaphragms, turbines, or rotating pistons, are not appropriate for supporting modern metering because they are challenging to integrate with other transducers, and high noise levels and substantial pressure losses often characterize them.

Digital, miniaturized and low-cost flow meters are now commercially available, useful for this application, which are mainly based on the thermal exchange principle due to the gas flow and ultrasonic measurement of the velocity profile.

Thermal gas meters are very diffused, even though some critical aspects should be considered, with reference to the calibration procedure [3] and to the effect of operating with gas mixtures, including hydrogen, which is actually a possible way of improving the performance of the transportation networks [4,5].

Ultrasonic meters [6,7] present the following main advantages:

•

The absence of moving parts that make this kind of device not subject to wear and tear, allowing it to operate in a wide variety of environmental conditions with minimal maintenance;

•

The compact size that makes them suitable for installation in confined spaces;

•

A direct electrical output that does not require special devices for remote readings, significantly reducing data collection times;

•

Good accuracy;

•

Capability to detect reverse flow;

•

Independence from the physical properties of the fluid (provided it is homogeneous), unlike thermal gas meters, being less significantly influenced by the gas composition [8,9,10].

Until now, the main obstacle to the widespread use of these meters has been their high cost, but they are becoming cost-competitive with other technologies.

The main characteristics of ultrasonic, thermal and diaphragm sensors (the most common bulk meters) are summarized in

Table 1. Main characteristics of ultrasonic, thermal and diaphragm meters.

Property	Diaphragm Meter [1,5]	Thermal Meter [1,4,5,8,9,10]	Ultrasonic Meter [1,3,5,6,7]
Accuracy	Medium	High	Very high
Pressure Loss	High (due to mechanical parts)	Very low	Very low
Durability	High (mechanical, long lifespan)	Medium (sensor drift over time)	High (no moving parts)
Size	Bulky (especially for high flow rates)	Compact	Compact
Dependence on Gas Composition	Low	Very high (based on thermal properties of the gas)	Low (if the gas is homogeneous)
Maintenance Requirements	Medium (moving parts require periodic checks)	Medium–high (sensor recalibration)	Low (no moving parts)
Response time	Slow	Fast	Very fast
Ease of conversion to smart meter	Low	High	Very high

.

Moreover, if the data transmission, billing and transparency of the relationships between gas distributors and customers are taken into account, many other considerations can be highlighted.

Recent developments in smart utility metering have significantly advanced remote monitoring, diagnostics and automated billing for gas infrastructure. In this context, smart gas meters incorporate electronic measurement modules, low-power wide-area network (LPWAN) communications and backend integration. As an example, Al-Sammak et al. built a smart meter prototype integrating both LoRaWAN and NB-IoT modules and applied an adaptive algorithm to reduce packet transmissions [11]. Their results claim packet reductions of up to ~76% (LoRaWAN) and ~86% (NB-IoT), and energy-spike reductions of ~88% and ~87 % respectively. Nevertheless, this result comes without a proper data management security structure based on IoT models, such as blockchains. Additionally, the choice of LoRaWAN over other LoRa protocols may lead, in specific situations, to limitations in large-scale deployments, involving collisions, interference, and duty-cycle constraints [12]. As a matter of fact, security in data management and the choice of the proper LoRa protocol remain open challenges for smart metering systems.

The actual model of the energy market is based on a strongly centralized structure, with the main operators having the duty of keeping the provision of energy resources stable, safe and balanced. The big energy producers generally do not directly supply energy to the network, this service being managed by network operators and energy brokers; this situation remarkably reduces the possibilities of direct negotiation. The local energy producers, despite being economically compensated in some way, cannot access a competitive peer-to-peer market. Furthermore, the whole data validation process, from the measurement phase to the billing phase, is based on actions whose traceability is guaranteed by the institutional organizations, which is a rather direct system.

The availability of technical tools allowing for distributed scenarios, like blockchain, promises many improvements with respect to the actual situation: validation of data is based on distributed and transparent ledgers without the need for a central office; the energy could be “transformed” into a digital token, a certified quantity of energy, which is transferable and verified.This way, involvement in a peer-to-peer market is made easier, allowing small operators to participate, like local energy communities. This aspect seems important not only from a social point of view, but also from a sustainability and economic one. In fact, every quantity of energy could be taken into account to avoid any energy losses; local balancing actions could be set, improving the managing performance of the network with respect to the load and overload conditions, accounting for transmission losses and related costs. These technical opportunities are also business opportunities, especially for small and local producers, promoting flexibility and autotuning capabilities in the energy market. Finally, the model could be extended to many sectors of energy, like power, gas and water.

Of course, the problem cannot be faced only from a technical point of view: implementing this peer-to-peer energy market requires significant modification of the existing laws, technical standards and rules, especially in Italy; nevertheless, studying the technical aspects connected to the suggested innovation could be useful for the whole debate.

Based on the above considerations, this paper introduces and develops a new smart gas meter based on an ultrasonic sensor, employing LoRa and/or NB-IoT protocols and blockchain technologies to overcome the data integrity and security issues with a completely modular design; a preliminary version has been described in [13]. The architecture is organized in two separate blocks, the former for measurement and the latter for communication, and it presents original characteristics with respect to the state of the art. In fact, the measurement block includes a sensor and hardware for data acquisition, and the communication block, which is interchangeable, keeps suitable measurement information in the measurement hardware; this strategy guarantees that no useful information is lost, independently of whether the communication module is installed. Therefore, this new strategy has the potential to contribute to the transformation of the gas-metering sector, offering a reliable and secure energy management solution.

Obviously, the use of blockchain to guarantee energy and gas meter networks’ data security is not a fully original idea and many applications have been proposed, considering different possible scenarios [14,15,16,17,18].

Most innovation is in the integration of hardware/software measurement and communication blocks and in the designed information infrastructure, which has to be carefully designed and tested, which is not a trivial task. In this project, the infrastructure will be designed and simulated by a suitable software package in order to optimize the layout and the working characteristics. The simulation process and the adopted solutions will be described in the following sections, with the aim of also highlighting the main driving rules the design is based on.

The paper is organized in the following way: Section 2 describes the methodology used to create an approach suitable to integrate validated measurement data and blockchain hints into the measurement and data transmission process. Section 3 will give some information about the preliminary layout and experimental results. Conclusions will end the paper.

2. Materials and Methods

This project aims to guarantee the accuracy and reliability of measured data used for billing, by both validating the measurement phase by means of checking the effect of environmental conditions (geometry of the installation, temperature, gas pressure) on the flow transducer and by keeping the data reliable by implementing blockchain procedures, in order to improve the process monitoring and reduce the probability of data being tampered with.

2.1. Flow Measurement Validation

For measurement validation by the ultrasonic flow meter, some actions were defined to check both the electronic and the environmental data. A reference circuit was designed and realized in order to check the correctness of data measured by the ultrasonic meter, in terms of the flow rate, pressure and temperature of the flowing gas; furthermore, a parallel track was available for the flowing gas to check that no significant pressure loss occurred in the flow meter installed in the meter casing due to the mechanical layout.

The scheme of the circuit is shown in Figure 1.

Thanks to a pressure regulator, a stable flow of air was achieved, attenuating the oscillations produced upstream by the compressor. Two reference flow meters (with an uncertainty of 2.5% f.s.) with different measuring ranges (4–50 L/min and 10–100 L/min) were inserted in series along the loop shown in Figure 1, and three different flow conditions were realized, 3.3 m³/h, 4.8 m³/h, 6.0 m³/h, all within the operating range of meters for domestic gas-dispatching pipes (0.04–6 m³/h) [19,20].

Two ultrasonic flow sensors were inserted into the circuit (ultrasonic gas-metering module, class 1.5, model Spiro-L-Horiz, by Panasensing, Chengdu City, Sichuan Province, China) [19,20]: one installed in-line, with appropriate connectors (Figure 2a), and the other inserted in a classic meter casing (Figure 2b).

Three MEMS Gauge Pressure Sensors (2SMPP by Omron, Kyoto, Japan ) (Figure 3a) were connected to the circuit, so as to be upstream and downstream of the two ultrasonic flow meters in positions “Pos1”, “Pos2” and “Pos3”, as indicated in Figure 1a.

The straight pipes connected to the ultrasonic meter inlets are more than 10 times the diameter of the pipes (30 mm), as indicated by the standard [19].

Additionally, a reference pressure gauge (Bourdon Tube, Pressure Gauge 9061568, by Wika, Klingenberg, Germany) was also connected in Pos1 for comparison and calibration purposes (Figure 3b). The pressure sensors were calibrated by comparison with the reference gauge, realizing different pressure conditions (0, 0.01, 0.02, 0.1, 0.2, 0.3, 0.4 and 0.5 bar) at the measuring point shown in Figure 3b. The uncertainty contribution of linearity was estimated as the maximum deviation of the measured values from the least squares regression line, assuming a rectangular probability distribution [21]. Furthermore, a repeatability test was carried out by means of ten repeated measurements, in order to evaluate the repeatability uncertainty of the results through the standard deviation. Finally, the contributions of repeatability, linearity and reference uncertainty were combined [21] to evaluate the calibration uncertainty.

Some tests were carried out to check the behavior of the ultrasonic flow sensor: in particular, five repeated measurements were performed for each flow condition, and the mean and standard deviation were calculated and compared with the values provided by the reference flow meters.

2.2. LoRa-NB IoT Structure

As mentioned, the smart gas-metering system employs LoRa and NB IoT technologies. The former allows a long and wide range for the gas-metering nodes to reach the local gateway, allowing the system to be installed in both urban and rural environments; additionally, the use of NB-IoT enables the compliance of this system with Industry 5.0, due to the use of NB-IoT in low-power wide-area networks (LPWANs), and allows the easy integration of this system with the Long-Term Evolution (LTE) ecosystem, an important factor for the internet connection of the device. The internal structure of the smart metering device communication part is reported in Figure 4.

Low cost, flexibility, and low-power operation motivated the choice of the nRF52 as a microcontroller unit (MCU) for this purpose, re-programmable through Universal Serial Bus (USB) by using a CP2102 UART-to-USB converter, Silicon Laboratories Inc., Austin, TX, USA, characterized by remarkable efficiency in serial communication. Furthermore, its serial communication through the UART protocol with the BG77 modem enables the implementation of the NB-IoT feature.

LoRa communication with local devices is empowered by the Semtech SX1272 LoRa transceiver, Camarillo, CA, USA, whose communication with the MCU is regulated by the Serial Peripheral Interface (SPI) protocol. Finally, the whole module has a specific power path for its supply; the communication part is supplied by a Lithium Polymer (LiPo) battery, whose voltage is both read by the microcontroller Analog–Digital Converter to assess the battery charge level and regulated by the RP104 voltage regulator that provides a constant 3.3 V supply voltage to the whole module.

This configuration uses known components and modules and, at the same time, integrates the LoRa-NB-IoT functionality. In particular, the combined use of the two technologies is justified by the need for flexibility depending on the specific smart gas meter being installed. In fact, NB-IoT is used to send data directly to the internet, while LoRa technology is either used when

•

NB-IoT coverage is limited, so data is sent through LoRa to the nearest covered point;

•

When many gas meters of this type are installed in a neighborhood.

In the latter situation, the closest smart gas meter is installed in a 50 m range; thus, data from each device is forwarded through LoRa to a local gateway for data gathering and transmission to the internet for its visualization and blockchain integration. Specifically, LoRaP2P was chosen as the protocol due to its packet customizability and, thus, its low-power feasibility. On the other hand, when the gas meter of interest is the only device installed in a neighborhood, and hence, there are no smart gas meters in a 50 m range, NB-IoT is used.

2.3. Data Security and Transparency

As for data security and transparency, a parallel action of the procedure is inserting blockchain rules and realizing the management of “energy tokens”, which are digital data that fully represent the energy transaction. Energy tokens will be recorded and managed by the blockchain for automation traceability, transparency and safety purposes. Furthermore, the design and integration of the measurement and transmission modules will be of major concern, with the maintenance and/or substitution of the latter being a possible reason for a data security warranty. The use of blockchain and the introduction of energy tokens are expected to create new market models able to realize direct and peer-to-peer interactions between suppliers and customers, overcoming centralized management logics.

2.3.1. The Proposed Infrastructure

A three-level model is proposed and designed to be optimized for use in devices with limited computational resources, in order to reduce costs and energy consumption.

This model provides three node typologies:

•

Authority nodes, responsible for system validation and supervision;

•

Aggregating nodes, for acquisition, processing and transmission of data originating from edge nodes;

•

Edge/gas meter nodes, corresponding to the in situ devices performing local measurements.

For the reliable functioning of the whole chain, specific and clear operating tasks are given to each node, differing depending on the operating level. Higher-level nodes are located with a suitable geographical distribution, also depending on the commercial needs and interactions.

The system implemented for experimental validation is based on a private and permissioned blockchain with the following characteristics:

•

Network Type: Private permissioned (Hyperledger Besu with Proof of Authority consensus algorithm);

•

Mechanism: Proof of Authority (PoA) with pre-authorized validators;

•

Network ID: 1337 (custom private network identifier);

•

Block Time: ~5 s in test configuration;

•

Block Gas Limit: 8,000,000 gas units;

•

Theoretical Capacity: ~4–5 batches per block (with optimal batches of 50 tx), equivalent to ~200–250 energy transactions per block.

A synthetic scheme of the infrastructure is depicted in Figure 5.

With reference to the edge/gas meter nodes, it is important to highlight that all these nodes are specifically configured to manage energy consumption, with different characteristics:

•

Only consumer: the domestic gas meters in basic configuration;

•

Only producer: for meters installed at production sites;

•

Prosumer: domestic sites with hybrid characteristics (local production and use of energy).

All these nodes allow bidirectional communication, although with a limited capability. Table 2 summarizes communication intervals and size of data exchanged between nodes.

Table 2. Representative table for node communications.

#	Communication Path	Interval/Frequency	Payload Size (Bytes)	Average Latency
1	Edge → Aggregator	Consumer (60 s)	775–835	50–150 ms
2	Aggregator → Authority	Batch interval (30 s)	30,750–41,750 (batch of 50 tx)	800–1200 ms
3	Authority ↔ Authority	Continuous during block cycle (~5 s)	2000–5000	<5 ms (LAN)
4	Authority → Aggregator	On block confirmation (~5 s)	256–512	10–50 ms
5	Aggregator → Edge	On tx confirmation (~6–37 s after submission)	180–250	50–150 ms

Table 2. Representative table for node communications.

#	Communication Path	Interval/Frequency	Payload Size (Bytes)	Average Latency
1	Edge → Aggregator	Consumer (60 s)	775–835	50–150 ms
2	Aggregator → Authority	Batch interval (30 s)	30,750–41,750 (batch of 50 tx)	800–1200 ms
3	Authority ↔ Authority	Continuous during block cycle (~5 s)	2000–5000	<5 ms (LAN)
4	Authority → Aggregator	On block confirmation (~5 s)	256–512	10–50 ms
5	Aggregator → Edge	On tx confirmation (~6–37 s after submission)	180–250	50–150 ms

2.3.2. Simulation of the Infrastructure

The virtual scenario simulating the infrastructure described in the previous section, constituted by many gas meters interconnected with a blockchain, is studied on a main server. In this scenario, a virtual machine operates as the authority of the system with validation and supervision capabilities. The creation and management of the infrastructure are operated by means of GNS3 (Graphical Network Simulator 3) with Docker containerization, a software package for machine, network and transmission protocol simulation.

The main server is able to operate with high computational load, with the following characteristics:

•

A 64 GB RAM capacity;

•

Two CPUs and 12 cores, with nested virtualization enabled;

•

Many Ethernet interfaces for configuration and simulation flexibility purposes.

By means of this server, all the necessary network devices can be simulated, like routers, firewall and switches, the geographical layout, the different nodes, and their different capabilities according to the operating level. Furthermore, the analysis and the balancing of the network can be carried out to evaluate the efficiency and resilience of the simulated network.

The topology includes dedicated switches for each layer (AuthoritySwitch, AggregatorSwitch, ConsumerEdgeSwitch) connected via a central ISPSwitch for inter-VLAN routing, simulating a realistic geographical distribution.

The following traffic generation parameters were configured for system validation:

• Transaction Generation Frequency:

  •

  Consumer node: 1 transaction every 60 s (average consumption 2–8 kWh);

  •

  Producer node: 1 transaction every 45 s (average production 5–15 kWh);

  •

  Prosumer node: 1 transaction every 90 s (production/consumption/transfer mix).

• MQTT Broker Load (Aggregator):

  •

  Concurrent Connections: Tested from 3 edge devices (PoC) up to 500 simultaneous connections in stress tests;

  •

  Message Throughput: 100–200 msg/s in stress test scenarios;

  •

  QoS Used: QoS 1 (at least once) to ensure reliable delivery of critical energy transactions;

  •

  Keep-alive: 60 s;

  •

  Average Payload Size: 775–835 bytes (JSON signed with Ed25519).

• Batch Configuration and Throughput:

  •

  Batch Interval: 30 s (configurable via BATCH_INTERVAL_SECONDS in the 10–120 s range);

  •

  Batch Size: Min 1 tx, max 50 tx (adaptive based on network load);

  •

  Theoretical Blockchain Throughput: ~240 transactions/minute with optimal batches (48 tx/batch × 5 blocks/min);

  •

  Observed Blockchain Throughput: ~100 transactions/minute in nominal test scenarios.

End-to-end latencies were measured during 2 h test sessions:

•

Edge → Aggregator (MQTT): 50–150 ms (dependent on simulated network latency);

•

Batch processing: 200–500 ms (a function of batch size and Merkle tree construction);

•

Smart contract execution: 800–1200 ms (dependent on gas used and batch complexity);

•

Block confirmation: ~5 s (PoA block time);

•

Total End-to-End Latency: 6–37 s (average 20 s).

The total latency varies significantly as a function of the transaction’s arrival time relative to the batching cycle: in the optimal case (transaction arrives at the start of the batch window), the total time is approximately 6 s; in the worst case (transaction arrives immediately after the previous batch was sent), the time is extended up to 37 s including the wait for the next cycle.

2.3.3. Data Management

Most of the network’s capability to operate successfully depends on the way the data are managed, particularly the data sequence of the communication string and the way the data are shared between the different blocks, in particular the measuring and transmission ones.

All data are transmitted as an alphanumeric sequence of fixed length. The payload is organized into four strings of fixed length, designed to represent a specific information category in a univocal way.

The list below summarizes the data of different packages, which were shaped in order to fulfill the requirements of transparency and reliability as much as possible when the system works:

•

Metering package (gas meter):

• Data concerning the measuring sensor;
• ID sensor (microcontroller);
• ID measurement device (and reference to the calibration);
• Serial number of metering device;
• Calibration data.

•

Data of the Meter:

• ID meter (serial number);
• Pool/set data for meter configuration;
• Timestamp.

•

Data of the Firmware Measurement block:

• Pool/set of progressive pre-charged serial numbers;
• Sensor status;
• Measurement value;
• Algorithm parameters concerning acknowledgement serial reception.

•

Energy data:

• ID production plant;
• Production certificate;
• Site of production;
• Energy source type (solar, hydroelectric, etc.);
• Energy measurement data;
• Measurement unit (kWh, m³, etc.).

Each string is composed of the following:

•

Preamble: a fixed value representing the beginning of the string, without an associate value;

•

Corp: the data to be sent in this string;

•

CRC: standard control for data integrity check;

•

Termination characters: characters indicating the end of the segment.

Table 3 describes the payload string structure.

Table 3. Representative table for the payload string structure.

Segment	Data Type	Identifier	Bytes
1—Data concerning the measuring sensor	Preamble	AA01	4
1—Data concerning the measuring sensor	ID Sensor	IDM01	10
…	…	…	…
1—Data concerning the measuring sensor	CRC	CRC	4
1—Data concerning the measuring sensor	Escape Sequence	\n\r	2
2—Data of the meter	Preamble	AA02	4
2—Data of the meter	ID Meter	IDM02	10
…	…	…	…
2—Data of the meter	Escape Sequence	\n\r	2
3—Data of the firmware measurement block	Preamble	AA03	4
…	…	…	…
3—Data of the firmware measurement block	Escape Sequence	\n\r	2
4—Energy data	Preamble	AA04	4
…	…	…	…
4—Energy data	Escape Sequence	\n\r	2
//END	//END	//END	//END

Table 3. Representative table for the payload string structure.

Segment	Data Type	Identifier	Bytes
1—Data concerning the measuring sensor	Preamble	AA01	4
1—Data concerning the measuring sensor	ID Sensor	IDM01	10
…	…	…	…
1—Data concerning the measuring sensor	CRC	CRC	4
1—Data concerning the measuring sensor	Escape Sequence	\n\r	2
2—Data of the meter	Preamble	AA02	4
2—Data of the meter	ID Meter	IDM02	10
…	…	…	…
2—Data of the meter	Escape Sequence	\n\r	2
3—Data of the firmware measurement block	Preamble	AA03	4
…	…	…	…
3—Data of the firmware measurement block	Escape Sequence	\n\r	2
4—Energy data	Preamble	AA04	4
…	…	…	…
4—Energy data	Escape Sequence	\n\r	2
//END	//END	//END	//END

It should be noted that it is a suitable choice to make a perfect correspondence between 1 token and 1 energy unit, i.e., 1 token means 1 kWh or 1 m³.

Due to the higher computation capability of the transmission device, the token file will be managed at the transmission stage; even though the measuring microcontroller should operate at a light computational load, it should be able to manage some relevant data, like the raw measurements and the corresponding environmental ones, to allow for possible data reconstruction and processing in the case that processed data become unavailable for unpredicted events.

2.3.4. Blockchain System Authentication

To guarantee high protection of the system against potential unauthorized intrusions or accesses, it is mandatory to introduce a structured authentication procedure to access the blockchain network. To this aim, a Certification Authority is defined, with the specific duty of validating and certifying the companies, producing the sensors and measuring systems suitable for the proposed infrastructure, and being available to make their devices compatible with the blockchain validation process.

The accreditation process is based on different phases:

•

The company, which is a sensor producer, asks to be qualified, based on an audit of the Certification Authority.

•

After qualification, the company obtains a set of cryptographic keys and proprietary algorithms (for each sensor and/or measurement system) to generate a pool of serial codes to be pre-charged into the firmware.

•

The generation algorithm will block the serial codes during the installation phase into the firmware; they will be needed for authentication of each measurement datum to be transmitted. In fact, their function is to univocally individuate the authorized single device. Furthermore, these codes will be used to preserve the sequence of transactions; this way, each transaction could be recovered in the case of transmission problems.

•

Network validation during each communication: The message payload also includes one pre-charged code to be validated by challenge–response techniques and cryptographic ones based on public/private keys; only after this step will the blockchain consider this communication authenticated.

Once the accreditation process is performed, a certificate is issued and its renewal is carried out annually, always managed by the Certification Authority. This process involves periodic verification of the manufacturing company’s compliance with technical and security requirements, as well as checking the integrity and authenticity of registered devices. When the outcome of the verification process is positive, then the Certification Authority proceeds to the certificate renewal by issuing a new set of cryptographic keys and, if necessary, updating the serial codes generation algorithms.

This mechanism ensures system operational continuity and reduces the risk of long-term compromise of authentication keys.

At the same time, the Certification Authority carries out constant monitoring of active certifications, verifying any anomalies, expirations, or cases of non-compliance that could compromise system security.

When these conditions occur, the certification revocation procedure is activated so the public keys associated with the devices are invalidated and removed from the blockchain’s ledger of trust.

As a result, even if the device retains the ability to correctly generate serial numbers using the algorithm unlocked in the firmware, these are no longer valid.

The blockchain automatically rejects any authentication attempts coming from devices with revoked keys, preventing the validation of transactions.

2.3.5. Communication Protocol

According to the above-mentioned requirements of reliability and security in the management of data with reference to the whole network, the communication protocol was set according to the following:

•

Communication between nodes:

• Authority ↔ Data logger: MQTT with dedicated topics for sending batch and reception block confirmation;
• Data logger ↔ Data logger: MQTT with publish–subscribe function for synchronization of the local status;
• Authority ↔ Authority: MQTT with private topic for consensus communications.

•

Communication between Gas meter and Server:

• Protocol: MQTT over TLS to improve the energy efficiency at the edge devices;
• Topic Structure: Different topics between transactions and heartbeats;
• Local buffer: Transaction queue in the case of temporary disconnection with automatic retry.

•

Communication between Distributor and Server:

• Protocol: MQTT for architectural compliance;
• Batch Processing: Topic for sending aggregate;
• Real-time Alerts: MQTT retains messages for immediate notification of critical events.

All the MQTT communications use TLS 1.3, authentication by a certificate client, and topic ACL for granular control of access (cross-security).

3. Results

This section presents some preliminary results with reference to both the metering and communication sectors.

3.1. Metering Validation

Some tests were carried out with the following purposes:

•

For the fluid dynamic aspects, validation of the pressure behavior throughout the gas loop, upstream and downstream of the meter;

•

For the gas metering, validation of the flow rate, cumulative volume, and environmental quantity measurements (temperature, pressure).

Preliminary tests were carried out at different flow pressures, in the range of the admitted pressure for domestic gas-dispatching pipes. The loop shown in Figure 1 was used for testing.

First, the pressure sensors were calibrated by comparison with the reference pressure gauge, and the calibration curve (Figure 6) was obtained that allowed the voltage output to be converted into pressure measurements. A calibration uncertainty of 0.005 bar was also evaluated.

Therefore, tests were carried out at constant flow rates of 3.3 m³/h, 4.8 m³/h, and 6.0 m³/h, as described in Section 2.1, in two different environmental conditions:

•

Condition (a): atmospheric pressure: 884 mbar; temperature: 27.0 °C.

•

Condition (b): atmospheric pressure: 889 mbar; temperature: 25.5 °C.

In all the described test conditions, the relative pressure at positions Pos1, Pos2, and Pos3 was measured and is plotted in Figure 7a,b. In both atmospheric conditions, it can be noticed that the ultrasonic meter, either connected inside the casing (see pressure variation between Pos1 and Pos2) or in-line (see pressure variation between Pos2 and Pos3), does not introduce significant pressure drops at lower flows. At the highest flow rate, instead, the pressure drop evidently becomes more significant in correspondence with the sensor in the casing, where the 2.0 mbar limit prescribed by the standard [19] is exceeded. The pressure drop is due to both the fluid dynamic path and an imperfect seal of the system, so this aspect will be paid particular attention in the final version, improving sealing solutions. Leak tests will be carried out according to the standard’s specifications [19]. Furthermore, for a more accurate evaluation of pressure drops, the estimation of the calibration uncertainty of the pressure sensors will be refined.

As stated in Section 2.1, five repeated flow measurements were performed for each flow condition, and the mean and standard deviation were calculated and compared with the values provided by the reference flow meters. The results show that the variability was in the order of 2%, and the maximum relative error of the mean with respect to the indication of the reference flow measuring device operating in series along the loop of Figure 1 was in the range of 4 to 5%. It should be pointed out that once both the measuring and transmission blocks and the blockchain infrastructure are fine-tuned and validated, a high-accuracy gas flow rate measurement device will be introduced for final gas meter calibration and complete evaluation of the uncertainty contributions.

3.2. Communication and Blockchain Architecture

A general information flow has been hypothesized, according to the steps described in

Table 4. Bidirectional energy token market.

Step N#	Action	Description
Step 1	Token generation	All authorized actors (distributor, prosumer, domestic user) assess energy production and require token creation
Step 2	Validation and registration	A consensus is issued following validation by the network, registering the relevant tokens in the ledger
Step 3	Trading/allocation	Tokens are exchanged between actors or allocated for direct consumption
Step 4	Consumption and extinction	The final users “fire” tokens after their use

. It should be pointed out that a generic token could be managed for power, water and gas. Some examples show how the market, the distributed validation, and transactions/token flows are implemented.

3.2.1. The Energy Market

Four steps, reported in Table 4, are implemented to realize a bidirectional energy token market:

The system operates like an Automated Market Maker (AMM) for energy:

•

Cash flow and liquidity pool: All the available energy tokens are recorded in the ledger;

•

Deposit: All the producers deposit energy tokens;

•

Withdrawals: All the consumers withdraw tokens according to the energy use;

•

Arbitration: The distributor acquires tokens from a prosumer, selling them to a final consumer;

•

Immediate settlement: All transactions are irreversible and immediately recorded.

Some examples are shown in

Table 5. Scenario 1—main distributor.

N#	Role	Action
1	Domestic producer “DP” (with some solar panels)	Deposits 100 tokens
2	Distributor	Buys 100 from “DP”
3	A group of consumers	Buys 80 tokens from distributor as a unique consumer
4	Distributor	Keeps 20 tokens in the ledger

and

Table 6. Scenario 2—domestic prosumer.

N#	Role	Action
1	Distributor (photovoltaic plant)	Deposits 10,000 tokens
2	Industrial user	Buys 3000 tokens from the distributor
3	Domestic customer	Buys 5000 tokens from distributor
4	Distributor	Keeps 2000 tokens in the ledger

:

3.2.2. The Mechanism of Distributed Validation

An algorithm of consensus was set as a Proof of Authority, according to the following parameters:

•

Authority minimum number: three nodes (to avoid single failure points);

•

Consensus threshold: $\raisebox{1ex}{$2$}\!\left/ \!\raisebox{-1ex}{$3$}\right.$ + 0.01 (almost 67% of the authorities approve);

•

Blockage time: 30 s (trade-off between reaction time and stability).

The set threshold is able to keep the system working in cases of trouble or attacks, even in cases of failure of one node in a total of three nodes, or of two nodes in a total of five nodes.

The validation process is shown in

Table 7. Example of the validation process.

N#	Role	Action
1	Edge Node	Sends transaction to an aggregator
2	Aggregator	Pre-validates and aggregates in batch
3	Aggregator	Sends batch to 3 + nodes and authority
4	Authority 1/5	Independently validates the batch given its outcome
5	Authority 2/5	Independently validates the batch given its outcome
6	Authority 4/5	Independently validates the batch given its outcome
7	Authority	If 67%+ of the authority outcomes are positive, the batch is created and shared
8	All nodes	Update their local site

:

Some practical safety mechanisms are created, in particular the following:

•

Anti-Double Spending:

• Univocal cryptographic UUID for each token;
• A distributed database tracks the status of each token (created/consumed/transferred);
• Atomic lock during concurrent transactions.

•

Validation of Production

• Digital certification of the production plant;
• Compliance with the allowed ranges;
• Optional integration of other monitoring systems.

3.2.3. Transactions and Token Flow

The main supported transactions are

•

Token creation;

•

Token consumption (final consumer/prosumer);

•

Token transfer (between actors).

An example of the execution programs was prepared according to requirements of simplicity and computational load reduction. The list of programs accomplishing these tasks is given in Appendix A.

3.2.4. Token Life Cycle

As an example, the graphs in Figure 8 show a practical life cycle of tokens, depending on the actors involved. They highlight the role of the final consumer, which is fully engaged.

The blockchain infrastructure implemented for the purpose of experimental validation is based on an EnergyBatchRegistry.sol smart contract (283 lines of Solidity code), deployed on Hyperledger Besu 24.12.0 with Proof of Authority consensus.

The contract manages the registration of energy transaction batches through two main data structures: Batch and EnergyTransaction.

The complete life cycle of an energy token involves several phases with specific latencies measured during system validation tests:

• Edge Layer (GasMeter Node → Aggregator): Edge nodes generate transactions signed with Ed25519 (average payload 775–835 bytes) and transmit them via MQTT to the aggregator node. Average latency measured in the GNS3 test environment: 50–150 ms on a simulated local network.
• Aggregation Layer (Batch Processing): The aggregator collects transactions into batches with a configurable interval via the BATCH_INTERVAL_SECONDS environment variable (set to 30 s in the tests). The service constructs the Merkle root and validates the data structure. The average batch processing time is 200–500 ms for sizes varying from 5 to 50 transactions (MIN_BATCH_SIZE and MAX_BATCH_SIZE).
• Blockchain Layer (Smart Contract Execution): The smart contract’s submitBatch () function executes the following atomic operations:
  • Batch parameter validation (presence of at least one transaction, correctness of arrays);
  • Registration of the batch in the blockchain with block.timestamp;
  • Iteration over all transactions in the batch with an anti-duplication check via mapping;
  • On-chain storage of cryptographic hashes and transaction metadata;
  • Emission of BatchSubmitted and TransactionRecorded events for traceability.

During validation tests with experimental deployment, the gas consumption for the invocation of the submitBatch () function was measured: for a batch containing a single transaction, the gas consumed was approximately 1,646,143 gas units (20.6% of the block gas limit of 8,000,000 gas units).

The batch architecture was designed to optimize gas efficiency: with batches containing the maximum number of transactions (50 tx), the initial fixed cost is amortized, reducing the average cost per transaction to approximately 80,000–100,000 gas units per single energy transaction. The blockchain block time in PoA configuration is about 5 s, ensuring rapid transaction finality.

3.2.5. Management of the Distributed Ledger

The basic idea is that the tokens exist only in the distributed ledger. Furthermore, the system manages the ownership and status of each token by means of signed transactions using cryptography. Three token statuses are allowed:

•

Created: Token generated and available for use;

•

Transferred: Token transferred between actors (it is available);

•

Consumed: Token used to assess consumption (final status).

A preliminary simulation of the blockchain system was realized with the infrastructure shown in Figure 9, representing nodes of all the requested typologies, by means of virtual machines.

The tests carried out confirm that this infrastructure allows for good connection and communication between the edge node and the aggregator one, and for fully operating and bidirectional communication between the aggregator node and the authority one. Preliminary checks show that a few thousand edge nodes could be served by this infrastructure without requiring special computation resources.

4. Discussion

This research focused on three main objectives: designing a modular architecture for measurement devices, developing communication protocols optimized for heterogeneous environments, and defining distributed security models capable of ensuring measurement certification and traceability.

The goal of creating a modular architecture led to the analysis of solutions aimed at making gas meters interoperable with different types of networks, so it was not necessary to implement dedicated gateways for each communication technology.

The MQTT protocol was identified as the most suitable solution for efficient and reliable communications management, to ensure system scalability and promote integration between different manufacturers.

The need for an advanced security model compared to traditional schemes oriented the study towards using blockchain technology, evaluating its integration with protection mechanisms at the hardware and firmware levels. The targeted localization of problems allowed the system’s critical points to be identified, proposing scalable and replicable solutions in different industrial contexts.

The need for flexibility in data transmission justified the combined use of LoRa and NB-IoT technologies. Additionally, the hardware was chosen to minimize power consumption. As a matter of fact, the choice of a Nordic-based chip enables the classification of several instances of the proposed device as low-power wide-area networks (LPWANs).

Of course, regulatory considerations are also a concern, but the system is versatile and scalable. Therefore, once the potential application areas are understood, solutions can be specifically analyzed and optimized to tailor the implementation to the gas volumes handled, the areas covered, and all engineering, geographic, and commercial requirements.

5. Conclusions

In this paper, the design and preliminary validation of a smart gas meter are presented with the purpose of realizing a meter guaranteeing accuracy and security of data throughout the whole information transmission chain from measurement to billing. Accuracy issues have been faced in laboratory tests concerning the fluid dynamic behavior of the flow sensor in the gas meter and studying the eventual pressure losses introduced by the geometrical layout and environmental conditions. Preliminary tests demonstrated that the proposed geometrical layout allows for the possibility of easy data normalization with a simple set of sensors. Data security aspects have been analyzed by employing LoRa and/or NB-IoT protocols and blockchain technologies with a completely modular design; the architecture is divided into two separate blocks: the former for measurement and the latter for communication. Digital data management allows us to share data between the two blocks in order to preserve the necessary information in the measuring block even if the communication block is changed. The electronic solution provided for measurement and transmission blocks is designed for low energy consumption, allowing a long battery lifetime. Communication of energy consumption between network actors is managed on the basis of tokens traded in a blockchain network. Simulation software analysis shows that a network of up to a few thousand end users could be managed with an allowable computational load.

Of course, this paper is mainly devoted to discussing potential technical hardware/software solutions for accurate and secure energy consumption data management, creating a distributed infrastructure; implementing this peer-to-peer and distributed energy market requires significant modification of the existing laws, technical standards and rules, and this aspect is valid especially in Italy. Nevertheless, studying the technical aspects connected to the suggested innovation could be useful for the whole debate.