# Ensuring Reliability in Smart Building IoT Operations
Through Real-Time Holistic Data Treatment

Aliki Stefanopoulou, Asimina Dimara, Iakovos Michailidis, Georgios Karatzinis, Alexios Papaioannou, Stelios Krinidis, Christos-Nikolaos

Anagnostopoulos, Elias Kosmatopoulos, Dimosthenis Ioannidis, Dimitrios Tzovaras

<figure><img src="image_1.png" /></figure>

## ► To cite this version:

Aliki Stefanopoulou, Asimina Dimara, Iakovos Michailidis, Georgios Karatzinis, Alexios Papaioannou, et al.. Ensuring Reliability in Smart Building IoT Operations Through Real-Time Holistic Data Treatment. 19th IFIP International Conference on Artificial Intelligence Applications and Innovations (AIAI), Jun 2023, León, Spain. pp.207-218, 10.1007/978-3-031-34171-7_16. hal-05417768

HAL Id: hal-05417768

https://inria.hal.science/hal-05417768v1

Submitted on 15 Dec 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_3.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Ensuring Reliability in Smart Building IoT
Operations Through Real-Time Holistic
Data Treatment

Aliki Stefanopoulou<sup>1,2</sup>, Asimina Dimara<sup>1,3(✉)</sup>, Iakovos Michailidis<sup>1,2</sup>, Georgios Karatzinis<sup>1,2</sup>, Alexios Papaioannou<sup>1,4</sup>, Stelios Krinidis<sup>1,4</sup>, Christos-Nikolaos Anagnostopoulos<sup>3</sup>, Elias Kosmatopoulos<sup>1,2</sup>, Dimosthenis Ioannidis<sup>1</sup>, and Dimitrios Tzovaras<sup>1</sup>

**Abstract.** Efficient smartification in buildings pre-requires highly reliable data. Modern AI applications consider real-time emergent responsiveness, which renders control safety of outmost importance. A number of sensors and other devices are installed that retrieve data on energy consumption, indoor conditions, and other information. By analyzing this data, smart home devices are able to customise user experiences while optimizing energy use while enhancing security in a real-time manner. In this paper, a holistic data treatment framework for Smart Building IoT applications is presented. The proposed framework considers a multi-factorial anomaly detection and treatment. The implemented functional filtering pipeline consists of statistical filtering rules for detecting, recognizing and mitigating the most common anomalies observed in the historical data. First a methodology for estimating missing data values based on available data is considered. Moreover, an outlier detection and healing mechanism is also integrated to improve the accuracy and reliability of the analysed results. The results showcase that the clean data are of better quality for further exploitation.

**Keywords:** Data treatment · Data healing · Data filtering · AI
Operational Safety · Real-time data reliability

## 1 Introduction

Smart homes are equipped with a plethora of sensors and devices that gather information about users' behaviour, energy consumption, indoor and outdoor

<footnote n="1"><sup>1</sup> Centre for Research and Technology Hellas (CERTH), Information Technologies Institute (ITI), Thessaloniki, Greece
{alikstef,adimara,michaild,gkaratzi,alexiopa,krinidis,kosmatop,djoannid, Dimitrios.Tzovaras}@iti.gr</footnote>

<footnote n="2"><sup>2</sup> Department of Electrical and Computer Engineering, Automatic Control Systems and Robotics, Democritus University of Thrace (DUTh), Xanthi, Greece</footnote>

<footnote n="3"><sup>3</sup> Department of Cultural Technology and Communication, Intelligent Systems Lab, University of the Aegean (UoA), Mytilene, Greece
canag@aegean.gr</footnote>

<footnote n="4"><sup>4</sup> Management Science and Technology Department, International Hellenic University (IHU), Kavala, Greece</footnote>
environmental conditions and others. As a result, the potential of optimizing and understanding their operation through big data analysis is tremendous [1]. Smart building systems leverage the available amount of historical data to optimize energy use, and improve security while offering customized user experience by evaluating this data [2]. Smart home systems enable real-time operations management, especially during emerging phenomena, by regulating controllable settings in order to offer more personalized user satisfaction by gathering information on residents' preferences, habits, and actions [3]. Overall, big data has immense potential for smart home applications, and as the Internet of Things (IoT) technology develops further, more sophisticated big data exploitation in this field is anticipated.

Pushing sensorial data streams in IoT networks can be difficult for a variety of reasons, such as:

- Constraints due to Security: To save energy and reduce costs, IoT devices frequently use low-power highly-secure wireless technologies like Bluetooth, Zwave or Zigbee. Due to the inherent bandwidth limitations of these technologies, it might be difficult to send huge data streams to cloud servers or other devices [4].

- Handling Big-Data: Network congestion may occur in centralized IoT networks as a result of multiple devices attempting to push data streams at once. Delays, packet loss, and other problems may result from this, which may reduce the network's dependability [4].

- High latency for Real-time Control applications: High bandwidth is frequently needed for IoT applications to ensure prompt answers, especially when close-to real-time control frequency is employed. Pushing sensor data streams to cloud servers or other devices, however, might cause large latencies, especially if the network is busy or the devices are spread out far away [5].

- IoT device power limitations: Since many IoT devices rely on batteries or other low-power energy sources for power, this can restrict the amount of data streams they can push. Data transmission can use a lot of power, especially if the device is far from the closest access point or gateway [5].

Additionally, utilizing raw sensory data to extract reliable insights and provide data-intensive services may cause various issues that arise when operating with unprocessed or unstructured data deriving from the IoT applications [6]. Likewise, raw data collected directly by IoT devices may contain errors, duplicates or even large gaps. This can lead to inaccurate analysis and decision-making if the data is not cleaned, healed or corrected before the analysis process. IoT devices generate data in different formats, semantics and structures, making it challenging to integrate and analyze the data effectively [7]. This can require significant effort to normalize the data before it can be analyzed. This can overwhelm storage and processing resources and make it challenging to analyze the data in a timely and cost-effective manner. Finally, IoT data is often generated in real-time and at high speeds, which can make it challenging to store and process the data quickly enough to support real-time analysis and decision-making [6].
Additionally, environmental sensors rely on a reliable and stable network connection to transmit data. If the network is down or has low signal strength, the data transmission may be interrupted or delayed [8]. Environmental sensors need a stable power source to operate correctly. If the battery or power supply is running low, the sensor may not transmit data for a long period of time as required or may provide inaccurate readings [9]. Data corruption can occur during data transmission, especially when using wireless transmission methods. This can be due to various factors such as network interference, weak signals, or incompatible protocols.

Within this context, in this paper a holistic data treatment framework in Smart IoT Monitoring is suggested. A set of guidelines and procedures that outline how to manage and analyze data in a structured and systematic way is followed. It is a series of steps that helps to ensure that the data is reliable, consistent, and valid, and can be used for artificial intelligence models. The procedure includes removing errors, inconsistencies, and duplicates. This task also includes tasks such as data validation and data transformation. Moreover, a technique is involved to estimate missing data values based on the available data. Eventually, there are data points that are significantly different from other data points in the dataset, and they can have a significant impact on the analysis results. In the suggested pipeline an outlier healing is performed to identify and deal with these points while improving the accuracy and reliability of the analysis results.

The remainder of the paper is structured as follows: Sect. 2 addresses the methodology followed for data treatment. In Sect. 3, the type of problems that are detected in raw data streams are described. Section 4 presents the followed mitigation mechanisms that were implemented while Sect. 5 summarizes the key findings and their significance.

## 2 Data Treatment

Gathering and organizing unprocessed measured information can be challenging and typically involves several redundancies before it's ultimately stored in the central database. The process of obtaining measurement data involves multiple stages, such as triggering digital sensory equipment, interacting with local gateway brokers, harmonizing data points locally, and transmitting the received data-message to the designated database entity through the cloud server middleware platform. Each of these stages requires distinct devices and local firmware to manage data-messages locally. However, filtered data and cleansed datasets may increase the performance of data-intensive models and mechanisms for forecasting and situation assessment. Data cleansing is an integral part of the pre-processing level, considered of great importance before start trusting the information extracted from this same data.
As expected, the data collected from a deployed digital infrastructure (i.e., sensory equipment at the pilot sites (various countries)), may be found prune to such anomalies. After the preliminary evaluation process results, specific types of anomalies are observed in the measured time series, which render the implementation of filtering rules necessary. The implemented functional filtering pipeline, consists of statistical filtering rules for detecting, recognizing and mitigating the most common anomalies observed in the historical data, as illustrated in Fig. 1.

<figure><img src="image_4.png" /><figcaption>Fig. 1. Data-Filtering pipeline</figcaption></figure>

## 2.1 Data Granularity

A sampling frequency of the sensory equipment at least equal to 5 min will result in retrieving detailed data and enable the representation of physical metrics that present almost equivalent inertia. In specific, physical metrics like indoor temperature, humidity, CO₂ saturation can be adequately represented based on a 5-minute sampling frequency even when the existing HVAC devices are fully operating (and apparently affecting their evolution through time). In addition, the inertia of metrics like energy consumption and illuminance levels are mostly affected by the control cycle frequency, which is usually set to 15 min, rendering 5-min sampling adequate once more.
# 3 Types of Anomalies Observed/Detected

## 3.1 Duplicate Data

Duplicate records are a frequent problem in centralized data management platforms, which can cause a variety of issues. In such platforms, data from multiple sources is collected, processed, and stored in a central database, making it easier to access and analyze. However, as data is collected from different sources, it is possible that the same data may be recorded multiple times, resulting in duplicate records. In the context of centralized data management platforms, duplicate records can lead to several problems. Firstly, redundant data can increase the size of the database and make it more challenging to manage. This can result in slower performance and increased storage costs, as well as difficulties in ensuring data accuracy. Moreover, duplicate records can cause data inconsistencies, leading to faulty overlaps and duplicated timestamps for the same physical metric. For instance, suppose data from two sources is recorded with slightly different timestamps, but they refer to the same physical event. In that case, duplicate records may lead to confusion about which data is accurate and which data should be discarded. This, in turn, can lead to inaccurate analysis and incorrect conclusions, which can have far-reaching consequences. Therefore, it is essential to have proper mechanisms in place to identify and remove duplicate records from the database. This can involve implementing unique identifiers for each data point, establishing data validation rules, or using automated tools to identify and remove duplicates. By doing so, centralized data management platforms can ensure data accuracy, improve performance, and prevent potential issues resulting from duplicate records.

## 3.2 Missing Data

There is a plethora of sensors and there exist various communication protocols and various types of sensors even of the same protocol. Each sensor reports data in a different way. Specifically, there are event-based sensors that report data when the monitored event changes status or at a predefined time interval (e.g., motion sensor reports a value every 5 min or in between if the status of the monitored room changes from absence to presence and vice versa). There are triggered-based sensors that report a value only when the status of the reported value changes, otherwise, they report nothing (i.e., door window sensor sends a value when the state of the window changes from open to close and vice versa).

Other sensors are value-based and report their state if the current value is ± a default value (e.g., a temperature sensor sends temperature only if the current temperature is ± 0.02 than the previous value). Other sensors are time-based and they report a value every time interval that is set by default (e.g., an illuminance sensor reports a value every 1 min). Finally, there are constant sensors that report data constantly (i.e., energy analyser reports a value non-stop). As a result, when pushing data at a pre-defined time interval (e.g., 5 min for the monitoring) some values will be missing, as the sensor is asleep (e.g., no-event, no status change, no
trigger). Furthermore, there are technical issues that prevent a sensor from sending data (e.g., poor WiFi signal, no sensor battery).

## 3.3 Outliers

Outliers are extreme values that deviate significantly from the average or typical values in a dataset. In a timeseries, outliers can occur due to various reasons, such as measurement errors, data corruption, or unusual events. These outliers can have a significant impact on data analysis, as they can skew the overall trends and patterns in the timeseries. Therefore, it is important to identify and handle outliers appropriately. Extraordinary data, not-following the same underlying pattern with the other data-points of the same timeseries and context, were also observed in our case, fortunately with low density, after the aforementioned two detection layers. Following up the mitigated duplicates and missing data replacement, a statistical rule for detecting the outlier data was implemented based on the rolling average of a well-defined time-window in the past. To detect low density outliers the following filtering rule, which depends on the quality of the recent past values, could be applied. In specific, to detect if a sample $s_t$ at the $t^{th}$ timestep is an outlier, the implemented filter uses the past $h = 20$ samples of every physical metric respectively $S_h = s_{t-k}|k = 1, 2, ..., h$. Equation 1 is used to calculate the rolling average value of the specific timeseries.

$$ \mu_h = E[S_h] = \frac{1}{h} \sum_{k=1}^{h} s_{t-k} \qquad (1) $$

From the same subset the standard deviation is also calculated as presented in Eq. 2.

$$ var_h = \frac{1}{h} \sum_{k=1}^{h} (\mu_h - s_{t-k})^2 \qquad (2) $$

Finally, based on the calculations above, it is possible to define two threshold levels which decide if the $s_t$ sample is an outlier. In particular, if $|s_t - \mu_h| \ge 2var_h$ then $s_t$ is considered an outlier, as represented in Fig. 2, and its contribution will be omitted from the rolling average and variance calculations for its successor values (future values of the same timeseries).

# 4 Mitigation Mechanisms Implemented

## 4.1 Missing Data

As mentioned above, when trying to retrieve sensor data during a specific time interval there might be some missing values. The same occurs even if data were saved locally (e.g., at .csv format file, .json file format, local database). Consequently, specific guidelines have been established for both real-time and historical data to address this issue. Initially, a value that is not reported from any type
<figure><img src="image_5.png" /><figcaption>Fig. 2. Indicative indoor temperature outlier detection rule.</figcaption></figure>

of the existing monitoring sensors and devises was selected to be posted when there is not a reporting value and cannot be somehow retrieved from the past (e.g., last temperature value was 3 d ago), this value was set equal to "-999". As a result, a value equal to "-999" at the retrieved Gateway .json automatically indicates that the sensor is currently operating normally but it did not report any data now and recently. If this problem insists for a long period for the same sensor, it indicates that there is a problem either with the sensor or with its default specifications and needs to be checked.

Furthermore, a value was selected to indicate that if there is no reporting value and the sensor is dead (not operating), this value was set equal to "None". Nonetheless, for all the missing values different missing data handling was followed for the historical and real time data based on the type of the sensor. Specifically, for the historical data, as the values are saved as time series, specific imputation and machine learning techniques were followed. Initially, the frequency was resampled [10] for all the saved values based on the biggest existing time interval. For example, if there were historical temperature values every half an hour, all data sets were resampled to a half an hour interval. Afterwards, the methodology followed was based on the monitored value.

For each day in the data sample, for temperature and humidity, if the missing values were less than 10% of the total daily, data interpolation and extrapolation was applied for the missing values [11]; else, "-999" was posted. For illuminance and motion detection, gaps were replaced with previous value if the gaps were more than 10% of the total daily data; else, "-999" was posted. For all energy qualities the gaps were replaced with "-999". For the real time data, a buffer was used on the local Gateway to keep past values. Therefore, if the sensor was properly operating but did not report a value for the last 2h, the saved past
value is posted. If the sensor does not report a value more than two hours, "-999" is posted. If the sensor is not operating then "None" is posted. Generally, for real time data there are no missing values posted except if there is a problem with the sensor or the network itself. All the above are summarized in Tables 1 and 2.

<table><caption>**Table 1.** Summary of methods utilized per variable for historical data</caption><thead><tr><td>Variable</td><td>Missing values handling</td></tr></thead><tbody><tr><td>Temperature</td><td>Interpolation and extrapolation</td></tr><tr><td>Humidity</td><td>Interpolation and extrapolation</td></tr><tr><td>Illuminance</td><td>Fill none with previous value</td></tr><tr><td>CO2</td><td>-999</td></tr><tr><td>Motion detection</td><td>Fill none with previous value</td></tr><tr><td>Energy meters</td><td>-999</td></tr><tr><td>Smart plugs</td><td>-999</td></tr></tbody></table>

<table><caption>**Table 2.** Summary of methods utilized per variable for real-time data</caption><thead><tr><td>Variable</td><td>Missing values handling</td></tr></thead><tbody><tr><td>Temperature</td><td><ul><li>Post previous value (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>Humidity</td><td><ul><li>Post previous value (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>Illuminance</td><td><ul><li>Post previous value (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>CO2</td><td><ul><li>Post previous value (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>Motion detection</td><td><ul><li>Post previous value (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>Energy meters</td><td><ul><li>-999 (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr><tr><td>Smart plugs</td><td><ul><li>-999 (sensor is alive)</li><li>None (sensor is not communicating)</li></ul></td></tr></tbody></table>

## 4.2 Outliers

For the mitigation of the missing values in the datasets, a Neural Network (NN) with a Gated Recurrent Unit (GRU) [13] was utilized. The Gated Recurrent Unit is an advancement of the simple Recurrent Neural Network. To solve the vanishing gradient problem of a standard feed forward Recurrent Neural Network,
Gated Recurrent Units make use of an update gate and reset gate. These gates are two vectors which decide what information should be passed to the output. What's special about them is that they can be trained to keep information from long ago, without washing it through time or removing information which is irrelevant to the prediction [12]. The key distinction between simple Recurrent Neural Networks and Gated Recurrent Units is that the latter supports gating of the hidden state. This means that there are dedicated mechanisms for when a hidden state should be updated and when it should be reset. For instance, if the first token is of great importance the network learns not to update the hidden state after the first observation. Likewise, the network learns to skip irrelevant temporary observations. Lastly, it learns to reset the latest state whenever needed [12]. A Gated Recurrent Unit, at each timestamp *t*, takes an input $X_t$ and the hidden state $H_{t-1}$ from the previous timestamp $t-1$. Later it outputs a new hidden state $H_t$ which is again passed to the next timestamp.

To train the GRU models, the filtered historical and monitoring data from each pilot were utilized. Specifically, three models were created for each pilot, with each model designed to heal a particular data type. The models were trained using a set of features, which are as follows:

<table><caption>**Table 3.** Training results</caption><thead><tr><th>Model</th><th>Mean Squared Error</th><th>Mean Absolute Error</th></tr></thead><tbody><tr><td>Greece Indoor Temperature</td><td>0.015</td><td>0.0301</td></tr><tr><td>Greece Indoor Relative Humidity</td><td>0.0021</td><td>0.0350</td></tr><tr><td>Greece Indoor Carbon Dioxide</td><td>0.000176</td><td>0.0048</td></tr><tr><td>Germany Indoor Temperature</td><td>0.0030</td><td>0.0421</td></tr><tr><td>Germany Indoor Relative Humidity</td><td>0.0106</td><td>0.0816</td></tr><tr><td>Germany Indoor Carbon Dioxide</td><td>0.0011</td><td>0.0097</td></tr><tr><td>England Indoor Temperature</td><td>0.0012</td><td>0.0248</td></tr><tr><td>England Indoor Relative Humidity</td><td>0.0032</td><td>0.0488</td></tr><tr><td>England Indoor Carbon Dioxide</td><td>0.0021</td><td>0.0423</td></tr><tr><td>Spain Indoor Temperature</td><td>5.211E-12</td><td>1.84E-06</td></tr><tr><td>Spain Indoor Carbon Dioxide</td><td>0.005</td><td>0.0341</td></tr><tr><td>Spain Indoor Relative Humidity</td><td>0.0023</td><td>0.0075</td></tr></tbody></table>
- ("Indoor Temperature [C]", "Year", "Month", "Day", "Hour", "Minutes", "weekday"), for the training of the Indoor Temperature imputation models,

- ("Indoor Relative Humidity [%]", "Year", "Month", "Day", "Hour", "Minutes", "weekday"), for the training of the Indoor Relative Humidity Imputation models,

<figure><img src="image_6.png" /><figcaption>Fig. 3. Healed Carbon Dioxide data for the Greek pilot.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Fig. 4. Healed Indoor Relative Humidity data for the Greek pilot.</figcaption></figure>
<figure><img src="image_8.png" /><figcaption>Fig. 5. Healed Indoor Temperature data for the Greek pilot.</figcaption></figure>

- ("Carbon Dioxide [ppm]", "Year", "Month", "Day", "Hour", "Minutes", "weekday"), for the training of the Carbon Dioxide Imputation models.

All the previously mentioned models utilized a lookback period of 100 samples and 5 lagged values. This resulted in the input layer having a shape of (None, 100, 12). The second layer added to the models was an Encoder Bidirectional GRU Layer, which had a “tanh” activation function. Following that, the third layer added to the models was a Repeat Vector Layer. The fourth layer was a Decoder Bidirectional GRU Layer, which also had a “tanh” activation function. Finally, the output layer was a Time Distributed Dense Layer with a “linear” activation function. During training, the “adam” optimizer was used, and the loss function was “mean squared error”. The models were trained for 20 epochs. The accuracy of the trained models is summarized in Table 3.

The imputation results for all the pilot sites are depicted in Figs. 3, 4 and 5.

# 5 Conclusions

In summary, raw data generated by IoT devices can be challenging to work with due to various issues such as errors, duplicates, and inconsistencies. To address these challenges, a holistic data treatment framework is proposed for Smart IoT Monitoring. The suggested pipeline includes removing errors, inconsistencies, and duplicates, as well as data validation and transformation. Missing data values can be estimated using available data, and outlier healing techniques can be used to identify and deal with data points that are significantly different from other data points in the dataset. By following these procedures, the accuracy and reliability of analysis results can be improved, and decision-making can be supported with more confidence.
**Acknowledgements.** This work is partially supported by the PRECEPT project funded by the European Union's Horizon 2020 under Grant Agreement No. 958284 https://www.precept-project.eu/ and the SMART2B https://smart2b-project.eu/ project funded by the European Union's Horizon 2020 under Grant Agreement 101023666.

## References

1. Qolomany, B., et al.: Leveraging machine learning and big data for smart buildings: a comprehensive survey. IEEE Access **7**, 90316–90356 (2019)

2. King, J.: Energy impacts of smart home technologies. Report A1801 (2018)

3. Dimara, A., et al.: NRG4-U: a novel home energy management system for a unique loadprofile. Energy Sources, Part A: Recovery, Utilization Environ. Effects **44**(1), 353–378 (2022)

4. Zhao, X., et al.: Reliable IoT storage: minimizing bandwidth use in storage without newcomer nodes. IEEE Commun. Lett. **22**(7), 1462–1465 (2018)

5. Hiller, J., et al.: Secure low latency communication for constrained industrial IoT scenarios. In: 2018 IEEE 43rd Conference on Local Computer Networks (LCN). IEEE (2018)

6. Sadeeq, M.M., et al.: IoT and Cloud computing issues, challenges and opportunities: a review. Qubahan Acad. J. **1**(2), 1–7 (2021)

7. Krishnamurthi, R., et al.: An overview of IoT sensor data processing, fusion, and analysis techniques. Sensors **20**(21), 6076 (2020)

8. Dimara, A., et al.: Self-healing of semantically interoperable smart and prescriptive edge devices in IoT. Appl. Sci. **12**(22), 11650 (2022)

9. Almusaylim, Z.A., Zaman, N.: A review on smart home present state and challenges: linked to context-awareness internet of things (IoT). Wireless Netw. **25**, 3193–3204 (2019)

10. Liu, S., Yuan, Y., Yu, J., She, D., Wang, K.: On-the-fly interpolation of continuous temperature-dependent thermal neutron scattering data in RMC code. In: EPJ Web of Conferences, EDP Sciences, vol. 247 (2021)

11. One Click LCA Ltd., «One Click LCA,» [En línea]. Available: https://www.oneclicklca.com/

12. Dey, R., Salem, F.M.: Gate-variants of Gated Recurrent Unit (GRU) neural networks. In: 2017 IEEE 60th International Midwest Symposium on Circuits and Systems (MWSCAS), Boston, MA, USA, 2017, pp. 1597–1600. https://doi.org/10.1109/MWSCAS.2017.8053243

13. Li, C., Xiao, F., Fan, Y.: An approach to state of charge estimation of lithium-ion batteries based on recurrent neural networks with gated recurrent unit. Energies **12**(9), 1592 (2019)