Available online at www.sciencedirect.

com
Available online at www.sciencedirect.com
Available online at www.sciencedirect.com

ScienceDirect
Procedia Computer Science 00 (2019) 000–000
Procedia
Procedia Computer
Computer Science
Science 22000 (2019)
(2023) 000–000
584–591 www.elsevier.com/locate/procedia
www.elsevier.com/locate/procedia

The 6th International Conference on Emerging Data and Industry (EDI40),

The 6th International Conference
March on Emerging
15-17, 2023, Leuven, Data and Industry (EDI40),
Belgium
March 15-17, 2023, Leuven, Belgium
A
A Distributed
Distributed Data
Data Mesh
Mesh Paradigm
Paradigm for
for an
an Event-based
Event-based Smart
Smart
Communities Monitoring Product
Communities Monitoring Product
Worapol Alex Pongpechaa
Worapol Alex Pongpech
a NIDA, Seri Thai Rd, Bangkok and 10110, Thailand
a NIDA, Seri Thai Rd, Bangkok and 10110, Thailand

Abstract
Abstract
The recent pandemic events in Thailand, Covid-19 in 2018, demonstrated the need for an event-based smart monitoring system.
The
Whilerecent pandemicmulti-level
a distributed events in architecture
Thailand, Covid-19 in 2018,
has emerged demonstrated
as an architecture the need for
of choice forana event-based smart event-based
larger-scale smart monitoring system.
system
While a distributed multi-level architecture has emerged as an architecture of choice for a larger-scale smart event-based
that requires better latency, security, scalability, and reliability, a recently introduced data mesh paradigm can add a few additional system
that requires
benefits. The better latency,
paradigm security,
enables each scalability, and reliability,
district to become a recently
an event-based introduced
smart data mesh
monitoring mesh and
paradigm
handlecanits add a few and
analytics additional
moni-
benefits. The paradigm
toring workload. enables
Districts eacha set
can form district to become
of domains in a an event-based
network smart monitoring
of event-based mesh andmonitoring
smart community handle its systems
analyticsand
andprovide
moni-
toring workload. Districts can form a set of domains in a network of event-based smart community monitoring
data products for others during a crisis. This paper presents a distributed data mesh paradigm for an event-based smart monitoringsystems and provide
data products
product for others
in a given duringwith
community a crisis. This paper
predefined presents
domains. Thea paper
distributed datasmart
presents meshmonitoring
paradigm for as aandata
event-based smart monitoring
product between domains.
product
Key considerations for designing an event-based smart monitoring data product are given. The author introduces threedomains.
in a given community with predefined domains. The paper presents smart monitoring as a data product between possible
Key considerations
domains necessary forforcreating
designing an event-based
a smart monitoringsmart
system monitoring data product
in each community. aredomain
Each given. The author
creates introduces
a data product forthree possible
a given do-
domains
main andnecessary
shares dataforbetween
creatingdomains.
a smart monitoring system in analytics
Finally, a three-layer each community. Eachfor
architecture domain
a smartcreates a data product
monitoring product inforeach
a given do-
domain
main
and a and
use shares
case is data between domains. Finally, a three-layer analytics architecture for a smart monitoring product in each domain
presented.
and a use case is presented.
© 2023
© 2020 The
The Authors.
Authors. Published
Published by
by Elsevier
Elsevier B.V.
B.V.
© 2020 The Authors. Published by Elsevier B.V.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
(https://creativecommons.org/licenses/by-nc-nd/4.0)
This is an open
Peer-review access
under
under article under
responsibility
responsibility thescientific
ofofthe
the CC BY-NC-ND
Conference license
committee
Program the(http://creativecommons.org/licenses/by-nc-nd/4.0/)
of Chairs.
Conference Program Chairs
Peer-review under responsibility of the Conference Program Chairs.
Keywords: cloud computing; data mesh; data-driven architecture; domain concept;edge computing; event-based analytic; fog computing; IoT ;
Keywords: cloudMonitoring
Real-time; Smart computing; data mesh; data-driven architecture; domain concept;edge computing; event-based analytic; fog computing; IoT ;
Real-time; Smart Monitoring

1. Introduction
1. Introduction
A smart system is a system capable of independent actions based on a set of predefined rules triggered by the
A smart
incoming system
events i.e.isdata.
a system capable
The system of independent
ingested data fromactions
variousbased on a setboth
data sources, of predefined rulesbatch
real-time and triggered by and
sources, the
incoming events i.e. data. The system ingested data from various data sources, both real-time and batch sources, and
computed it according to a set of predefined rules. The system computes the data and carries out predefined activities
computed it according to a set of predefined rules. The system computes the data and carries out predefined activities

∗ Corresponding author. Tel.: +085-919-9090

∗ Corresponding
E-mail address:author. Tel.: +085-919-9090
worapol.pon@nida.ac.th
E-mail address: worapol.pon@nida.ac.th

1877-0509 © 2020 The Authors. Published by Elsevier B.V.

1877-0509 © 2020
This is an open Thearticle
access Authors. Published
under by Elsevier B.V.
the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
1877-0509
This © 2023
is an open Thearticle
access Authors. Published
under by Elsevier B.V.
the Conference
CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/)
Peer-review
This is an under
open responsibility
access article of the
under the CC Program
BY-NC-ND Chairs.
license (https://creativecommons.org/licenses/by-nc-nd/4.0)
Peer-review under responsibility of the Conference Program Chairs.
Peer-review under responsibility of the scientific committee of the Conference Program Chairs
10.1016/j.procs.2023.03.074
 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591 585
2 W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000

corresponding to the rules. An event-based smart monitoring system is a smart system designed to monitor and alert
accordingly to a set of predefined rules.
An example of a crisis that could benefit from an event-based smart monitoring system is the Covid-19 epidemic,
first reported from Wuhan, China, on 31 December 2019. The Thais government implemented several centralized
monitoring systems. So far, most people complained that these systems did not monitor potentially infected popula-
tions fast enough and questioned the data sources’ legitimacy. The most important function of any event-based smart
monitoring system is to provide the public with accurate, relevant, and trustworthy information during crises and in a
timely manner.
Analytic latency, security, reliability, and scaling issues have pushed most smart systems designs toward a dis-
tributed multi-layer architecture. Scaling each layer, horizontally and vertically, is more economical, more practical,
and provides more flexibility in the future. The multi-layer architecture helps remove any single source of failure in
the analytics system. While a distributed multi-layer architecture provides these benefits, it presents more complex
data management than a centralized architecture.
Some of the biggest problems of Thailand’s smart monitoring system during the 2018 Covid-19 crisis in Thailand
is its inability to provide accurate detection and quick warnings to the public. Additionally, the provided information to
the public does not cover all of the districts. There are fifty districts in Bangkok, but the system can only monitor and
alert less than half of them in Bangkok. Furthermore, the system was heavily centralized, and the locals in each district
were not sufficiently involved in the alerting and monitoring process. Clearly, scaling is one of the main problems with
Thailand’s current smart monitoring system.
From this past crisis, we have also learned that events are local in a community and asynchronous, where not all
events are similar. Subject matter experts in each community will have to determine whether the events are critical
or not. These characters present complex data management in the analytical process of the system. Instead of having
a monolith multi-layer architecture, a new paradigm where the analytical processes are distributed to the computing
unit nearest to the data source would be more efficient and reduce the load of the main computing unit. Instead of
having everything stored at the central data lake and computing and alerting through the main monitoring center, each
community should have its smart monitoring and alerting center. Each center will compute and ingest more relevant
and closer data sources to the community instead of sending all the data to be computed at the main center.
An event-based smart monitoring system can be modeled as a group of functionalities or activities where a data
product results from these activities. A recently introduced data management paradigm, data mesh, offers a more ef-
fective approach for involving communities in creating these data products. The analytics process is closer to the data
sources with the data mesh paradigm, thus minimizing latency. The subject matter experts in the communities are bet-
ter utilized and more involved with the analytic process. Each community can monitor and alert the community based
on predefined rules created by the community. Additionally, each community can offer this alerting and monitoring as
a data product to the others.
This paper presents distributed data mesh paradigm considerations for an event-based smart monitoring product.
The paper presents smart monitoring as a set of data products from each domain in a community. Then give key
considerations for designing an event-based smart monitoring data product. The author discusses functions and tasks
for a domain when creating a data product. Finally, a three-layer architecture for a smart monitoring product in each
domain and a use case is presented.
The paper is organized as follows. Section 2 presents an overview of data mesh and smart monitoring systems.
Section 3 presents the proposed data mesh paradigm for an event-based smart monitoring product. Finally, section 4
closes with a conclusion and future works.

2. Overview

This section presents relevant works in the area of smart monitoring systems and in the data mesh. The section
begins with a smart monitoring system and concludes with relevant works on the data mesh.
586 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591
W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000 3

2.1. On Smart Monitoring System

In the last few years, there have been a number of research on smart monitoring utilizing sensors and IoT devices
for better water management. Goncalves and friends [2] presented an IoT-Based Framework for Smart Water Supply
Systems Management. Olivier and colleagues [7] presented the IoT Sensing Platform as a Driver for Digital Farming
in Rural Africa. Singh and Ahmen [12] presented a systematic review of IoT-based smart water management systems.
Given the real case of security breaches in the Florida water management system in early, the recent work by Salam
[10] on the security aspect of the Internet of Things in Water Management and Treatment is very relevant. Most of
these works demonstrated the growing trends in using IoT and sensor devices in water management systems.
We found some work on utilizing edge-to-cloud computing for IoT-based systems. Mohan and colleagues [6]
presented work on Edge-Fog Cloud for the internet of things computation is a good example of utilizing the archi-
tecture. Robberechts and colleagues [8], a Novel Edge-to-Cloud-as-a-Service (E2CaaS) Model for Building Software
Services, is focusing on using the architecture for Smart Cities applications. Sinaeepourfard and colleagues[11] pre-
sented work on a big data management architecture for smart cities based on fog-to-cloud data management architec-
ture. Hassan et al. [3] provided a clear, detailed discussion on the role of edge computing in the Internet of Things. He
also presented a well-thought-out taxonomy of IoT-based Edge environments, which we have extended for Fog and
Cloud environments in this paper.

2.2. Data Mesh

As defined by Zhamak Dehghani [1], a data mesh is a type of data platform architecture that embraces the ubiquity
of data in the enterprise by leveraging a domain-oriented, self-serve design. It focuses on domain-driven design cor-
responding business domain. Given that the paradigm has just been introduced recently, there are only a few works in
data mesh.
Strengholt’s book [13] on data management at scale discussed the paradigm in great detail with a strong use case
for managing data at scale. Sahni et al. [9] work is also related to data mesh but in a more infrastructure layer.
He introduced Edge Mesh which aims to provide many benefits, including distributed processing, low latency, fault
tolerance, better scalability, better security, and privacy. Machado et al. [4] proposed a domain model and a conceptual
architecture for the achievement of decentralized data architectures, which is based heavily on the data mesh concept.
Machado et al. [5] also presented additional work on data mesh in 2022, focusing on the motivation for the appearance
of the Data Mesh paradigm, its features, and approaches for its implementation.

2.2.1. Data Mesh Principles

Data Mesh builds on top of four principles given as follows.

1. Domain-oriented, decentralized data ownership, and architecture, meaning that organizational/business functions
need to own their data.
2. Data as a product and to expose the domain’s products in a form that is usable to others.
3. Data infrastructure as a platform that offers different capabilities in a self-service manner.
4. Federated computational governance, balancing the act of having just enough centralized control to ease the work
but keeping the decision-making as local as possible.

2.2.2. Data Mesh Topology

There are several approaches in designing a data mesh topology [13] as given in the figure below.

1. Governed mesh topology allows the different data domains to be grouped and represented as nodes. Each node
is a domain, which can represent itself as either a data provider and/or data consumer towards the other domains.
2. Harmonized mesh topology allows nodes to operate more on their own. Data distribution goes point-to-point but
is governed at the same time. The central data hub allows domains to operate their own platforms whilst adhering
to common policies and standards.
 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591 587
4 W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000

Fig. 1. Data Mesh Topology

3. Highly federated mesh topology allows each domain to implement its own stack of technologies in different
environments. This results in greater flexibility for special domains, experiments, or domains that require fast
time to market.

3. A Data Mesh Paradigm for an Event-based Smart Community Monitoring System

The Covid-19 crisis demonstrated the ineffectiveness of the centralized smart monitoring system implemented in
Thailand, showcasing the high latency and the inability to scale up to meet the rapid scale-up of consumers. The author
also observed that the data sources are highly scattered, and no one knows who the data owner is. Data processing
and alerting were also slow and ineffective as all the data must be processed in the central hub, and alerting are only
through the central hub.
In this paper, the author employs a data mesh paradigm as a fundamental architecture for designing an event-based
smart community monitoring system. The data mesh paradigm enables a more effective and distributed approach to
building data products. The paradigm also facilitates scaling both technologically and organizationally more effec-
tively that the centralized paradigm, such as the data lake.
The data mesh paradigm allows communities to build smart community smart monitoring data products by them-
selves. The author does not discuss the smart aspect of the system as such aspects will be left for each community to
decide. The data mesh topology proposed in this research is the hybrid mesh federation illustrated in Figure 1. This
would allow each community to implement its stack of technologies while still connecting with the central hub, which
is already been implemented in Thailand. The central hub can also act as the self-serve data infrastructure platform
for the data mesh.
In this section, the author introduces the logical architecture of data mesh under the scope of the smart monitoring
system as illustrated in Figure 2 where the self-serve data infrastructure is also acted as the central hub of the data
mesh.
Each community can play a more active role in building an event-based smart monitoring system with the data
mesh paradigm and creating a data product based on the needs of their community. The data can be sourced locally,
processed, and analyzed with the local subject matter experts and create timely and customized data products for the
community. This data product can be quickly consumed and scaled up to meet the community’s needs.
A community is directly mapped onto a data mesh network and is responsible for producing and maintaining a
smart monitoring system. Under the data mesh paradigm, a smart monitoring system can compose a set of domains
where the data is ingested from IoT devices or other domains inside or outside the community through a self-serve
data infrastructure platform.
Each domain will be able to deploy a functionally, cohesively, and autonomously data product. All the necessary
infrastructure, code, data, and metadata should be readily available for every domain. Thus each domain/community
588 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591
W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000 5

Fig. 2. Data Mesh Domain and Self-serve Platform

Fig. 3. Stakeholders Fig. 4. Domain Interface

is fully responsible for its data and products. The five main stakeholders in each domain as illustrated in Figure 3 are
given as follows.

a) The data mesh self-serve data infrastructure platform team. The team is responsible for creating infrastructure,
data analytics, building the dashboard, and the API requested by the domains.
b) The subject matter experts (SME). It is impossible to determine smart actions without the proper context from
the subject matter experts. Each domain could have a different group of SMEs as needed for events that must be
monitored and alerted on the data product.
c) The public in the community consumes the data product and provides feedback to the data team.
d) A data product developer is a group of developers in a domain that helps create data products. Data scientists,
software developers, and Data engineers usually reside in this group.
e) The data product owner is responsible for data governance of the domain’s data and data product.

3.1. Domain

The core of the data mesh paradigm builds upon the concept of domain-driven. A domain is defined as a sphere
of knowledge or activity. The author proposes three possible domains in a smart monitoring community system the
detection domain, the alerting domain, and the ER domain, as illustrated in Figure 2.

a) Detection domain The main data products of the detection domain involve detecting predefined events from the
ingesting data, such as an out-of-boundary event. Producing these products involved ingesting and processing
data from IoT devices. The product usually is in the form of analytical data that other domains need to create
their data product, such as the warning and ER data products.
b) Alerting Domain The Alerting Domain creates all the relevant data products involving alerting and warning
services for the community. People in the community can consume these data products via API from the domain.
The products use operational or analytic data from other domains, such as the detection domain.
 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591 589
6 W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000

Fig. 5. Self-serve Data Infrastructure Platform Fig. 6. Multi-layer Architecture

c) ER Domain The ER Domain provides data products that involve various healthcare services necessary for ev-
eryone in the community during the crisis. The alerting domain can also consume the operational and analytical
data produced from the ER domain.

3.2. Domain Interface

It is crucial that domains must be able to interact with others. The two interfaces available are the analytics, and
operational interface, as illustrated in Figure 4.

a) The analytics data interface allows a domain to share analytical data with others. The interface also provides
an API for discovering and observing data products. The data infrastructure platform maintains this interface,
and it is the interface where data products and analytical data can be shared between domains.
b) the operational interface APIs enable a domain to share its transactional capabilities and state with the commu-
nities. This interface is maintained jointly by the data owners and the data infrastructure platform. The interface
allows transactional data produced in a domain to be shared with the others so other domains can use this data to
produce data products or analytical data that can be shared via the analytics data interface.

3.3. Self-serve Data Infrastructure Platform

The goal of a self-serve data infrastructure platform illustrated in Figure 5 is to provide essential data infrastructure
capabilities such as storage, processing, searching, and cataloging for each domain. The self-serve concept is similar
to the services provided by all cloud providers. Each domain will be assigned a project account where the domain
can utilize all of the available infrastructures through the given project. The platform allows the domains to build,
share, and use data products throughout the life cycle and will be able to keep track of all the infrastructure to the
individual project account. The platform allows each domain to accomplish these tasks separately and autonomously.
The author proposes a self-serve data infrastructure platform composed of three-layer distributed infrastructure layers,
as illustrated in Figure 6.

1) The Edge Computing layer is the outermost layer of the platform. It allows the IoT and sensor devices to serve
data to the domains and brings computation and data storage closer to the data source for improving response
times and saving bandwidth. A domain can utilize this layer to create data products with the lowest latency, such
as event detection.
2) The Fog Computing layer is the middle layer of the platform, residing between the edge layer and the main layer.
It provides domains with bigger computation powers to transform data from other domains, both analytics and
operational.
590 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591
W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000 7

3) The Cloud Computing layer is the innermost layer of the platform. It is located furthest from the data sources and
facilitates data exchange from the Edge and Fog layers for a domain. It possesses all the efficiency and flexibility
of distributed computing, such as scalability, tool selections, data storage options, and monitoring and alerting.

3.4. Data Product

A data product is a product that facilitates an end goal through the use of data. A data product has an input and
output port connected to the operational and analytical interfaces.
The input port is connected to the self-serve data infrastructure platform. The IoT data can be ingested through
a streaming data-pipeline infrastructure. If the data product requires analytical data or operational data from other
domains, it can also be ingested from the platform. The output port is also connected to the self-serve data platform
to deliver operational and analytical data to the other domains.
In emergency events, the life and well-being of businesses can depend heavily on information provided by smart
monitoring products. There are a set of attributes that must be considered carefully when designing a smart monitoring
product. We have adopted some of these from the edge computing taxonomy [3]. These attributes are given as follows.

1) Accuracy: A smart monitoring data product must provide accurate information.

2) Latency Smart monitoring data product needs to respond in real-time at the event or near-real-time.
3) Accessible: General consumers must be able to access the data product.
4) Scalable: A smart monitoring data product must be able to scale accordingly.
5) Flexible: A smart monitoring data product must be flexible in providing relevant information to consumers.
6) Reliability A smart monitoring data product must be reliable to the consumers.
7) Security A smart monitoring data product must be secure and not provide a backdoor for hackers.

3.5. A Use Case

One of Thailand’s most requested applications during the Covid-19 is a Covid-19 contract tracking application.
An event-based smart monitoring product based on the data mesh paradigm is an effective mechanism for creating a
Covid-19 tracker application.
Each community is treated as a group of connected domains on the data mesh where each domain can have a
different infrastructure for creating data products. The other communities or the public can also consume these data
products via secure API through the platform.
Every domain needs three main functions from the self-serve data infrastructure platform to build a data product.
These are a common set of architectural characteristics that the design of all data products share.

1) Serving Components Ingesting components are classified into batch ingestion and real-time ingestion compo-
nents. The batch ingestion components mainly respond to those intermediate and prolonged functions. The
real-time ingestion components respond mostly to immediate functions. Their main objective is to move the
fast-flowing data to the processing units with the lowest latency possible. The author proposes Apache Kafka as
the main component for handling real-time ingestion and Apache Sqoop as the batch ingestion component for
the system.
2) Consume Components There are two types of data in the system: structured and unstructured data. The author
proposes HDFS, which is already part of the Hadoop cluster, as the main storage for the Fog Layer, and Object
storage, such as Amazon S3, as the main storage for the Cloud layer.
3) Transform Components Processing in the multi-layer smart water management begins in the edge layer. Data
from sensor devices are sent to a Raspberry Pi 4 Model B cluster, a 1.5 GHz 64-bit quad-core ARM Cortex-A72
processor 802.11ac Wi-Fi to perform immediate functions such as threshold computing for alerting applications.

In this use case, there are two possible types of data products in each district, one is a data product, and the other
is data as a product. Each community will have three domains working collaboratively: the detection domain, the
warning domain, and the ER domain.
 Worapol Alex Pongpech et al. / Procedia Computer Science 220 (2023) 584–591 591
8 W.A. Pongpech / Procedia Computer Science 00 (2019) 000–000

The detection domain is tasked with tracking the spreading of Covid-19. The data must be ingested from outside
the domain through the self-serve data infrastructure platform. The tracking data is available through the health de-
partment. Once the detection domain receives the data, it can quickly compute whether the infected patients are in the
community.
The warning domain takes the data as a product from the detection domain and creates a data product as a dash-
board, which illustrates the spreading of infected patients in the community. The dashboard can show the location of
the infected patient. It can also show the increase or decrease of the infected patient in the community. The warning
domain can also create analytical data as a product to be consumed by the ER domain.
The ER domain consumes data as a product of the detection and warning domains. The analytical data from the
warning domain allows the ER domain to plan a more effective healthcare strategy for the community. The ER domain
can create a data product connecting the patients to the available healthcare services in the community and acting as a
healthcare agent for the community during a crisis.

4. Conclusions

Smart monitoring systems are being utilized increasingly in many countries to help manage emergency events.
However, designing such a system is a complex task. Such a system must handle modern data’s volume, variety, and
velocity. To facilitate designing such a smart system for these emergency events, the author presented a data mesh
paradigm for an event-based smart community monitoring system. The paper presents a data mesh concept used in
conjunction with a multi-layer architecture to provide a more effective mechanism for creating data products than a
single-layer architecture. A discussion on smart monitoring as a data product is given to the five stakeholders in a
domain. The author introduces the three main domains needed for building a data mesh event-based smart monitoring
system. The paper also provides key considerations for designing a smart monitoring data product that each domain
should consider. The paper is concluded with the self-serve data infrastructure platform necessary for creating a data
product, and a use case is also presented.

References

[1] Dehghani, Z., 2022. Data Mesh. O’Reilly Media. URL: https://books.google.co.th/books?id=GOnzDwAAQBAJ.
[2] Gonçalves, R., J. M. Soares, J., M. F. Lima, R., 2020. An iot-based framework for smart water supply systems management. Future Internet
12. URL: https://www.mdpi.com/1999-5903/12/7/114, doi:10.3390/fi12070114.
[3] Hassan, N., Gillani, S., Ahmed, E., Yaqoob, I., Imran, M., 2018. The role of edge computing in internet of things. IEEE Communications
Magazine 56, 110–115. doi:10.1109/MCOM.2018.1700906.
[4] Machado, I., Costa, C., Santos, M.Y., 2021. Data-driven information systems: The data mesh paradigm shift .
[5] Machado, I.A., Costa, C., Santos, M.Y., 2022. Data mesh: Concepts and principles of a paradigm shift in data architectures. Procedia
Computer Science 196, 263–271. URL: https://www.sciencedirect.com/science/article/pii/S1877050921022365, doi:https:
//doi.org/10.1016/j.procs.2021.12.013. international Conference on ENTERprise Information Systems / ProjMAN - International
Conference on Project MANagement / HCist - International Conference on Health and Social Care Information Systems and Technologies
2021.
[6] Mohan, N., Kangasharju, J., 2016. Edge-fog cloud: A distributed cloud for internet of things computations, in: 2016 Cloudification of the
Internet of Things (CIoT), pp. 1–6. doi:10.1109/CIOT.2016.7872914.
[7] Oliveira-Jr, A., Resende, C., Pereira, A., Madureira, P., Gonçalves, J., Moutinho, R., Soares, F., Moreira, W., 2020. Iot sensing platform as a
driver for digital farming in rural africa. Sensors 20. URL: https://www.mdpi.com/1424-8220/20/12/3511, doi:10.3390/s20123511.
[8] Robberechts, J., Sinaeepourfard, A., Goethals, T., Volckaert, B., 2020. A novel edge-to-cloud-as-a-service (e2caas) model for building software
services in smart cities, in: 2020 21st IEEE International Conference on Mobile Data Management (MDM), pp. 365–370. doi:10.1109/
MDM48529.2020.00079.
[9] Sahni, Y., Cao, J., Zhang, S., Yang, L., 2017. Edge mesh: A new paradigm to enable distributed intelligence in internet of things. IEEE Access
5, 16441–16458. doi:10.1109/ACCESS.2017.2739804.
[10] Salam, A., 2020. Internet of Things in Water Management and Treatment. Springer International Publishing, Cham. pp. 273–298. URL:
https://doi.org/10.1007/978-3-030-35291-2_9, doi:10.1007/978-3-030-35291-2_9.
[11] Sinaeepourfard, A., Krogstie, J., Petersen, S., 2018. A big data management architecture for smart cities based on fog-to-cloud data manage-
ment architecture.
[12] Singh, M., Ahmed, S., 2020. Iot based smart water management systems: A systematic review. Materials Today: Proceedings URL: https://
www.sciencedirect.com/science/article/pii/S2214785320364701, doi:https://doi.org/10.1016/j.matpr.2020.08.588.
[13] Strengholt, P., 2020. Data Management at Scale. O’Reilly Media. URL: https://books.google.co.th/books?id=GOnzDwAAQBAJ.