Pith. sign in

REVIEW 4 major objections 6 minor 37 references

The same programmable Edge–Fog–Cloud substrate can run both control and monitoring cyber-physical workflows, with physical-edge cost that stays local and measurable.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review · grok-4.5

2026-07-31 15:03 UTC pith:ATFAVFWN

load-bearing objection Solid SLICES dual-workload demo with real stage latency numbers; the reusable-workflow-evidence claim is only partly earned on synthetic short runs. the 4 major comments →

arxiv 2607.28193 v1 pith:ATFAVFWN submitted 2026-07-30 cs.DC

A Cloud Continuum Research Infrastructure for Distributed CPS Experimentation

Fabio Orazio Mirto , Giuseppe Tricomi , Luca D'Agati , Andrea Sabbioni , Stefano Silvestri , Francesco Longo , Giovanni Merlino , Armir Bujari
show 2 more authors
Paolo Bellavista Antonio Puliafito
This is my paper
classification cs.DC
keywords Cloud ContinuumEdge–Fog–CloudDigital TwinDistributed ExperimentationCyber-Physical Systemsworkflow provenancereproducible testbeds
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

Cyber-physical systems that span sensors, near-edge coordination, and cloud analytics are hard to compare because each study tends to rebuild its own stack. This paper argues that a two-level setup fixes that: one level exposes and manages federated compute, network, and device resources; the other maps application stages onto Edge, Fog, and Cloud roles where placement, timing, and data provenance are recorded as experimental facts. The same primitives are then used for two different workload classes—a closed-loop energy-community control path with distributed digital-twin coordination, and a continuous air-monitoring path with anomaly alerts and windowed aggregation. Across forty automated runs on a geographically split deployment, virtualized and physical edges produce the same workflow structure; the physical edge adds a predictable ingestion delay that does not spill into backbone or cloud stages. A sympathetic reader cares because this turns continuum research from one-off prototypes into replayable, stage-attributable experiments on a shared substrate.

Core claim

A two-level reference architecture—research-infrastructure substrate below, Edge–Fog–Cloud workflow organization above—can host both control-oriented and monitoring-oriented cyber-physical workloads with the same deployment descriptors, while preserving per-stage provenance and bounding the overhead of physical versus virtualized edges to the Edge-to-Fog hop.

What carries the argument

The two-level reference architecture plus run descriptors: infrastructure binding (where resources are exposed and provisioned) is separated from application stage roles (Edge sensing/safety, Fog mediation, Cloud aggregation/decision, optional HPC back-end), so each run records placement, timestamps, and provenance as first-class evidence.

Load-bearing premise

Short controlled runs with synthetic energy and environmental traces on one fixed multi-site layout are enough to stand in for real sensor noise, longer-lived systems, and other network paths.

What would settle it

Repeat the same descriptors with real field traces, longer windows, or a different inter-site path and check whether physical-edge ingestion overhead still stays confined to Edge→Fog (~50% class) while cloud decisions and aggregation remain configuration-stable and fully provenance-linked.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Control and monitoring continuum apps can be compared on one substrate instead of separate domain stacks.
  • Latency and correctness claims become stage-attributable (generation, fog arrival, window close, decision) rather than end-to-end averages alone.
  • Physical versus virtual edge becomes a controlled placement factor with predictable local cost, not a full-stack rewrite.
  • Experiment descriptors can serve as the infrastructure-side counterpart to scientific workflow specs for replay and FAIR-style reuse.
  • HPC back-end stages already named in the decomposition can be scored with the same evidence rules (batch time, transfer cost, model availability).

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If stage-level provenance is required for publishable continuum results, testbeds that only provision slices without workflow descriptors will under-serve CPS evaluation.
  • Bounded edge overhead that does not propagate suggests placement-sensitivity studies should stress the Edge–Fog hop and device class first, before retuning cloud analytics.
  • The same grammar could benchmark recovery and failure injection as descriptor variants without new application code.
  • Digital-twin work that stays conceptual about layering can be stress-tested by forcing twin fragments to move across Edge, Fog, and Cloud under these descriptors.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. The paper proposes a two-level reference architecture for Cloud Continuum CPS experimentation on the SLICES Cloud Continuum Blueprint: a research-infrastructure layer (Kubernetes/Crossplane, resource catalogue, Stack4Things/IoTronic) is separated from an application-level Edge–Fog–Cloud workflow pattern in which placement, timing, and provenance are first-class concerns. The pattern is instantiated with two profiles—REC (control/Digital Twin coordination via MQTT, Kafka, TEANS) and AirWatch (monitoring with fog mediation and Spark window aggregation)—and evaluated in a 40-run campaign (10 per scenario×configuration) comparing virtualized edge pods (POD) to physical Raspberry Pi edges (RASP) across Messina–Bologna–SLICES. The main empirical result is that both workloads run on the same primitives with RASP adding ~52–57% Edge→Fog ingestion latency that does not propagate to backbone or cloud stages (Table 5, Fig. 3), with stage timestamps used for attribution.

Significance. If the result holds under broader conditions, the work is a useful methodological contribution for continuum systems research: it treats the experimental unit as a full Edge–Fog–Cloud workflow with explicit resource bindings and descriptors, rather than a single microservice or ad hoc demo, and ships a public artifact (orchestration scripts, manifests, datasets). The POD vs RASP comparison with NTP-synchronized stage timestamps and IQR-filtered means±σ is a concrete, reproducible measurement of heterogeneous-edge cost on a real multi-site path. Significance is incremental rather than foundational—the stack largely composes known components (Mosquitto, Kafka, Spark, S4T, TEANS)—but the reusable two-level framing, shared stage grammar (Table 3), and dual control/monitoring validation on one federated substrate are valuable for SLICES-style experimental science and for authors who need comparable continuum evidence rather than domain-only prototypes.

major comments (4)
  1. [§6.3, Table 5, Q2–Q4] Central claim vs. evidence scope (§5.2–5.4, §6.1–6.3, Abstract, Q1–Q4): The paper claims the substrate supports control and monitoring workloads while preserving workflow properties—traceability, deterministic aggregation, and bounded heterogeneous-edge impact—as a “workflow-evidence-based basis” for continuum research. Table 5 and Fig. 3 primarily establish stage latencies and that RASP overhead is Edge→Fog-local. REC “consistent TEANS decisions” and AirWatch “14 windows / deterministic aggregation” are reported under synthetic traces, fixed 5 s sampling, and 10-minute runs. §6.4 acknowledges these limits, but the Abstract and §6.3 still generalize to reusable workflow evidence. Either (i) add stress that breaks generator regularity (bursty/lossy streams, reordering, clock skew beyond NTP, longer windows) and report provenance completeness / window-failure rates, or (ii) narrow claims s
  2. [§4.3, §5.1, Table 3] Placement is declared a first-class experimental concern (Abstract; Table 2; §3.1; §4.3) and the architecture’s portability argument rests on re-binding stages across tiers (§3.3–3.4). The campaign only varies edge realization (POD vs RASP) on a fixed Messina gateway / Bologna fog / SLICES cloud mapping. No run moves anomaly detection, Digital Twin fragments, or aggregation across layers. Without at least one controlled placement swap under the same descriptors, the claim that the two-level model enables comparable placement experiments is aspirational. A minimal fix is one additional configuration (e.g., fog vs cloud anomaly path, or edge vs fog pre-filter) with the same stage metrics, or an explicit demotion of placement comparison to future work in the contributions list.
  3. [Table 3, §3.3, §7] Table 3 and §3.3 fully specify an HPC back-end stage (optimization/calibration; batch duration, transfer overhead, model-output availability) as part of the continuum grammar, and the introduction positions HPC as the continuum back-end. That stage is never exercised; the footnote defers it to a follow-up. Including unevaluated HPC in the reference architecture and decomposition while validating only Edge–Fog–Cloud latency paths overstates completeness. Either run a minimal offload experiment under the same descriptors or move HPC out of the validated architecture into a clearly labeled extension roadmap so contributions match evidence.
  4. [§5.2, §6.1–6.2, Q2] Q2 asks whether per-stage evidence suffices to interpret results after execution. The protocol records t_gen, t_arr, t_comp and device/provenance identifiers (§5.2), which supports latency attribution. The manuscript does not show end-to-end provenance artifacts (e.g., join rates from edge observation IDs through fog mediation to TEANS decisions or Spark windows, drop/duplicate counts, or causal trace examples). “Preserves provenance” is therefore stronger than the presented analysis. Add a small provenance completeness table or a worked trace for one REC decision and one AirWatch window, or rephrase Q2 results as stage-timestamp attribution only.
minor comments (6)
  1. [Figure 2] Fig. 2 caption cites “Optimized MQTT ingestion (65 ms)” as if a design target; body text treats ~65 ms as measured RASP mean. Align caption with measurement language.
  2. [§6.4] §6.4 “Belgium (the selected SLICES site)” is awkward and inconsistent with earlier “SLICES Cloud” wording; name the site consistently.
  3. [§5.4] Keywords and related-work table are helpful; a short explicit threat-to-external-validity paragraph tying synthetic generators to each of Q1–Q4 would help readers who skip §6.4.
  4. [§2.3, §5, Acknowledgements] Minor language/typos: “partial funding” → “partially funded” (Acknowledgements); “out for the intended time window” (§2.3) is unclear; “deviceless” in ref. [37] context is fine but ensure in-text acronyms (EPREM, TEANS, LR) are expanded at first use in §5.
  5. [Table 5] Table 5 reports Cloud Aggregation with large absolute means (~2.3–2.5 s) and notes multi-tenant effects; a one-line note on whether window size (60 s) makes this latency operationally acceptable for AirWatch would aid interpretation.
  6. [§4.6, §5.3] Artifact URL is appreciated; state license and whether raw per-run timestamp CSVs (not only aggregates) are included, to match the FAIR claims in §4.6.

Circularity Check

1 steps flagged

Measurement-and-architecture paper: latency and workflow claims come from timed runs, not from identities that force the result; only mild non-load-bearing self-use of prior stack components.

specific steps
  1. self citation load bearing [§5.1 Deployment Topology; §6.1 REC / TEANS; refs [26],[35]–[37]]
    "At the Cloud tier, Apache Spark Structured Streaming handles stateful window-based aggregation, while the TEANS engine executes global Digital Twin decisions for REC... Physical edge-devices, such as Raspberry Pis, are integrated into this continuum by attaching them to the Stack4Things (S4T) substrate."

    TEANS and Stack4Things/Lightning-Rod are prior work with substantial author overlap. They supply the REC decision engine and edge device management used in the evaluation. This is ordinary engineering self-reuse of stack components, not a uniqueness theorem or a definition that forces Table 5 latencies; the measured Edge→Fog overheads and aggregation counts remain independent empirical outputs. Flagged only as minor non-load-bearing self-dependence.

full rationale

This paper does not present a first-principles derivation whose outputs are forced by construction from fitted inputs or self-defined quantities. The strongest claims (same SLICES primitives host REC and AirWatch; RASP adds ~52–57% Edge→Fog ingestion latency that stays local; stage-level provenance and aggregation stability) are supported by a campaign of 40 automated runs with explicit timestamps (t_gen, t_arr, t_comp), IQR-filtered means/σ in Table 5, and Fig. 3. Overhead is defined as (RASP/POD−1) on measured latencies, not as a fitted parameter renamed as a prediction. Prior author-overlapping components (TEANS [26], Stack4Things/Lightning-Rod, IoTronic) appear as engineering substrates in the deployment stack; they are not invoked as uniqueness theorems or as equations that define the measured latencies. No self-definitional loop, no fitted-input-as-prediction, and no ansatz smuggled in as a forced result. Residual weakness is external validity (synthetic traces, short runs, one topology)—a correctness/generalization concern, not circularity. Score 1 only for ordinary self-reuse of the authors’ prior stack pieces, which is not load-bearing for the experimental claims.

Axiom & Free-Parameter Ledger

5 free parameters · 5 axioms · 2 invented entities

Load-bearing content is engineering and experimental, not axiomatic physics. The claim rests on standard distributed-systems assumptions (time sync, overlay networking, container orchestration), SLICES blueprint capabilities taken as given, synthetic workload fidelity, and the authors’ decomposition of continuum roles. No new physical entities; free parameters are experimental knobs (sampling, windows, duration, topology) chosen for the campaign rather than fitted to prove a law.

free parameters (5)
  • Edge sampling interval = 5 s
    Fixed at 5 s for both workloads; directly shapes ingestion load and window fill.
  • AirWatch Spark tumbling window = 60 s
    Chosen aggregation granularity (60 s over 9 variables); determines cloud-stage completeness metrics.
  • Experiment duration = 10 min
    10-minute runs define steady-state observation window; excludes long-term aging/drift.
  • IQR outlier threshold = <1.5×IQR
    Post-hoc filter (<1.5×IQR, noted <1% or similar) used before reporting steady-state means in Table 5.
  • Synthetic trace generators (energy / environmental) = synthetic (unspecified full seed/profile)
    Domain values are generated, not field-captured; generator settings are part of the experiment but not fully numeric in-text.
axioms (5)
  • domain assumption NTP keeps multi-site clock offsets typically under ~1 ms so L_ing = t_arr − t_gen is a valid stage latency.
    Stated in §5.2 measurement protocol; underpins all latency attribution.
  • domain assumption SLICES CC Blueprint plus K8s/Crossplane/Stack4Things can expose Edge, Fog, and Cloud roles as a coherent federated substrate.
    Level-1 architecture §3.2; taken from prior SLICES/blueprint work rather than re-proved.
  • domain assumption POD vs RASP differ only in Edge-tier realization while sharing MQTT workflow logic, so latency deltas attribute to physical edge path.
    §5.1 controlled comparison design; central to Q3 overhead claims.
  • ad hoc to paper Synthetic REC/AirWatch traces adequately stress balancing and monitoring logic for architectural validation.
    §6.1–6.2 and limitations §6.4; required for interpreting “consistent decisions” and stable aggregation.
  • domain assumption Workflow correctness in continuum settings is judged by placement, timing, and provenance, not only service outputs.
    Design requirements Table 2 and §2.3 framing; shapes what evidence is collected.
invented entities (2)
  • Two-level reference architecture (RI layer vs Edge–Fog–Cloud application layer) with experiment descriptors no independent evidence
    purpose: Separate substrate provisioning from workflow roles and make runs replayable/comparable.
    Organizational contribution of the paper (§3–4.6); not a physical entity but a methodological construct. Independent use depends on external adoption of descriptors.
  • Workflow-stage grammar shared by REC and AirWatch (Edge/Fog/Cloud/HPC evidence columns) no independent evidence
    purpose: Allow dual workload classes to be compared on one substrate without unrelated prototypes.
    Table 3 decomposition; HPC column specified but not experimentally exercised in this campaign.

pith-pipeline@v1.2.0-daily-grok45 · 25151 in / 3689 out tokens · 74007 ms · 2026-07-31T15:03:19.104501+00:00 · methodology

0 comments
read the original abstract

Cloud Continuum applications require experimental environments capable of combining heterogeneous Edge, Fog, Cloud, and high-performance computing resources while preserving reproducibility, observability, and control over distributed deployments. This paper presents a two-level reference architecture for Cloud Continuum experimentation built on top of the SLICES Cloud Continuum Blueprint. The proposed approach separates the research-infrastructure layer, which exposes and manages distributed resources, from the application layer, where Cyber-Physical workflows are organized according to an Edge-Fog-Cloud pattern in which placement, timing, and data provenance are treated as first-class experimental concerns. The architecture is designed to support multiple continuum applications rather than a single domain-specific prototype. At the Edge, applications interact with physical devices and perform low-latency sensing or safety actions; at the Fog, they execute near-source coordination, mediation, and stream-processing logic; at the Cloud, they consolidate global knowledge through analytics, optimization, and visualization. This partitioning enables researchers to deploy, customize, and compare alternative control and monitoring strategies over the same programmable infrastructure substrate. The approach is validated through two representative use cases: Renewable Energy Community management, where distributed Digital Twin coordination and time-window-based energy control are requested, and AirWatch, a monitoring pipeline focused on anomaly detection, low-latency alerting, and cloud-side aggregation. Both workloads are evaluated through a systematic campaign of 40 runs comparing virtualized and physical edge deployments over a geographically distributed infrastructure.

Figures

Figures reproduced from arXiv: 2607.28193 by Andrea Sabbioni, Antonio Puliafito, Armir Bujari, Fabio Orazio Mirto, Francesco Longo, Giovanni Merlino, Giuseppe Tricomi, Luca D'Agati, Paolo Bellavista, Stefano Silvestri.

Figure 1
Figure 1. Figure 1: Two-level reference architecture. The first level exposes and controls SLICES resources through the CC Blueprint, while the second level maps those [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: End-to-end dataflow of the instantiated Edge–Fog–Cloud topology. The Extreme Edge tier hosts physical Raspberry Pi boards or containerized pods [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Latency distributions across the RASP deployment. Panel (a) shows the Edge [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

37 extracted references · 12 canonical work pages

  1. [1]

    Bonomi, R

    F. Bonomi, R. Milito, J. Zhu, S. Addepalli, Fog computing and its role in the internet of things, in: Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, 2012, pp. 13–16.doi:10.1145/2342509.2342513

    arXiv 2012

  2. [2]

    W. Shi, J. Cao, Q. Zhang, Y . Li, L. Xu, Edge computing: Vi- sion and challenges, IEEE Internet of Things Journal 3 (5) (2016) 637–646.doi:10.1109/JIOT.2016.2579198

    arXiv 2016

  3. [3]

    Bittencourt, R

    L. Bittencourt, R. Immich, R. Sakellariou, N. Fonseca, E. Madeira, M. Curado, L. Villas, L. DaSilva, C. Lee, O. Rana, The internet of things, fog and cloud continuum: Integration and challenges, Internet of Things 3-4 (2018) 134–155.doi: 10.1016/j.iot.2018.09.005

    work page doi:10.1016/j.iot.2018.09.005 2018

  4. [4]

    Chiang, T

    M. Chiang, T. Zhang, Fog and IoT: An overview of research op- portunities, IEEE Internet of Things Journal 3 (6) (2016) 854– 864.doi:10.1109/JIOT.2016.2584538

    arXiv 2016

  5. [5]

    Osanaiye, S

    O. Osanaiye, S. Chen, Z. Yan, R. Lu, K.-K. R. Choo, M. Dlodlo, From cloud to fog computing: A review and a conceptual live VM migration framework, IEEE Access 5 (2017) 8284–8300. doi:10.1109/ACCESS.2017.2692960

    arXiv 2017

  6. [6]

    951850 (2020).doi:10.3030/951850

    European Commission, SLICES-DS: Scientific large-scale in- frastructure for computing/communication experimental studies – design study, cORDIS project fact sheet, Grant Agreement No. 951850 (2020).doi:10.3030/951850

    work page doi:10.3030/951850 2020

  7. [7]

    Balouek-Thomert, E

    D. Balouek-Thomert, E. G. Renart, A. R. Zamani, A. Simonet, M. Parashar, Towards a computing continuum: Enabling edge- to-cloud integration for data-driven workflows, The International Journal of High Performance Computing Applications 33 (6) (2019) 1159–1174.doi:10.1177/1094342019877383

    work page doi:10.1177/1094342019877383 2019

  8. [8]

    B. Chun, D. Culler, T. Roscoe, A. Bavier, L. Peterson, M. Wawr- zoniak, M. Bowman, PlanetLab: An overlay testbed for broad- coverage services, Computer Communication Review 33 (3) (2003) 3–12.doi:10.1145/956993.956995

    arXiv 2003

  9. [9]

    Berman, J

    M. Berman, J. S. Chase, L. Landweber, A. Nakao, M. Ott, D. Raychaudhuri, R. Ricci, I. Seskar, GENI: A federated testbed for innovative network experiments, Computer Networks 61 (2014) 5–23.doi:10.1016/j.bjp.2013.12.037

    work page doi:10.1016/j.bjp.2013.12.037 2014

  10. [10]

    Adjih, E

    C. Adjih, E. Baccelli, E. Fleury, G. Harter, N. Mitton, T. Noel, R. Pissard-Gibollet, F. Saint-Marcel, G. Schreiner, J. Vandaele, T. Watteyne, Fit iot-lab: A large scale open experimental iot testbed, in: 2015 IEEE 2nd World Forum on Internet of Things (WF-IoT), 2015, pp. 459–464.doi:10.1109/WF-IoT.2015. 7389098

    work page doi:10.1109/wf-iot.2015 2015

  11. [11]

    Keahey, J

    K. Keahey, J. Anderson, Z. Zhen, P. Riteau, P. Ruth, D. Stanzione, M. Cevik, J. Colleran, H. S. Gunawi, C. Ham- mock, J. Mambretti, A. Barnes, F. Halbah, A. Rocha, J. Stubbs, Lessons learned from the chameleon testbed, in: 2020 USENIX Annual Technical Conference (USENIX ATC 20), USENIX Association, 2020, pp. 219–233. URLhttps://www.usenix.org/conference/a...

    2020

  12. [12]

    B. C. Senel, M. Mouchet, J. Cappos, O. Fourmaux, T. Fried- man, R. McGeer, EdgeNet: A multi-tenant and multi-provider edge cloud, in: Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking, 2021, pp. 49–54. doi:10.1145/3434770.3459737

    arXiv 2021

  13. [13]

    Satyanarayanan, The emergence of edge computing, Com- puter 50 (1) (2017) 30–39.doi:10.1109/MC.2017.9

    M. Satyanarayanan, The emergence of edge computing, Com- puter 50 (1) (2017) 30–39.doi:10.1109/MC.2017.9

    doi:10.1109/mc.2017.9 2017

  14. [14]

    C.-H. Hong, B. Varghese, Resource management in fog/edge computing: A survey on architectures, infrastructure, and al- gorithms, ACM Computing Surveys 52 (5) (2019) 1–37.doi: 10.1145/3326066

    doi:10.1145/3326066 2019

  15. [15]

    T. Lynn, J. G. Mooney, B. Lee, P. T. Endo (Eds.), Orches- tration from the Cloud to the Edge, Springer International Publishing, Cham, 2020, Ch. 4, pp. 61–77.doi:10.1007/ 978-3-030-41110-7_4

    2020

  16. [16]

    Deelman, D

    E. Deelman, D. Gannon, M. Shields, I. Taylor, Workflows and e-science: An overview of workflow system features and capa- bilities, Future Generation Computer Systems 25 (5) (2009) 528– 540.doi:10.1016/j.future.2008.06.012

    work page doi:10.1016/j.future.2008.06.012 2009

  17. [17]

    S. B. Davidson, J. Freire, Provenance and scientific workflows: Challenges and opportunities, in: Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data, 2008, pp. 1345–1350.doi:10.1145/1376616.1376772

    arXiv 2008

  18. [18]

    Rosendo, P

    D. Rosendo, P. Silva, M. Simonin, A. Costan, G. Antoniu, E2Clab: Exploring the computing continuum through repeatable, replicable and reproducible edge-to-cloud experiments, in: Pro- ceedings of the 2020 IEEE International Conference on Cluster Computing (CLUSTER), 2020, pp. 176–186.doi:10.1109/ CLUSTER49012.2020.00028

    arXiv 2020

  19. [19]

    Deelman, K

    E. Deelman, K. Vahi, G. Juve, M. Rynge, S. Callaghan, P. J. Maechling, R. Mayani, W. Chen, R. Ferreira da Silva, M. Livny, K. Wenger, Pegasus, a workflow management system for science automation, Future Generation Computer Systems 46 (2015) 17– 35.doi:10.1016/j.future.2014.10.008. 14

    doi:10.1016/j.future.2014.10.008 2015

  20. [20]

    Colonnelli, B

    I. Colonnelli, B. Cantalupo, I. Merelli, M. Aldinucci, Stream- Flow: cross-breeding cloud with HPC, IEEE Transactions on Emerging Topics in Computing 9 (4) (2021) 1723–1737.doi: 10.1109/TETC.2020.3019202

    arXiv 2021

  21. [21]

    Kritzinger, M

    W. Kritzinger, M. Karner, G. Traar, J. Henjes, W. Sihn, Digi- tal twin in manufacturing: A categorical literature review and classification, IFAC-PapersOnLine 51 (11) (2018) 1016–1022. doi:10.1016/j.ifacol.2018.08.474

    doi:10.1016/j.ifacol.2018.08.474 2018

  22. [22]

    Jones, C

    D. Jones, C. Snider, A. Nassehi, J. Yon, B. Hicks, Characterising the digital twin: A systematic literature review, CIRP Journal of Manufacturing Science and Technology 29 (2020) 36–52.doi: 10.1016/j.cirpj.2020.02.002

    doi:10.1016/j.cirpj.2020.02.002 2020

  23. [23]

    Fuller, Z

    A. Fuller, Z. Fan, C. Day, C. Barlow, Digital twin: Enabling tech- nologies, challenges and open research, IEEE Access 8 (2020) 108952–108971.doi:10.1109/ACCESS.2020.2998358

    arXiv 2020

  24. [24]

    Oprea, A

    S.-V . Oprea, A. Bâra, An edge-fog-cloud computing architec- ture for IoT and smart metering data, Peer-to-Peer Network- ing and Applications 16 (2023) 1415–1430.doi:10.1007/ s12083-022-01436-y

    2023

  25. [25]

    Oprea, A

    S.-V . Oprea, A. Bâra, Edge and fog computing using IoT for direct load optimization and control with flexibility services for citizen energy communities, Knowledge-Based Systems 228 (2021) 107293.doi:10.1016/j.knosys.2021.107293

    arXiv 2021

  26. [26]

    Cicceri, G

    G. Cicceri, G. Tricomi, L. D’Agati, F. Longo, G. Merlino, A. Puliafito, A deep learning-driven self-conscious distributed cyber-physical system for renewable energy communities, Sen- sors 23 (9) (2023) 4549.doi:10.3390/s23094549

    work page doi:10.3390/s23094549 2023

  27. [27]

    Lowitzsch, C

    J. Lowitzsch, C. E. Hoicka, F. J. van Tulder, Renewable energy communities under the 2019 european clean energy package — governance model for the energy clusters of the future?, Re- newable and Sustainable Energy Reviews 122 (2020) 109489. doi:10.1016/j.rser.2019.109489

    arXiv 2019

  28. [28]

    Sousa, T

    T. Sousa, T. Soares, P. Pinson, F. Moret, T. Baroche, E. Sorin, Peer-to-peer and community-based markets: A comprehensive review, Renewable and Sustainable Energy Reviews 104 (2019) 367–378.doi:10.1016/j.rser.2019.01.036

    doi:10.1016/j.rser.2019.01.036 2019

  29. [29]

    Tricomi, L

    G. Tricomi, L. D’Agati, F. Longo, G. Merlino, A. Puliafito, S. Silvestri, Paving the way for an urban intelligence OpenStack- based architecture, in: 2024 IEEE International Conference on Smart Computing (SMARTCOMP), 2024, pp. 284–289.doi: 10.1109/SMARTCOMP61445.2024.00069

    arXiv 2024

  30. [30]

    Morawska, P

    L. Morawska, P. K. Thai, X. Liu, A. Asumadu-Sakyi, G. Ayoko, A. Bartonova, A. Bedini, F. Chai, B. Christensen, M. Dunbabin, J. Gao, G. S. Hagler, R. Jayaratne, P. Kumar, A. K. Lau, P. K. Louie, M. Mazaheri, Z. Ning, N. Motta, B. Mullins, M. M. Rah- man, Z. Ristovski, M. Shafiei, D. Tjondronegoro, D. Wester- dahl, R. Williams, Applications of low-cost sens...

    2018

  31. [31]

    Castell, F

    N. Castell, F. R. Dauge, P. Schneider, M. V ogt, U. Lerner, B. Fishbain, D. Broday, A. Bartonova, Can commercial low-cost sensor platforms contribute to air quality monitoring and expo- sure estimates?, Environment International 99 (2017) 293–302. doi:10.1016/j.envint.2016.12.007

    work page doi:10.1016/j.envint.2016.12.007 2017

  32. [32]

    B. Maag, Z. Zhou, L. Thiele, A survey on sensor calibration in air pollution monitoring deployments, IEEE Internet of Things Journal 5 (6) (2018) 4857–4870.doi:10.1109/JIOT.2018. 2853660

    work page doi:10.1109/jiot.2018 2018

  33. [33]

    Bharathi, A

    B. Bharathi, A. H. M. Rafeeq, M. Prakash, Fog computing enabled air quality monitoring and prediction leveraging deep learning in IoT, Journal of Intelligent & Fuzzy Systems 43 (1) (2022) 1501–1512.doi:10.3233/JIFS-212713

    work page doi:10.3233/jifs-212713 2022

  34. [34]

    crossplane.io, cloud Native Computing Foundation (CNCF) project documentation (2024)

    Crossplane Project, Crossplane documentation,https://docs. crossplane.io, cloud Native Computing Foundation (CNCF) project documentation (2024)

    2024

  35. [35]

    Longo, D

    F. Longo, D. Bruneo, S. Distefano, G. Merlino, A. Puliafito, Stack4things: An openstack-based framework for iot, in: 2015 3rd International Conference on Future Internet of Things and Cloud, 2015, pp. 204–211.doi:10.1109/FiCloud.2015.97

    work page doi:10.1109/ficloud.2015.97 2015

  36. [36]

    D’Agati, G

    L. D’Agati, G. Tricomi, M. Arena, F. Longo, A. Puliafito, G. Merlino, IoT Orchestration in the Compute Continuum: In- tegrating Kubernetes with Stack4Things , in: 2025 IEEE 25th International Symposium on Cluster, Cloud and Internet Com- puting Workshops (CCGridW), 2025, pp. 140–147. URLhttps://doi.ieeecomputersociety.org/10.1109/ CCGridW65158.2025.00028

    arXiv 2025

  37. [37]

    Merlino, G

    G. Merlino, G. Tricomi, L. D’Agati, Z. Benomar, F. Longo, A. Puliafito, Faas for iot: Evolving serverless towards deviceless in i/oclouds, Future Generation Computer Systems 154 (2024) 189–205.doi:10.1016/j.future.2023.12.029. 15

    work page doi:10.1016/j.future.2023.12.029 2024