Conceptio › Archive › arXiv CS
arXiv CSopen access

Real-World Deployment and Performance Characterisation of Fog-Based Deep Learning for Cold-Chain Temperature Prediction over LoRaWAN

· arxiv_cs
arXiv CS · Papers · License: Open Access
Open Source ↗Direct PDF ↓
clouddistributed-computingparallel-computing
distributed computing, parallel computing, cloud

arXiv:2609.14036v2 [cs.DC] 15 Sep 2026

Real-World Deployment and Performance Characterisation of Fog-Based Deep Learning for Cold-Chain Temperature Prediction over LoRaWAN Jeremiah Taguta

Jean Frederic Isingizwe Nturambirwe

Clement Nthambazale Nyirenda

Department of Computer Science University of the Western Cape Cape Town, South Africa 0000-0001-8199-4307

eResearch Office University of the Western Cape Cape Town, South Africa 0000-0002-1794-7343

eResearch Office & Department of Computer Science University of the Western Cape Cape Town, South Africa 0000-0002-4181-0478

Abstract—Fresh fruits and vegetables (FFVs) are highly perishable, and cold-chain breaks contribute significantly to global food waste. While Machine Learning (ML) can enable proactive intervention, cloud-based inference faces challenges such as latency and data loss. Fog computing addresses these issues but has been tested only in simulation for FFV cold-chain temperature prediction. To the best of the authors’ knowledge, this paper presents its first real-world deployment. A fog-deployed LSTMGRU model predicted cold-room temperature using LoRaWAN sensor data collected from a South African apple cold-storage facility with induced cold-chain breaks. Running entirely on a Raspberry Pi 4 with no cloud dependency, the system generated conditional SHAP explanations only when a break is predicted. The deployed system predicts cold-room temperature with an MAE of 0.2°C at roughly 0.2 kWh per day (≈0.7 Wh per prediction). Predictions were delivered in under one second (555 ms), dominated by network and messaging rather than computation, with conditional explanations adding modest cost. SHAP consumes 28% more CPU but is well within the hardware’s capacity. The model attributes its predictions primarily to temperature, humidity, and their interaction. Critically, the deployment surfaced what simulation cannot: a sensor-triggered single point of failure, alongside genuine resilience, autonomous recovery from infrastructure faults and continued operation through internet loss. These are the first published deployment benchmarks for fog-based temperature prediction in FFV cold chains, establishing that explainable temperature forecasting is feasible on resource-constrained edge hardware. Future work includes asynchronous sensor fusion, commercial cold chain deployment, alternative model architectures, and causal analysis. Index Terms—Cold-chain monitoring, fog computing, LoRaWAN, explainable AI, temperature prediction, Internet of Things

I. I NTRODUCTION Globally, a third of food produced for human consumption is lost or wasted across the supply chain, with fresh fruits and ISBN 979-8-3195-1782-1/26/$31.00 ©2026 IEEE This work is based on the research supported in part by the National Research Foundation of South Africa (Ref Numbers SRUG22051310444, PMDS230703126166). The opinions, findings, conclusions or recommendations expressed in any publication generated by the NRF-supported research are those of the author(s) alone, and the NRF accepts no liability whatsoever in this regard.

vegetables (FFVs) contributing nearly half of the loss, including in developing countries like South Africa [1]–[3]. Because FFVs are highly perishable, proper cold chain monitoring is required because they are very sensitive to temperature fluctuations [2], [4], such that even short deviations result in temperature abuse, short shelf life, qualitative and quantitative losses, food insecurity, food-borne illness or death, financial loss and waste-driven global warming [1], [2], [4], [5]. Food loss and waste also wastes resources such as water, energy and land [1]. While the Internet of Things (IoT) has been utilised for real-time cold chain monitoring, it lacks predictive capability [3], [4], [6]. Machine learning (ML) offers proactive cold chain control by predicting temperature changes [4], [7], but where ML models run from becomes a challenge. When deployed in the cloud, ML models may receive data late, delaying prediction and hindering proactive, real-time cold chain management [8]. The model may receive incomplete data, which can affect its accuracy and lead to unreliable predictions [5], potentially resulting in incorrect actions and increased FFV loss or waste. Late or inaccurate predictions are of no use; hence the need for low-latency ML inference, closer to the data source, reducing data loss, as offered by Fog computing [8]. It can therefore be argued that solving FFVs’ cold chain monitoring challenges is beyond the capability of a single solution, but requires the integration of IoT, ML and Fog computing [3], [4], [6]. This study, therefore, investigates the integration of these technologies for increased FFV cold chain integrity and to minimise the massive global and South African burden of food loss and waste, and associated consequences. While fog computing is well-suited to real-time applications, fog-based ML for FFV cold-chain monitoring remains underexplored [3] and has, to date, been demonstrated only in simulation [5]. To the best of the authors’ knowledge, this study presents the first reported real-world deployment and measurement of an explainable ML (stacked LSTM-GRU (LSGR) architecture) temperature-prediction pipeline with multi-sensor fusion of independently timed (asynchronously arriving) sensors, combining the most recent reading from each

at inference, on a fog node in an operational FFV cold room (a controlled cold room maintained at real cold-chain operating temperatures, with deliberately induced deviations). This study makes the following contributions: • The first published energy, pipeline latency, compute resource (CPU, RAM), and accuracy benchmarks for fogbased ML for temperature prediction in FFV cold-chains under real-world deployment. • A demonstration that real-time LSGR inference and conditional SHAP explainability are viable on a Raspberry Pi 4 under sustained deployment, with explainability triggered only on temperature break predictions to minimise steady-state overhead. • An event-driven sensor-fusion mechanism that integrates heterogeneous LoRaWAN sensors transmitting at the same nominal interval but with independent, unsynchronised timing, fusing the most recent available reading from each sensor at inference time. • A characterisation of system fault tolerance under real field failures (battery depletion, power interruption, connectivity loss), demonstrating autonomous recovery without manual intervention. The remainder of this paper is structured as follows. Section II reviews related work; Section III describes the proposed system; Section IV details the experimental setup; Section V presents and discusses the results; and Section VI concludes with key findings and future research directions. II. R ELATED W ORK Many studies have used ML to predict temperature in FFV cold chains. A Multilayer Perceptron (MLP) was utilised for predicting the temperature of apples during cold storage [9], [10], and citrus fruits and bananas during refrigerated transport [11]. Loisel et al. [10] also used Random Forest (RF), AdaBoost, Linear Regression (LR), Lasso, and Support Vector Machines (SVM). A 1D-Convolutional Neural Network predicted temperature at sensor-free locations in strawberry shipments [12], while an Extreme Learning Machine (ELM), Decision Trees, LR, Naive Bayes, RF and SVM were compared for predicting the internal temperature of transport carrying tomatoes [13]. A 4-layer LSTM predicted the internal temperature of navel oranges’ cold rooms and the time to cold chain breaks [14]. Moreover, Taguta et al. [7] compared Gated Recurrent Unit, MLP, ELM and Extreme Gradient Boosting for apple cold room temperature prediction. Emenike et al. [15] predicted temperature in refrigerated transport carrying FFVs using Artificial Neural Networks. Of these studies, only two focused on the South African context [7], [15], and only one focused on the cold room phase and a single product [7]. Moreover, the reviewed studies do not explain or interpret the models, yet explainability is as important as model accuracy because it helps stakeholders understand how models arrive at decisions, increases trust, provides mechanisms to improve the models, and supports compliance reporting [16]. While these studies showcase the temperature-predictive power of ML, they utilised temporarily split existing datasets. Such

validation, though useful, does not imply strong real-world deployment performance, as packet loss, stale data, asynchronous data transmission, and computing constraints characterise realworld deployment and require investigation [3]. Although Junjie et al. [17] compared peephole LSTM and BP neural networks to predict temperature in a refrigerated transport vehicle carrying vegetables, inference runs on a personal computer receiving data from the cloud. Cloudbased prediction introduces latency unacceptable for real-time control. It depends on continuous, high-bandwidth connectivity that may be unavailable at farms, packing houses, and cold rooms in low-connectivity settings or refrigerated trucks driving through such settings [3], [18], [19], where failed uploads mean no predictions and no proactive control [8], [19]. Fog computing brings computation and storage closer to the sensors [19]: a sensor and fog node connected over a local network guarantee low-latency inference without internet dependence [3], [18], while data can be aggregated for later upload under reduced bandwidth when connectivity allows [18], [19]. However, the reviewed studies did not use fog computing despite its benefits. A recent systematic review of ML for temperature prediction and temperature break detection and prediction in FFV cold chains confirmed the absence of fog computing and live inference on streaming sensor data [3]. Even studies collecting data using IoT infrastructure used it as a sophisticated logging mechanism, training and evaluating models offline on the resulting datasets rather than during operation. Therefore, both the Fog–ML integration gap and the IoT–Fog–ML integration gap persist in research on FFV cold-chain temperature prediction. To the best of the authors’ knowledge, Taguta et al. [5] was the first study to investigate the integration of IoT, Fog, and ML for predicting temperature in FFV cold chains using SimPy simulations. The prior work provides no mechanism to cost the model in terms of energy, RAM, CPU usage and latency on real-world deployment hardware, as the models were not deployed; a realism gap which remains unfilled. It lacks real-world characterisation of the deployment, especially on low-resourced fog nodes, yet real-world deployment validates the findings in the real operational world. The prior work did not study explainability, whose utilisation for FFV cold room temperature prediction models at the fog layer remains unexplored, yet critical for low-resourced hardware. This study, therefore, demonstrates the IoT-Fog-Explainable ML integration as a novel approach for FFV cold chain temperature prediction. Although the work in Taguta et al. [5] validated this approach in simulation, the present study realises and characterises its deployment on real hardware, including on-device explainability. III. S YSTEM AND M ETHOD A. Architecture The system is fog-centric: all sensing, inference, and explanation occur at the network edge, with no dependence on cloud infrastructure. Sensors transmit to a gateway over an EU868 LoRaWAN link, chosen for its low-power, longrange suitability for periodic environmental sensing [3]. The

gateway forwards uplinks to a single fog node that hosts the LoRaWAN network server, the inference pipeline, and the data store. The end-to-end path is sensors → gateway → fog node (network server → broker → inference pipeline → database), as shown in Fig. 1. Co-locating the network server, inference, and storage on the same node eliminates the need for the internet on the essential route, allowing the system to continue receiving data and predicting during internet failures, while also limiting operating costs to local energy rather than recurrent cloud charges. Fog Node - Raspberry Pi 4 ChirpStack

LoRaWAN End-Devices Synetica enLink ZonePlus (environmental)

(LoRaWAN Network Server)

Fig. 2. Cold room sensor deployment

decoded JSON

UDP

MQTT Broker

LoRaWAN gateway (EU868) LoRaWAN EU868

subscribe

Inference Pipeline (LSGR + conditional SHAP)

Netvox R718E

async write (non-blocking)

(Accel)

fields are identified and skipped, prohibiting predictions based on partial data. The system runs as managed services that start on boot and restart on failure; it therefore returns to a running state without manual intervention after power restoration or process failure, a behaviour examined in Section V-D.

PostgreSQL

B. Inference Pipeline and Conditional Explainability Fig. 1. Fog-based architecture. All inference and explanation run on the fog node; no cloud services are used.

Table I presents a summary of the deployed hardware, while Fig. 2 shows the sensor deployment. The gateway sends uplinks to ChirpStack (version 4.17.0) [20], running on a Raspberry Pi 4 fog node. ChirpStack decodes and publishes them to an Eclipse Message Queuing Telemetry Transport broker 2 [3], [17]. A Python service subscribes, routes each message per device, and sends it to the inference pipeline. Background threads save decoded readings to PostgreSQL 14, ensuring that storage does not interfere with the inference path. TABLE I D EPLOYED HARDWARE .

Component

Device

Role

Fog node Gateway Sensor

Raspberry Pi 4 Kerlink iFemtoCell-evo Synetica enLink ZonePlus (eZone) Netvox R718E

Edge server (full stack) LoRaWAN GW (EU868) Environmental (primary)

Sensor

Vibration / acceleration (secondary)

The sensors communicate individually and asynchronously, with varying transmission patterns that include additional packets on motion events. Inference is event-driven: each valid reading from the environmental sensor updates a bounded rolling buffer and marks the system as ready to predict, and inference is triggered by the subsequent arrival of the vibration sensor’s reading, which typically occurs a few seconds later, at which point the buffered environmental data and the vibration reading are fused into a single feature vector. Incomplete or motion-triggered packets that lack the necessary inference

The predictive model is a stacked LSTM-GRU architecture (LSTM(64) - Dropout(0.5) - BatchNormalization – GRU(50)BatchNormalization – Dense(1)), with both LSTM and GRU using tanh activation and sigmoid recurrent activation, trained using the Adam optimiser (learning rate: 0.0002), batch size of 32, and patience of 25. It was trained offline to predict cold-room temperature at the next timestep, using the dataset and feature-engineering approach described in Taguta et al. [5]. The trained model and feature scaler are loaded once at startup and reused for all predictions, never reloaded per inference. Each inference cycle combines a rolling buffer of recent environmental readings with the latest vibration reading to form the engineered features (lagged, rolling-window, and interaction terms over temperature, humidity, CO2 , and ambient light). The model predicts cold-room temperature at the next sampling interval, giving an observed median prediction horizon of 5 minutes. The predicted temperature is classified against configured thresholds: normal (within −0.5 ◦ C to 1 ◦ C) as required for the South African apples cold room [21], otherwise as a break. Local feature attributions are computed conditionally using SHAP, preferred for robust local model interpretation [16]. SHAP’s GradientExplainer was initialised with a background set of 100 records randomly sampled from the dataset described in Taguta et al. [5]. The explanation was triggered only when a prediction was classified as a temperature break. During normal operation, no attribution is computed, and the explainability subsystem incurs no per-cycle costs. This conditional approach allows for on-device explainability while adhering to resource and latency restrictions. The cost of explanations is only incurred when they are operationally significant.

A. Deployment A Raspberry Pi 4B, 4-core ARM Cortex-A72 with 4GB RAM and 64GB storage, was used as a fog node. The system was deployed in an experimental or controlled Apple cold room in Stellenbosch, maintained at a nominal set-point of approximately −0.5 ◦ C [21], and operated continuously from 25 May 2026. 54 crates of Sundowner apples (≈100 per crate) were held in the cold room until 8 June 2026, when half were moved to a separate room for deviation injection; this study’s sensors moved with them. Temperature breaks, or deviations, were induced to determine the model’s performance under unstable, varying cold chain conditions. For this study, data up to 18 June 2026 (5619 prediction cycles) were utilised. All reported measurements were obtained under live operating conditions. The sensors transmitted at 5-minute intervals. During the deployment, the system experienced 5 key, naturally occurring field failures (battery depletion, power interruption, connectivity loss), which were used to characterise fault tolerance. Python 3.12.3 was used for programming. B. Performance Metrics To determine the energy, latency, and compute resource efficiency of the IoT-Fog-ML integration, the following metrics were used. 1) Latency: Latency was measured at successive pipeline stages from timestamps embedded at each hop. On-device stages are reported: network-server-to-broker (ns to mqqt) (from the server’s receive time to wall-clock arrival, recorded as the first operation in the broker callback) and on-node processing (mqqt to pred) (broker arrival to completed inference), and SHAP latency, all three timed with Python’s perf _counter. mqqt to pred includes inference. 2) Energy: Energy consumption was measured at the supply with an in-line smart-plug meter, recording energy over a representative 5-day period for the complete deployed system (fog node and gateway). Average per-day and per-prediction energy were derived from this total, the latter as total energy divided by the number of predictions over the 5 days. 3) Compute resources: CPU and memory usage were sampled in-process once per inference cycle. Memory is reported as the process resident set size sampled immediately after inference, that is, an instantaneous footprint of the inference pipeline. CPU is reported as average process utilisation over the inter-cycle interval; because it is a duty-cycle average, it reflects the mean load over the operation rather than the instantaneous load during inference. 4) Model Accuracy: The LSGR model’s temperature predictions were evaluated using MAE, MSE (lower is better), and R2 (closer to 1 is better) [7]. Confidence intervals (CI) were obtained by bootstrap resampling (2 000 resamples) V. R ESULTS AND D ISCUSSIONS This section presents the results and discussion of this study, covering energy consumption, latency, compute resource usage, fault tolerance, model accuracy, and explainability.

A. Energy consumption The system drew approximately 8 W on average, consuming about 0.2 kWh per day, equivalent to ≈0.7 Wh per prediction (amortised over 1457 predictions across the 5day window). Total energy is dominated by the always-on hardware rather than by the light, intermittent prediction-andexplanation workload. This footprint, comparable to a lowwattage LED running continuously and far below server- or cloud-based inference, shows that explainable temperature prediction is feasible at very low energy cost on edge hardware. B. Latency decomposition As shown in Fig. 3, the per-stage latencies are consistent across runs, with low standard deviations. The ns to mqqt stage dominates, accounting for almost half of the latency up to inference, indicating that network-server processing and message passing, rather than on-device computation, are the principal costs. On-node processing, including preprocessing and inference of the uncompressed model, takes approximately 283 ms (228 ms for inference); this is modest given that the model runs without compression on edge hardware. When a break is predicted, conditional SHAP adds approximately 195 ms to attribute features. 350 300

272.2 ± 18.2

282.7 ± 16.4

250

Time (ms)

IV. E XPERIMENTAL S ETUP

227.8 ± 13.6 194.7 ± 9.9

200 150 100 50 0

ns_to_mqtt mqtt_to_pred

inference

SHAP

Fig. 3. Decomposed latency.

The system produces a prediction in about 555 ms (excluding the gateway-to-network-server hop). While significant for hard real-time systems, this remains well under one second, a small fraction of the 300 s inter-reading interval, and is therefore near real-time for cold-chain monitoring; even with explanation, the total stays below one second. Notably, the cost of explainability is lower than that of inference, an acceptable price for transparency. The measured sensor-to-prediction latency is substantially higher than the 84.31 ms reported in the simulation study [5]. This reflects the gap between simulation and real deployment: the simulation abstracted execution and data transmission as idealised costs, whereas the hardware realisation incurs their true overheads, which are framework

execution, messaging, and physical LoRaWAN transmission. The discrepancy underscores the value of deployment measurement, as these realities are concealed by abstraction yet dominate real-world latency. C. Compute resources Table II shows that the memory cost of inference is consistently less than 20%. This implies that the Pi 4 has enough memory for temperature prediction tasks using DL models. TABLE II R ESOURCES EFFICIENCY.

Mean Median Q3

CPU util All (%)

CPU util no SHAP (%)

CPU util SHAP (%)

RAM (MiB)

All

1.95 ±0.62 1.70 2.00

1.89 ±0.51 1.70 1.90

2.42 ±1.06 1.90 3.20

727.41 ±6.51 724.90 730.50

The table also shows that CPU usage spiked and was inconsistent, with an average of 1.95%, a third quartile of 2% and a maximum of 10.7%. The CPU burst indicates events which are triggered, and this is confirmed by CPU utilisation without SHAP upon predicting normal temperature (mean: 1.89%), which is consistently low, compared to with SHAP (after break prediction) (mean: 2.42%), marking a 28% CPU usage increase, even with a higher utilisation median. The utilisation spiked due to SHAP computations. This implies that SHAP increases CPU utilisation and is computationally expensive, though the Pi 4 still maintained a low load and handled the computations. Since RAM usage was measured after inference but before SHAP, no significant differences were visible between SHAP and no SHAP cycles. The low CPU utilisation and the Raspberry Pi’s ability to sustain the explainable ML pipeline demonstrate that a single fog node is computationally sufficient for this workload, providing real-world evidence for the feasibility previously found in simulation [5]. CPU utilisation remained low despite inference and explanation taking over 200 ms (Fig. 3). This reflects that the latency is largely attributable to framework and interpreter overhead rather than sustained computation, and that the brief processing burst is averaged out over the longer CPU-sampling window; that is, the workload is latency-bound rather than compute-bound. D. Fault tolerance and resilience Evaluating the system in a real deployment, rather than in simulation, exposes failure modes that arise only under genuine operating conditions. Over 24 operational days, the system experienced 5 interruptions of 1.5 hours or more, totalling 79.1 hours of downtime (no predictions) and corresponding to 86.31% availability; Table III lists each. Most required manual intervention to fix the problem, though the service automatically resumed after the fix. These results characterise reliability without claiming faultfree operation. The system recovered autonomously from

TABLE III FAULT CATEGORIES OBSERVED DURING THE DEPLOYMENT. Cause

Duration

Recovery

Data impact

eZone battery depletion

16.9 h

Manual battery replacement

eZone low

battery

1.5 h

Automatically woke up

Connectivity loss and loss of the external (Internet) link

22.4 h

None required; local operation unaffected

Failure of the Raspberry Pi power cable IP reassignment disrupted the gateway’s packet forwarding.

12 h

Manual replacement

48.7 h

Static IP assigned to the host

Inference halted and automatically resumed Inference halted and automatically resumed Local inference and logging continued; only the remote access was affected Inference paused, then resumed automatically Inference halted, and automatically resumed

infrastructure failures and continued local inference during internet loss, confirming its cloud-independent operation, which is desirable for cold-chain environments where connectivity may be intermittent, while also revealing a sensor-level vulnerability. Reporting both is essential to an honest account of real-world deployment, and the observed failure modes provide design guidance that simulation-based evaluation could not. However, a structural limitation of the deployed design is that inference is triggered by the arrival of the Netvox supplementary readings, creating a single point of failure: if that sensor becomes unavailable, inference halts even if the environmental sensor remains active. Future work will develop a redesigned trigger that proceeds from the environmental sensor and degrades gracefully. E. Explainable Temperature Prediction Predicting one sampling interval ahead, the LSGR model achieved an MAE of 0.1972 ◦ C (95% CI [0.1834, 0.2146]), an MSE of 0.3826 (95% CI [0.1519, 0.6874]), and an R2 of 0.7683 (95% CI [0.5846, 0.8961]) under real-world deployment conditions. The low MAE indicates that predictions track actual temperature closely under typical operation and are highly operationally accurate, while the higher MSE and moderate R2 reflect the model’s difficulty anticipating sharp, genuine spikes in advance, a real-world challenge left to future work. The model exhibits a small positive bias (0.13 ◦ C), tending to slightly over-predict temperature. In cold-chain monitoring, where breaks manifest as rising temperature, this is the fail-safe direction: a model that errs slightly warm is biased toward flagging deviations rather than missing them. This implies the model is generally hot, or biased toward hotter temperature predictions. Fig. 4 shows that humidity and the single temperature lag appeared most frequently in the top three important features, indicating the model relies on them most for break prediction; the prominence of the humidity–temperature interaction suggests their combination is a major contributor. In contrast,

CO2 , ambient light, and acceleration ranked consistently low, contributing little to the model’s predictions over the observed conditions. As the features the model relies on the most, these are the quantities most worth monitoring in operation, offering practical insight into developing deviations regardless of whether they are causal drivers. Establishing their causal role would require dedicated causal analysis and controlled intervention, which is left to future work. Since predictions rely on a small feature subset, these also form a candidate reduced feature set for future model improvement.

Humidity_Temperature_Interaction

96% (μ=5.70)

Humidity

93% (μ=1.93) 63% (μ=1.16)

Temperature_Lagged

36% (μ=2.12)

CO2e Estimate Equivalent

7% (μ=1.57)

CO2e_Lagged Humidity_Lagged

5% (μ=0.52)

Ambient_Light_Trend

0% (μ=5.02)

Temperature_CO2e_Interaction

0% (μ=0.64)

Ambient Light

0% (μ=2.04)

Humidity_CO2e_Interaction

0% (μ=1.73)

Average_Humidity

0% (μ=0.44)

0

25

50

the pipeline achieved high operational accuracy (MAE) but was slightly affected by spikes while running entirely on a fog node, with low energy per prediction, reasonable latency, low resource cost, and on-device explainability at no steadystate overhead. SHAP attributed predictions primarily to past temperature, humidity and their interaction, and the Raspberry Pi 4 proved operationally sufficient for explainable temperature prediction. Beyond these benchmarks, the deployment surfaced realities that simulation cannot: autonomous recovery from infrastructure faults, continued operation through internet connectivity loss, and a single point of failure arising from the sensor-triggered inference design. Future work will redesign the inference trigger so prediction degrades gracefully when a sensor is unavailable, quantify predictive lead time ahead of breaks, explore adaptive learning approaches to improve accuracy, investigate on-device causal inference, and extend evaluation to commercial cold-chain conditions, other models, commodities and cross-device timing. Overall, the study demonstrates that a single fog node can deliver practical, autonomous, near-real-time explainable cold-chain temperature prediction for low-connectivity sites at an affordable cost, with feature attributions identifying which variables warrant closest monitoring and pointing toward future model simplification. R EFERENCES

75

100

125

% of break events (top-3)

Fig. 4. Bar = frequency as top-3 driver; µ = mean |SHAP| when present (n = 631 break events)

F. Limitations of the study Tying predictions to both sensors causes system failure, especially when the Netvox provides only supplementary data. The study also uses a controlled laboratory cold room, which excludes operational routines like regularly loading and removing products. These activities introduce door openings and airflow disruption that increase the variance of coldroom conditions, making the prediction task more demanding than the one evaluated here; performance under commercial handling regimes may differ. Breaks were also induced deliberately rather than arising from equipment or handling faults, so the findings were not obtained under commercial operating conditions. The radio-and-gateway hop was omitted, as differencing gateway and network-server clocks produced some negative values and outliers, indicating clock offset between the two devices. VI. C ONCLUSION & F UTURE W ORK This paper presented the real-world deployment and characterisation of an explainable, fog-based LSGR pipeline for FFV cold-chain temperature prediction, realising on physical hardware a system previously validated only in simulation. Deployed in a real cold room under operational conditions,

[1] “Food Loss and Waste: Facts and Futures,” World Wide Fund for Nature, Tech. Rep., 2017. [2] L. Goedhals-Gerber, E. van Dyk, R. Getor, B. Louw, and N. Mishra, “Identifying container hotspots for table grape exports from South Africa to the UK: A case study,” Transportation Research Interdisciplinary Perspectives, vol. 24, 2024. [Online]. Available: https://www.scopus.com/inward/record.uri?eid= 2-s2.0-85187665990&doi=10.1016%2fj.trip.2024.101054&partnerID= 40&md5=7fd89d769e06e261a711362aa5009660 [3] J. Taguta, J. F. I. Nturambirwe, and C. N. Nyirenda, “Towards IoT-Fog-ML integration for temperature break detection and prediction in fresh produce cold chains: a systematic review and architectural framework,” Frontiers in Artificial Intelligence, vol. Volume 9 2026, 2026. [Online]. Available: https://www.frontiersin.org/journals/ artificial-intelligence/articles/10.3389/frai.2026.1830032 [4] R. Badia-Melis, U. Mc Carthy, L. Ruiz-Garcia, J. Garcia-Hierro, and J. I. Robla Villalba, “New trends in cold chain monitoring applications - A review,” Food Control, vol. 86, pp. 170–182, 2018. [5] J. Taguta, J. F. I. Nturambirwe, and C. N. Nyirenda, “Fog-Based Deep Learning for Real-Time Cold Chain Temperature Prediction Using IoT Data,” in Artificial Intelligence Research, A. Gerber and A. W. Pillay, Eds. Cham: Springer Nature Switzerland, 2026, pp. 287–301. [6] J. L. Vilas-Boas, J. J. Rodrigues, and A. M. Alberti, “Convergence of Distributed Ledger Technologies with Digital Twins, IoT, and AI for fresh food logistics: Challenges and opportunities,” Journal of Industrial Information Integration, vol. 31, p. 100393, Feb. 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/ S2452414X22000607 [7] J. Taguta, J. F. Isingizwe Nturambirwe, and C. N. Nyirenda, “Comparative Evaluation of Machine Learning Models for Predicting Fresh Produce Cold Chain Temperature: A Case of South African Apples,” in 2025 IST-Africa Conference (IST-Africa), May 2025, pp. 1–10, journal Abbreviation: 2025 IST-Africa Conference (IST-Africa). [8] C. F. C. Solutions, “Unleash the power of the Internet of Things,” Cisco Systems Inc, 2015. [9] R. Badia-Melis, J. P. Qian, B. L. Fan, P. Hoyos-Echevarria, L. RuizGarcı́a, and X. T. Yang, “Artificial Neural Networks and Thermal Image for Temperature Prediction in Apples,” Food and Bioprocess Technology, vol. 9, no. 7, pp. 1089–1099, Jul. 2016. [Online]. Available: https://doi.org/10.1007/s11947-016-1700-7

[10] J. Loisel, A. Cornuéjols, O. Laguerre, M. Tardet, D. Cagnon, O. Duchesne de Lamotte, and S. Duret, “Machine learning for temperature prediction in food pallet along a cold chain: Comparison between synthetic and experimental training dataset,” Journal of food engineering, vol. 335, p. 111156, 2022. [11] Y. Zou, J. Wu, X. Wang, K. Morales, G. Liu, and A. Manzardo, “An improved artificial neural network using multi-source data to estimate food temperature during multi-temperature delivery,” Journal of Food Engineering, vol. 351, p. 111518, Aug. 2023. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0260877423001164 [12] M. Ayanoglu and I. Uysal, “ML Approach to Improve the Costs and Reliability of a Wireless Sensor Network,” Sensors, vol. 23, no. 9, 2023. [Online]. Available: https://www.scopus.com/inward/record.uri? eid=2-s2.0-85159164618&doi=10.3390%2fs23094303&partnerID=40& md5=57ff537bb6a44fc1be2736de9e9698c5 [13] H. Ali, K. Rafaqat, A. Teg, B. Rab Nawaz, N. Haitham, K. Amjad Rehman, and Aqsa, “IoT- Enabled Firmness Grades of Tomato in Cold Supply Chain Using Fusion of Whale Optimization Algorithm and Extreme Learning Machine,” IEEE access, vol. 12, pp. 52 744–52 758, 2024. [14] J. Guo, D. Liu, S. Lin, J. Lin, and W. Zhen, “Temperature Prediction of a Temperature-Controlled Container with Cold Energy Storage System Based on Long Short-Term Memory Neural Network,” Applied Sciences (Switzerland), vol. 14, no. 2, 2024. [Online]. Available: https://www.scopus.com/inward/record.uri?eid= 2-s2.0-85192559779&doi=10.3390%2fapp14020854&partnerID=40& md5=9b2662eb2641231bbcb086c28fa1fbbf [15] C. C. Emenike, N. P. Van Eyk, and A. J. Hoffman, “Improving Cold Chain Logistics through RFID temperature sensing and Predictive Modelling,” in 2016 IEEE 19th International Conference on Intelligent Transportation Systems (ITSC), Nov. 2016, pp. 2331–2338, journal Abbreviation: 2016 IEEE 19th International Conference on Intelligent Transportation Systems (ITSC). [16] S. Lundberg and S.-I. Lee, A Unified Approach to Interpreting Model Predictions, Dec. 2017. [17] J. Junjie, P. Cuiling, L. Wenjing, L. Shuangyin, L. Zhijie, and C. Ningxia, “Environmental Prediction in Cold Chain Transportation of Agricultural Products Based on K-Means++ and LSTM Neural Network,” Processes, vol. 11, no. 3, p. 776, 2023. [18] F. M. Ribeiro Junior, R. A. C. Bianchi, R. C. Prati, K. Kolehmainen, J.-P. Soininen, and C. A. Kamienski, “Data reduction based on machine learning algorithms for fog computing in IoT smart agriculture,” Biosystems engineering, vol. 223, pp. 142–158, 2022. [19] Z. Musa and K. Vidyasankar, “A Fog Computing Framework for Blackberry Supply Chain Management,” vol. 113, 2017, pp. 178–185. [Online]. Available: https://www.scopus.com/inward/record.uri?eid= 2-s2.0-85033489056&doi=10.1016%2fj.procs.2017.08.338&partnerID= 40&md5=61cfee5872c600a3e1856811305c38c0 [20] O. Brocaar, “ChirpStack: Open-source LoRaWAN network server,” https://github.com/chirpstack/chirpstack, accessed: 2026-05-01. [21] A. Botes, A. Infruitec-Nietvoorbij, and J. van der Merwe, CA Manual Revised, ser. Recommendations for the Storage of Pears and Apples, 2019.

Record · ID 919370 · SHA-256 92c1089b4cb4e1bd
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.