Smart Water Security with AI and Blockchain-Enhanced Digital Twins

Andres Caro; Mohammadhossein Homaei; Oscar Mogollon Gutierrez; Ruben Molano Gomez; Victor Gonzalez Morales

REVIEW 5 major objections 5 minor 18 references

Smart Water Security with AI and Blockchain-Enhanced Digital Twins

T0 review · 5 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper claims that a LoRaWAN, AI-filtered, Proof-of-Authority blockchain pipeline can log validated water-meter data at more than 80 transactions per second for up to 1,000 smart meters, making a rural water network tamper-resistant…

desk verdict A genuine rural-water security integration paper whose architecture is worth a serious look, but whose headline 'under 2 seconds' latency claim is contradicted by its own Table II and finality definition. read the letter →

arxiv 2504.20275 v1 pith:5ILT6L6P submitted 2025-04-28 cs.CR cs.AIcs.LG

Mohammadhossein Homaei , Victor Gonzalez Morales , Oscar Mogollon Gutierrez , Ruben Molano Gomez , Andres Caro This is my paper · ORCID

classification cs.CRcs.AIcs.LG

keywords digitaltwinsblockchainintrusiondetectionsystemLoRaWANsmartwatermetersProofofAuthorityLSTMautoencoderIsolationForest

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Rural water utilities cannot assume their meter data are trustworthy, and they often lack the staff and connectivity to run a conventional security stack. The paper tries to establish that a three-layer pipeline can close that gap: LoRaWAN meters (long-range, low-power wireless) send readings to a hybrid intrusion detection system, an LSTM autoencoder plus Isolation Forest filters out spoofed, replayed, or physically impossible values, and a private Proof-of-Authority Ethereum smart contract writes only the surviving records to an immutable ledger that feeds a digital twin for leak detection, forecasting, and maintenance. If the pipeline works as reported, a municipality could buy tamper-evident water accounting for a few hundred euros a month and get near-real-time alerts from the digital twin. The paper reports measurements of throughput above 80 transactions per second, mean transaction latency of roughly 1.2 to 2.1 seconds depending on batch size, block finality in 2–3 seconds, and rejection of the tampering attempts it staged.

What carries the argument

The load-bearing mechanism is the pre-validation filter placed between the LoRaWAN gateway and the ledger. It pairs an LSTM autoencoder, which learns to reconstruct sequences of normal meter behavior and flags any sequence whose reconstruction error exceeds a threshold, with an Isolation Forest, which scores whether a single reading is easily separated from the data cloud. A record must pass both checks before the smart contract's logging function can store it; the contract separately enforces meter registration and role-based access control, so unregistered or incorrectly signed submissions are discarded before any state change. This ordering—cheap rules, then learned filters, then consensus—is what lets the authors claim both attack resistance and speed.

What would settle it

Deploy the stack in a field test with real LoRaWAN hardware, then attack it twice: physically replay or spoof a meter reading and try to log it, and compromise one of the three validator nodes to attempt a history rewrite. If any unvalidated reading reaches the ledger, or if other validators accept the rewritten chain, the central claim is false; measuring full end-to-end latency—read, filter, batch, include, finalize—at 1,000 meters would also test the abstract's timing claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that data authenticity can be enforced at the point of ingestion rather than assumed afterwards. Every meter reading traverses a two-model filter before it reaches the blockchain, and the ledger itself is a small Proof-of-Authority Ethereum network whose smart contract registers meters, checks error codes, computes payments, and emits water-data events for the digital twin. In the authors' experiments this integrated design sustained more than 80 transactions per second while batching readings, kept mean transaction latency between 1.2 and 2.1 seconds with block finality in 2–3 seconds, scaled from 100 to 1,000 simulated meters without throughput dropping below roughly 85 TPS, and rejected direct database edits, unauthorized contract calls, and rogue validators. The stated upshot is a practical, low-cost architecture for continuous monitoring and tamper-resistant record keeping in under-connected rural settings.

Load-bearing premise

The load-bearing premise is that a single-server deployment with three validator nodes running in containers and synthetic attacks injected into historical data faithfully represents a real rural water network under genuine attack, so the measured speed and the measured security would both survive field conditions.

Editorial extensions

If this is right

A rural water operator could run the whole ledger on one server for an estimated €20–€50 per month with near-zero per-transaction fees, which removes the cost barrier that public blockchain solutions face.
The night-time leakage rule plus the AI filter can turn raw meter streams into automatic leak alerts and maintenance triggers, because only readings that pass both the rule and the anomaly models are logged.
The measured throughput headroom matters: even at 1,000 meters and 20 readings per transaction the network stayed near or above 80 TPS, so the design can absorb bursty uploads after connectivity outages.
Immutability is enforced at the consensus level, so once a valid reading is logged, attempts to edit the on-disk ledger, call privileged contract functions, or add a rogue validator are rejected rather than detected after the fact.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper's tamper-resistance tests do not cover a compromised validator; in a three-validator Proof-of-Authority network, a captured validator could block transactions or stall finality, so the security guarantee is conditional on validator trust.
The IDS was scored on synthetic attacks injected into historical consumption data; a live deployment against real radio-captured spoofing or replay traffic would be a stronger check, and the reported precision and recall may not transfer if real attacks have different temporal structure.
Because the design separates the learned filter from the ledger, the same ingestion filter could be retrained for gas, electricity, or district heating smart meters without changing the smart contract, which is a concrete extension the paper leaves implicit.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The paper is a legitimate systems-integration effort: it combines LoRaWAN acquisition, an LSTM autoencoder plus Isolation Forest IDS, a private Proof-of-Authority Ethereum blockchain, and a digital twin for rural water systems. I don't see that exact combination in the prior work they cite, and the pipeline is described clearly enough to be reproduced. The tamper-resistance tests (on-disk modification, unauthorized contract calls, rogue validator injection) are relevant and the cost analysis for a small pilot is practical. Credit where due: the IDS is tested against independently labeled synthetic attacks, which gives the security claim at least some grounding, and the scalability story across 100–1,000 meters is plausible.

The soft spots are real but mostly fixable. The biggest is the abstract's claim of "over 80 TPS with under 2 seconds of latency." Table II shows that at the batch size where TPS exceeds 80 (81 TPS at 20 readings/tx), mean latency is 2.1 s and max is 3.5 s. Section IV-D then defines mean latency as time to first block inclusion and adds 2–3 s of finality. So even the best batch-1 case gives end-to-end latency around 3.2–4.1 s. The "under 2 seconds" figure only describes first inclusion, not confirmed finality. That is an internal inconsistency in the paper's central quantitative claim, not a quibble about the test environment.

Other issues are milder. The IDS evaluation has no baselines, no train/test split details, no threshold selection procedure, and no error bars; the reported precision/recall is single-run and could be optimistic. The leakage-detection evaluation is partly circular: Algorithm 1 flags leaks based on non-zero nighttime consumption, and then Section IV-A presents nighttime consumption as evidence the detector works. The single Hetzner server hosting all three PoA validators means the security and decentralization claims are weaker than a multi-owner deployment would imply, though this is stated rather than hidden. No code or data is released, which limits reproducibility.

The architecture itself does not collapse. The contradiction in the latency claim can be corrected by rewriting the abstract and clearly separating first-inclusion latency from finality. The IDS evaluation can be strengthened with proper protocol. This is an engineering contribution, not a breakthrough, but it is coherent and useful for utilities looking at rural deployments.

My recommendation: send it to peer review. A serious referee can get the authors to fix the latency framing and tighten the evaluation. It is not desk-reject material — the integration is real and the domain is underserved. I'd bring it to a reading group, but only after the latency claim is corrected.

Referee Report

5 major / 5 minor

Summary. The paper proposes an integrated architecture for rural smart-water management that combines LoRaWAN-based data acquisition, a hybrid anomaly detector (LSTM autoencoder plus Isolation Forest), a private Ethereum blockchain with Proof-of-Authority consensus, and a digital-twin layer for leak detection, forecasting, and maintenance. The evaluation reports leakage-detection results on historical meter data, IDS precision/recall on synthetically injected attacks, blockchain throughput and latency under different batching strategies, tamper-resistance tests, and a cost estimate. The central claim is that the system exceeds 80 transactions per second with under 2 seconds of latency while scaling to 1,000 smart meters.

Significance. If the performance and security claims held as stated, the paper would make a useful contribution by demonstrating a plausible end-to-end pipeline that places AI-based pre-validation before blockchain logging in a rural water context. The manuscript is transparent about the deployment configuration, includes concrete tamper-resistance tests, and provides a cost breakdown, which is helpful for practitioners. The main weakness is that the headline latency figure is contradicted by the paper's own data and definitions, and the IDS and leakage evaluations are not yet specified tightly enough to support the reported quantitative claims.

major comments (5)

[Abstract and §IV-D, Table II] The abstract's claim of 'under 2 seconds of latency' is not supported by the paper's own evaluation. Table II reports a mean latency of 2.1 s and a maximum latency of 3.5 s at batch size 20, and §IV-D states that this latency is only the time to first block inclusion, with finality requiring an additional 2–3 seconds. Thus the end-to-end confirmation latency is at least 3.7–4.1 s even at batch size 10, and the 'under 2 seconds' claim holds only for a narrower metric that is not the one defined earlier in the same section. This is load-bearing because throughput/latency is the paper's principal quantitative contribution. Please either report finality-inclusive latency or revise the claim to state the metric precisely.
[§IV-B, Table I] The IDS evaluation lacks essential experimental detail: no train/test split is described, the thresholds τ and θ are not specified, the LSTM sequence window N is not given, and no error bars or baseline comparisons (e.g., LSTM-only or Isolation-Forest-only) are reported. Without these details the precision, recall, and F1 values in Table I cannot be reproduced or compared with prior work. Please specify the data split, how thresholds were selected, the window size, and the variability across runs or folds.
[§IV-A and Algorithm 1] The leakage-detection evaluation is circular. Algorithm 1 flags a leak whenever nighttime consumption is non-zero for two or more consecutive days, and §IV-A then presents nighttime consumption as evidence that the flagged meters are leaking. This does not validate the detection logic; it only re-describes the rule. Please provide independent ground-truth labels (e.g., confirmed leak reports) or an explicit baseline comparison, and state the false-positive rate on meters known to be leak-free.
[§IV-C and §IV-E] The security evaluation does not exercise a realistic adversary. All three PoA validator nodes run in Docker containers on one Hetzner server, so the tamper-resistance tests show only that a node cannot silently alter its own ledger copy or call administrative functions without credentials. They do not test what happens when an attacker compromises a validator, partitions the network, or sends replayed traffic that does not match the synthetic injection patterns. Please state these as explicit assumptions or add adversarial scenarios that involve a compromised validator or a network partition.
[§IV-D] The scalability claim for 1,000 meters is not backed by reported data. The text says the system was tested from 100 to 1,000 simulated meters, but no table or figure shows throughput or latency at intermediate or maximum meter counts, and the claim that the network 'maintained a throughput greater than 85 TPS' is not accompanied by latency figures. Please add the measurement results or soften the claim to match what is actually reported.

minor comments (5)

[§II-B] Reference [12] is cited as 'Kim et al. [ ?]' with a placeholder; please fix the citation.
[§IV-D] The bullet defining transaction latency as 'the time interval between the client submitting the transaction and its final confirmation on-chain' conflicts with the later sentence that the reported mean latency is only to first block inclusion and that finality requires 1–2 additional blocks. Please align these definitions and add a note about which metric is used in the abstract.
[Algorithm 3] The pseudo-code contains typos and formatting issues, including 'mapping(string =¿ WaterData[])' and 'function CALCULATE PAYMENT (uint256 u, e)' where the type of e is missing. Please clean up the algorithm listing.
[§IV-C] The description says meter data is batched and submitted in 8-hour intervals, while the throughput tests report transactions per second. Please clarify whether the reported TPS reflects sustained continuous load or bursty uploads after connectivity windows.
[§IV-F] The cost tables use non-ASCII dashes and inconsistent formatting (e.g., 'C20' and 'C50'). Please standardize to EUR or the intended currency symbol.

Circularity Check

1 steps flagged · score 4.0 of 10

Leakage-detection validation is circular (Algorithm 1's night-flow rule is confirmed by night-flow heatmaps); central TPS/IDS results are not circular.

self definitional [Algorithm 1 (Section III-A) and Section IV-A]
"Check nighttime (00:00–06:00) consumption / Update leakage counter: increment if all > 0, else reset / if counter≥ 2 then / Flag leakage; freeze status. The detection algorithm flagged meters with non-zero night consumption over consecutive days, suggesting probable leaks. Figure 4 shows a heatmap of night-time water consumption (00:00–06:00) for a leaking meter, where consistent activity was detected."

The algorithm's leak flag is defined by non-zero consumption during nighttime hours on consecutive readings; the evaluation confirms the detector by showing that the flagged meter has nighttime consumption and by aggregating nighttime usage across flagged meters. These plots are generated from the same criterion encoded in Algorithm 1, so they provide no independent evidence of leak-detection accuracy. No external ground truth (e.g., physical leak inspection, pressure data, or labeled leak intervals) is used. The claimed verification therefore reduces to a tautology: the rule is judged to work because it reproduces its own definition.

full rationale

The main circularity is confined to the leakage-detection evaluation in Section IV-A. Algorithm 1 defines a leak as consecutive non-zero readings during 00:00–06:00, and the evaluation's evidence is exactly that flagged meters have nighttime consumption; this is a self-definitional confirmation, not an independent test. The blockchain and IDS evaluations are not circular: TPS/latency are measured from a private PoA deployment, and the IDS precision/recall is scored against synthetic attacks injected into real consumption data with independent labels. The abstract's 'under 2 seconds of latency' claim is internally inconsistent with Table II and the finality note (finality adds 2–3 seconds), but this is a correctness and reporting-consistency problem rather than a circularity. The self-citations to [4] and [11] supply architectural context and prior DT layers, but the present experimental measurements are self-contained, so no load-bearing self-citation circularity is established. Overall, one component's validation reduces by construction, while the central performance and security claims retain independent content; hence a score of 4 is appropriate.

Assumptions & free parameters 5 free parameters · 4 assumptions · 0 invented entities

The central framework rests on standard machine-learning and blockchain primitives plus several unverified domain assumptions: historical data is a valid proxy for normal behavior, synthetic attacks approximate real threats, a three-node colocated PoA network is a meaningful security boundary, and emulated meters reproduce rural connectivity. Free parameters include the LSTM and Isolation Forest thresholds, the leakage rule parameters, and the blockchain configuration; most are unreported, which limits reproduction. No new physical entities are introduced.

free parameters (5)

LSTM reconstruction threshold tau = not reported
Section III-B3 defines tau as a predefined threshold for flagging sequences as anomalous; the value is not reported and is determined from training behavior.
Isolation Forest anomaly threshold theta = not reported
Section III-B4 states theta is 'determined during training'; no value or tuning procedure is given.
Leakage counter threshold and night window = counter >= 2; 00:00-06:00
Algorithm 1 fixes these hand-chosen values, and the evaluation in Section IV-A confirms leaks using the same nighttime-consumption criterion.
Block interval and gas limit = 1 s block interval; 15M gas limit
Section IV-C states these non-default Ethereum settings are chosen to enable higher throughput and faster finality; the reported TPS depends on them.
LSTM sequence window size N = not reported
Section III-B2 maintains a per-meter buffer X_m of size N for the LSTM; N is a hyperparameter that affects detection, but no value is specified.

assumptions (4)

domain assumption Historical water consumption data is representative of normal behavior and sufficient to train the LSTM autoencoder and Isolation Forest.
Section III-B assumes the models learn normal behavior from historical data; no real adversarial or out-of-distribution data is used in training.
ad hoc to paper Synthetic injections of replay, spoofed consumption, tampered error codes, and gas-usage anomalies approximate real attacks.
Section IV-B evaluates the IDS only on synthetic attacks injected into historical data; transferability to real attacks is assumed without evidence.
domain assumption A private PoA blockchain with three validator nodes on one server provides meaningful tamper resistance and availability.
Section IV-C deploys three colocated validators in Docker; the security model trusts authorities and does not consider colluding validators.
ad hoc to paper Emulated LoRaWAN meters and a replicated gateway on the same infrastructure reproduce rural connectivity behavior.
Section IV-C emulates 400 meters and simulates intermittent connectivity; no field deployment data is presented.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Smart Water Security with AI and Blockchain-Enhanced Digital Twins." pith.science (2026). https://pith.science/paper/5ILT6L6P

@misc{pith2026250420275,
  author       = {Pith},
  title        = {Pith review of: Smart Water Security with AI and Blockchain-Enhanced Digital Twins},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5ILT6L6P}},
  note         = {Machine review of arXiv:2504.20275}
}

read the original abstract

Water distribution systems in rural areas face serious challenges such as a lack of real-time monitoring, vulnerability to cyberattacks, and unreliable data handling. This paper presents an integrated framework that combines LoRaWAN-based data acquisition, a machine learning-driven Intrusion Detection System (IDS), and a blockchain-enabled Digital Twin (BC-DT) platform for secure and transparent water management. The IDS filters anomalous or spoofed data using a Long Short-Term Memory (LSTM) Autoencoder and Isolation Forest before validated data is logged via smart contracts on a private Ethereum blockchain using Proof of Authority (PoA) consensus. The verified data feeds into a real-time DT model supporting leak detection, consumption forecasting, and predictive maintenance. Experimental results demonstrate that the system achieves over 80 transactions per second (TPS) with under 2 seconds of latency while remaining cost-effective and scalable for up to 1,000 smart meters. This work demonstrates a practical and secure architecture for decentralized water infrastructure in under-connected rural environments.

Figures

Figures reproduced from arXiv: 2504.20275 by the authors.

**Figure 2.** Proposed Smart contract for DT platform 6) Integration with Blockchain: The IDS listens to smart contract events (e.g., WaterDataLogged) via Web3 interfaces and buffers incoming records accordingly. Its output dictates whether the data is stored on the BC or discarded. Optional logging of detected anomalies on-chain can improve transparency, support audits, and train future models. The IDS layer is modular and can … view at source ↗

**Figure 3.** Technologies in the Platform on the BC side [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (5 more)

**Figure 6.** Figure 6: Leaked meters and their consumption during nights [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

**Figure 7.** Figure 7: Anomalies Detected: Comparison of Night Leakage (sample) and [PITH_FULL_IMAGE:figures/full_fig_p005_7.png]

**Figure 5.** Figure 5: Comparison Normal and Median usage [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

**Figure 8.** Figure 8: Detected Anomalies Compared with Median Usage Baseline [PITH_FULL_IMAGE:figures/full_fig_p005_8.png]

**Figure 9.** Figure 9: Heatmap of Precision, Recall, and F1-Score per Attack Type [PITH_FULL_IMAGE:figures/full_fig_p006_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

18 extracted references · 16 canonical work pages

[1]

An application of c2-net atmospheric corrections for chlorophyll-a estima- tion in small reservoirs,

A. Cuartero, J. C. C ´aceres-Merino, and J. A. Torrecilla-Pinero, “An application of c2-net atmospheric corrections for chlorophyll-a estima- tion in small reservoirs,” Remote Sensing Applications: Society and Environment, vol. 32, p. 101021, 2023

work page 2023
[2]

Finding optimal spatial window: the influence of size on remote- sensing-based chl-a prediction in small reservoirs,

J. C. C ´aceres Merino, A. Cuartero S ´aez, and J. A. Torrecilla Pinero, “Finding optimal spatial window: the influence of size on remote- sensing-based chl-a prediction in small reservoirs,” IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERV ATIONS AND REMOTE SENSING, vol. 17, p. 18769, 2024

work page 2024
[3]

IoT innovations in sustainable water and wastewater management and water quality monitoring: A comprehensive review of advancements, impli- cations, and future directions,

A. Alshami, E. Ali, M. Elsayed, A. E. E. Eltoukhy, and T. Zayed, “IoT innovations in sustainable water and wastewater management and water quality monitoring: A comprehensive review of advancements, impli- cations, and future directions,” IEEE Access, vol. 12, p. 58427–58453, 2024

work page 2024
[4]

A review of digital twins and their application in cybersecurity based on artificial intelligence,

M. Homaei, O. Mogoll ´on-Guti´errez, J. C. Sancho, M. ´Avila, and A. Caro, “A review of digital twins and their application in cybersecurity based on artificial intelligence,” Artificial Intelligence Review, vol. 57, no. 8, Jul. 2024. [Online]. Available: http://dx.doi.org/10.1007/s10462- 024-10805-3

doi:10.1007/s10462- 2024
[5]

Digital twin smart water conservancy: Status, challenges, and prospects,

W. Li, Z. Ma, J. Li, Q. Li, Y . Li, and J. Yang, “Digital twin smart water conservancy: Status, challenges, and prospects,” Water, vol. 16, no. 14, p. 2038, Jul. 2024

work page 2024
[6]

Smart water resource management using artificial intelligence—a review,

S. R. Krishnan, M. K. Nallakaruppan, R. Chengoden, S. Koppu, M. Iyapparaja, J. Sadhasivam, and S. Sethuraman, “Smart water resource management using artificial intelligence—a review,” Sustainability, vol. 14, no. 20, p. 13384, Oct. 2022

work page 2022
[7]

The role of artificial intelligence in digital twin’s cybersecurity,

M. H. Homaei, A. C. Lindo, J. C. S. N ´u˜nez, O. M. Guti ´errez, and J. A. D´ıaz, “The role of artificial intelligence in digital twin’s cybersecurity,” in Proceedings of the RECSI - Reuni ´on Espa ˜nola sobre Criptolog ´ıa y Seguridad de la Informaci ´on, vol. 6. Spain: RECSI, 2022, p. 7

work page 2022
[8]

Digital twin: Enabling technologies, challenges and open research,

A. Fuller, Z. Fan, C. Day, and C. Barlow, “Digital twin: Enabling technologies, challenges and open research,” IEEE Access, vol. 8, pp. 108 952–108 971, 2020

work page 2020

Show all 18 references

[9]

Smart contracts in energy systems: A systematic review of fundamental approaches and implementations,

D. Kirli, B. Couraud, V . Robu, M. Salgado-Bravo, S. Norbu, M. Andoni, I. Antonopoulos, M. Negrete-Pincetic, D. Flynn, and A. Kiprakis, “Smart contracts in energy systems: A systematic review of fundamental approaches and implementations,” Renewable and Sustainable Energy Revi...

2022
[10]

Blockchain op- portunities for water resources management: A comprehensive review,

T. K. Satilmisoglu, Y . Sermet, M. Kurt, and I. Demir, “Blockchain op- portunities for water resources management: A comprehensive review,” Sustainability, vol. 16, no. 6, p. 2403, Mar. 2024

2024
[11]

Digital transformation in the water distribution sys- tem based on the digital twins concept,

M. Homaei, A. J. Di Bartolo, M. ´Avila, O. Mogoll ´on-Guti´errez, and A. Caro, “Digital transformation in the water distribution sys- tem based on the digital twins concept,” 2024. [Online]. Available: https://arxiv.org/abs/2412.06694

2024 arXiv
[12]

Ensuring cybersecurity in water distribution networks: a risk- based approach,

E. Kim, “Ensuring cybersecurity in water distribution networks: a risk- based approach,” Journal of Water Resources Planning and Management, vol. 147, no. 9, 2021

2021
[13]

A digital twin dam and watershed management platform,

D. Park and H. You, “A digital twin dam and watershed management platform,” Water, vol. 15, no. 11, p. 2106, Jun. 2023

2023
[14]

Industrial internet of water things architecture for data standardization based on blockchain and digital twin technology,

M. A. Mohammed, A. Lakhan, K. H. Abdulkareem, M. K. Abd Ghani, H. A. Marhoon, S. Kadry, J. Nedoma, R. Martinek, and B. G. Zapirain, “Industrial internet of water things architecture for data standardization based on blockchain and digital twin technology,” Journal of Advanced ...

2024
[15]

A blockchain based framework for efficient water manage- ment and leakage detection in urban areas,

M. Naqash, T. Syed, S. Alqahtani, M. Siddiqui, A. Alzahrani, and M. Nauman, “A blockchain based framework for efficient water manage- ment and leakage detection in urban areas,” Urban Science, vol. 7, no. 4, p. 99, Sep. 2023

2023
[16]

Adoption of blockchain technology through digital twins in the construction industry 4.0: A pestels ap- proach,

B. Teisserenc and S. Sepasgozar, “Adoption of blockchain technology through digital twins in the construction industry 4.0: A pestels ap- proach,” Buildings, vol. 11, no. 12, p. 670, Dec. 2021

2021
[17]

Aplicaci´on de t ´ecnicas de reducci ´on de dimensionalidad y balanceo en ciberseguridad,

O. M. Guti ´errez, J. C. S. N ´u˜nez, M. H. Homaei, and J. A. D ´ıaz, “Aplicaci´on de t ´ecnicas de reducci ´on de dimensionalidad y balanceo en ciberseguridad,” in VII Jornadas Nacionales de Investigaci ´on en Ciberseguridad (JNIC), Bilbao, Spain, June 2022

2022
[18]

Anomaly Detection with Generalized Iso- lation Forest,

B. E. Downey, C. K. Leung, A. G. M. Pazdor, R. A. L. Petrillo, D. Popov, and B. R. Schneider, “Anomaly Detection with Generalized Iso- lation Forest,” in Advanced Information Networking and Applications, Springer Nature Switzerland, 2024, pp. 356–368

2024

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.

[1] [1]

An application of c2-net atmospheric corrections for chlorophyll-a estima- tion in small reservoirs,

A. Cuartero, J. C. C ´aceres-Merino, and J. A. Torrecilla-Pinero, “An application of c2-net atmospheric corrections for chlorophyll-a estima- tion in small reservoirs,” Remote Sensing Applications: Society and Environment, vol. 32, p. 101021, 2023

work page 2023

[2] [2]

Finding optimal spatial window: the influence of size on remote- sensing-based chl-a prediction in small reservoirs,

J. C. C ´aceres Merino, A. Cuartero S ´aez, and J. A. Torrecilla Pinero, “Finding optimal spatial window: the influence of size on remote- sensing-based chl-a prediction in small reservoirs,” IEEE JOURNAL OF SELECTED TOPICS IN APPLIED EARTH OBSERV ATIONS AND REMOTE SENSING, vol. 17, p. 18769, 2024

work page 2024

[3] [3]

IoT innovations in sustainable water and wastewater management and water quality monitoring: A comprehensive review of advancements, impli- cations, and future directions,

A. Alshami, E. Ali, M. Elsayed, A. E. E. Eltoukhy, and T. Zayed, “IoT innovations in sustainable water and wastewater management and water quality monitoring: A comprehensive review of advancements, impli- cations, and future directions,” IEEE Access, vol. 12, p. 58427–58453, 2024

work page 2024

[4] [4]

A review of digital twins and their application in cybersecurity based on artificial intelligence,

M. Homaei, O. Mogoll ´on-Guti´errez, J. C. Sancho, M. ´Avila, and A. Caro, “A review of digital twins and their application in cybersecurity based on artificial intelligence,” Artificial Intelligence Review, vol. 57, no. 8, Jul. 2024. [Online]. Available: http://dx.doi.org/10.1007/s10462- 024-10805-3

doi:10.1007/s10462- 2024

[5] [5]

Digital twin smart water conservancy: Status, challenges, and prospects,

W. Li, Z. Ma, J. Li, Q. Li, Y . Li, and J. Yang, “Digital twin smart water conservancy: Status, challenges, and prospects,” Water, vol. 16, no. 14, p. 2038, Jul. 2024

work page 2024

[6] [6]

Smart water resource management using artificial intelligence—a review,

S. R. Krishnan, M. K. Nallakaruppan, R. Chengoden, S. Koppu, M. Iyapparaja, J. Sadhasivam, and S. Sethuraman, “Smart water resource management using artificial intelligence—a review,” Sustainability, vol. 14, no. 20, p. 13384, Oct. 2022

work page 2022

[7] [7]

The role of artificial intelligence in digital twin’s cybersecurity,

M. H. Homaei, A. C. Lindo, J. C. S. N ´u˜nez, O. M. Guti ´errez, and J. A. D´ıaz, “The role of artificial intelligence in digital twin’s cybersecurity,” in Proceedings of the RECSI - Reuni ´on Espa ˜nola sobre Criptolog ´ıa y Seguridad de la Informaci ´on, vol. 6. Spain: RECSI, 2022, p. 7

work page 2022

[8] [8]

Digital twin: Enabling technologies, challenges and open research,

A. Fuller, Z. Fan, C. Day, and C. Barlow, “Digital twin: Enabling technologies, challenges and open research,” IEEE Access, vol. 8, pp. 108 952–108 971, 2020

work page 2020