# A data-flow oriented software architecture for heterogeneous marine data
streams

Keila Lima1, Ngoc-Thanh Nguyen1, Rogardt Heldal1, Lars Michael Kristensen1,
Tosin Daniel Oyetoyan1, Patrizio Pelliccione4, Eric Knauss3 1Western Norway
University of Applied Sciences, Norway
3Chalmers $|$ University of Gothenburg, Sweden
4Gran Sasso Science Institute, Italy

###### Abstract

Marine in-situ data is collected by sensors mounted on fixed or mobile systems
deployed into the ocean. This type of data is crucial both for the ocean
industries and public authorities, e.g., for monitoring and forecasting the
state of marine ecosystems and/or climate changes. Various public
organizations have collected, managed, and openly shared in-situ marine data
in the past decade. Recently, initiatives like the Ocean Decade Corporate Data
Group have incentivized the sharing of marine data of public interest from
private companies aiding in ocean management. However, there is no clear
understanding of the impact of data quality in the engineering of systems, as
well as on how to manage and exploit the collected data.

In this paper, we propose main architectural decisions and a data flow-
oriented component and connector view for marine in-situ data streams. Our
results are based on a longitudinal empirical software engineering process,
and driven by knowledge extracted from the experts in the marine domain from
public and private organizations, and challenges identified in the literature.
The proposed software architecture is instantiated and exemplified in a
prototype implementation.

###### Index Terms:

architecture, architectural decisions, IoT

##  I Introduction

Marine in-situ data is crucial for industries operating at sea in sectors and
domains such as oil and gas, fish farming and aquaculture, wind farms, and
shipping. Moreover, for public authorities, this type of data is crucial for
monitoring and forecasting the state of marine ecosystems, as well as climate
change. In these domains, marine in-situ data is collected by sensors for leak
detection or other environmental monitoring such as temperature or pH, and
integrity monitoring of sub-sea structures. The infrastructures and sensor
systems deployed into the ocean provide (near) real-time data streams. Due to
their high associated deployment and maintenance costs, they must operate for
weeks and up to years without intervention.

An emerging technological trend for the communication connectivity of ocean-
deployed sensors is the Internet-of-Underwater-Things (IoUT) [ref14]. Data
flow from IoUT to end-user applications can be decomposed into three layers:
(i) data acquisition - via the underwater sensors; (ii) networking and
communication - for routing data from Underwater Wireless Sensor Networks
(UWSNs) to IP networks; and (iii) data management - for delivering data to
end-user applications. These layers can also be represented from a data actor
viewpoint by data producers, data service providers, and data consumer sub-
systems operated by different organizations [ref13].

However, IoUT systems present challenges related to the marine environment,
e.g., rough sea conditions, limited sensor battery capacity, and constrained
communication bandwidth. More specifically, in our context, we consider non-
mobile nodes and acoustics for wireless underwater communication inside the
UWSN. Underwater acoustic communication (UAC) has low bandwidth, high
propagation delay, and high bit error rate, especially with horizontal
communication, as the signals are prone to distortions and can be affected by
water conditions. Therefore, the assessment of data quality is a design
concern for IoUT data-driven applications and services. The lack of
understanding of data quality in systems may lead to analytics based on
inadequate data by automated and AI-based systems [10188681]. This in turn may
result in sub-optimal or poor decision-making, and previous studies have
discussed the need to investigate the impact of data quality on the design of
machine learning and AI-dependent systems [9609199, kuwajima2020engineering].
Moreover, the European Union (EU) has made significant efforts towards
regulating the usage of low-quality data in applications that could
potentially impede citizens’ rights. The regulatory framework proposal on
artificial
intelligence111https://ec.europa.eu/newsroom/dae/redirection/document/75788
aims to ensure that high-risk AI systems adhere to these standards to
establish their trustworthiness.

The dependence of these complex and intelligent marine systems on IoUT data
requires substantial knowledge on their resulting architecture. This is
crucial to understand the end-to-end data quality requirements, trade-offs,
and the design of the different layers, the behavior of associated components,
and their interactions. However, currently there is no clear understanding of
the impact of data quality in the engineering of systems, as well as on how to
manage and exploit the collected data.

This paperpresents a data flow-oriented software architecture developed in an
R&D setting that involves stakeholders with different data-related roles
within the marine domain. The component and connector view of the architecture
and associated decisions result from a two-year work that incorporates
knowledge from the literature and stakeholders’ needs and goals. The
architecture Our long-term research process results are based on the domain’s
specific expertise and literature, driven by data quality. Despite the domain-
specific approach, data quality is a critical aspect of software systems with
the increasing incorporation of data analytics tools. Thus, implications,
requirements, and architecture to address them need to be studied. With this
aim, we analyzed software and data quality requirements throughout the data
flow, proposing a set of architectural decisions. These have been incorporated
into the architecture and have been instantiated and exemplified on a
prototype implementation. The ambition of this paper is to aid practitioners
in the marine domain in making informed decisions when architecting their
systems.

##  II Research methodology

Our study is motivated by a real-world need for a software architecture
accommodating wireless smart ocean observation systems (hereafter, referred to
as System). We follow the Design Science approach [hevner2010design] to
conceive and design the architectural decisions (Section IV) and the software
architecture for System (Section V), addressing our identified need.

###  II-A Context

The research context plays a crucial role in Design Science
[petersen2009context]. Our study involves 16 marine organizations that
collaborate to build System, as detailed in Table I (gray rows indicate
software-related stakeholders). System accommodates representative use cases
within ocean industries covering aquaculture, environmental monitoring, and
energy. The stakeholders play different data-related roles in building System:

TABLE I: Organizations involved in building System ID |  Size |  Profile |  Role
---|---|---|---
|  (emp.) |  |
1 |  $<$250 |  Producer of oceanographic sensors and supplier of sensory services |  P, S, C
2 |  $>$250 |  Research institute on technology development for sensors and decision support |  C
3 |  $>$250 |  Underwater communication and marine robotics manufacturer |  P, S
4 |  $>$250 |  Defence research and development institute |  P, S
5 |  – |  Marine industry cluster to foster technology synergies in the sector |  I
6 |  $>$250 |  Oil exploration and petroleum resources development company |  C
7 |  $<$250 |  Oceanographic sensors manufacturer and sensor services provider |  P, S
8 |  $<$250 |  Manufacturer of underwater communication systems and monitoring services provider |  P, S
9 |  $>$250 |  IT and digital solutions consultancy |  S, C
10 |  – |  Innovation industry cluster to foster national and international R&D cooperation |  I
11 |  $<$250 |  Research institute focus in marine, cryospheric and atmospheric studies |  P, S, C
12 |  $>$250 |  Subsea systems development, operation, and consultancy |  P, S
13 |  $>$250 |  Marine research institute |  P, S, C
14 |  $<$250 |  Offshore telecommunications carrier |  S
15 |  – |  Cluster of research institutes, governmental bodies, companies related to seafood industry |  I
16 |  $<$250 |  Subsea inspection systems development and operation |  P, S

  * •

Data Producers (Role P): organizations responsible for developing and
integrating underwater sensors into Underwater Wireless Sensor Networks
(UWSNs).

  * •

Data Service Providers (Role S): organizations providing services for
transmitting, processing, or sharing data in underwater and onshore
environments.

  * •

Data Consumers (Role C): organizations consuming data produced by System for
data analytics purposes. They provide crucial requirements for building an
architecture that can be parameterized for specific use cases.

  * •

Industry Clusters (Role I): clusters of organizations that are responsible for
knowledge and technology transfer between research and the industrial settings
to support innovation of System but do not directly involve its development.

###  II-B Research process

Figure 1 depicts the relevance, rigor, and design cycles following the Design
Science research approach [hevner2010design].

Figure 1: Research process with: a) depicting the relevance cycle; and b)
illustrating the rigour cycle and solution design process

Relevance cycle: Figure 1a illustrates how we, the architect team, ensure that
the produced artifacts are relevant to the needs of the stakeholders listed in
Table I. The relevance cycle of this study started in January 2022. Each team
member worked individually and the whole team gathered for 2 hours every week,
for status updates and to discuss issues encountered while producing the
artifacts. We also organized 2-hour monthly workshops with the software-
related stakeholders. These workshops aimed to elicit the software
requirements, determine the architecture to be developed, identify necessary
architectural decisions, and validate our ongoing efforts. The artifacts were
presented in 2-day bi-annual workshops bringing together all stakeholders of
the project together. The primary aim of the bi-annual workshops was to ensure
the alignment of all the software architecture’s components of System,
including underwater data acquisition, network communication, and software
technologies.

Rigor and Design cycles: Figure 1b shows the cycles of rigor and design. Our
initial exploratory studies [ref14, ref13, ref15] on building System and the
associated literature surveys served as starting point for this stage of the
research process. We took into account the challenges presented in the
literature (Section III), and existing software technologies (Section IV and
V). Those findings resulted in decisions and a software architecture for
System (Sections IV and V). A prototype implementation of the software
architecture was made to validate and adjust the decisions accordingly.
Details of our previous studies and the software components can be found in
our companion package [replication_package].

###  II-C Threats to validity

####  II-C1 Construct Validity

Since the gathered challenges from the literature were a pivotal point in our
research methodology, we do not claim to have identified all the existing
challenges for data-driven systems that process marine in-situ data in
realtime. We focus on the ones that our architectural decisions address in the
intersection of our design cycle, the rigor cycle outcomes, and the relevance
cycle inputs and validation. While the authors gained domain knowledge,
gathering papers in the literature diminished until the understanding of the
challenge reached a saturation point. Furthermore, to analyze the challenges,
we use standardized quality models, which were extended by inserting minimal
changes (two additional quality attributes) supported by the literature.

####  II-C2 Internal Validity

To reduce the threat of misinterpretation of the identified challenges, we
used views from different reference papers from literature collected over the
research period. To validate the rationale behind the challenges, they were
discussed several times with the stakeholders in the activities held in the
relevance cycle (see Figure 1a). We proposed an architecture that reflects the
decisions whose rationale incorporates existing challenges from different
studies, technological solutions, and stakeholders’ domain expertise.
Furthermore, we do not limit the validation of the resulting architecture to
the stakeholders’ interaction chain; we also integrate feedback from the
prototype technical implementation process. The integration and prototyping
processes only started when sufficient knowledge of the domain was acquired to
ensure that as many factors as possible were taken into consideration in the
solution-seeking stage.

####  II-C3 External Validity

The research process focused on requirements for a set of heterogeneous data-
driven use cases within the marine domain. Our resulting flexible and
parameterized architecture is a reflection of this. Consequently, in contexts
that share similar challenges as those described throughout Section III, the
related architectural decisions can be suitable for similar systems. Lastly,
the architectural decisions entail some limitations, and their usage in other
contexts has to be analyzed carefully to ensure the quality of the resulting
architecture.

####  II-C4 Reliability

To improve the reliability of the study, we provide the documents from which
Tables II and III were extracted. As for the resulting architecture, we also
provide the initial draft upon which new knowledge has been integrated between
the many iterations over our relevance, design and rigor cycles (Section II).
Because of intellectual property rights (IPR) constraints and the cross-
organizational context, the source code of the end-to-end prototype
implementation cannot be provided. Runtime excerpts of the system’s operation
is provided. All this data is available in the companion package of the study
in [replication_package].

##  III Challenges

The system behavior is highly dependent on data quality, and our aim is to
analyze an architecture from the point of view of its heterogeneous data
flows. We have therefore analyzed the gathered challenges using the quality
attributes for software and data products from the ISO/IEC 25010 [iso25010]
and the ISO/IEC 25012 [iso25012_2] quality models, respectively. We introduced
two additional quality attributes on the quality model in order to accommodate
challenges not captured by ISO/IEC 25010 and ISO/IEC 25012: Energy efficiency
as suggested in [bass2003software] and Explainability from [9609199,
habibullah2023non].

The energy efficiency quality attribute is identified across different studies
[bass2003software, VENTERS2018174, koccak2015integrating] as a characteristic
to be considered when evaluating of software systems as it contributes to the
software sustainability. Although the ISO/IEC 25010 [iso25010] encompasses a
resource utilization sub-characteristic under performance efficiency quality
attributes, these usually refer to computational resources (e.g. CPU, storage,
and network usage). This can be ambiguous if energy is perceived as a resource
because it is a trade-off to the computational resources. Explainability has
emerged as a quality attribute associated with machine learning and other AI-
based components due to their “black box” characteristics. It is often
associated with the quality of data used by such systems since its runtime
behavior depends on data [9609199], which in turn influences the decision-
making process of these systems.

Below we discuss 15 of the identified challenges from the perspective of the
software and the data quality attributes. The challenges and their impacted
software and data quality attributes of System are summarized in Table II.

TABLE II: Software architecture relevant challenges on stationary wireless
marine observing systems

ID | Challenge | Layer |  Quality of Software Product Impacted | Quality of Data Product Impacted | References
---|---|---|---|---|---
Inherent | System-dependent/Both
CH1 | Limited battery |  Underwater Data Acquisition | Reliability (availability) |  | Accuracy,
---
Credibility,
Completeness
Recoverability | [ref2, ref3, ref5, ref11, ref13, ref14]
CH2 | Physical vulnerability | Reliability (availability) |  | Accuracy,
---
Credibility,
Completeness
Recoverability | [ref3, ref4, ref5, ref7, ref8, ref11, ref14]
CH3 | Lack of device output format standards |  | Compatibility
---
(Interoperability)
| Credibility,
---
Completeness,
Consistency
| Compliance
---
Portability
| [ref3, ref5, ref7]
---
[ref14, ref15]
CH4 | Unreliable UAC links |  | Reliability (Fault
---
Tolerance)
| Credibility,
---
Completeness
Recoverability |  | [ref2, ref4, ref5, ref7]
---
[ref9, ref10, ref11, ref14]
CH5 | Missing raw data |  Network Communication | Explainability* |  | Credibility,
---
Completeness
Understandability | [ref13, ref14]
CH6 | Environmental impact of UAC |  | Performance efficiency
---
(resource utilization)
| Credibility,
---
Completeness
N/A | [ref1, ref5, ref14]
CH7 |  | Low communication bandwidth and
---
high latency of UAC and OTA links
| Performance efficiency
---
(capacity)
| Credibility,
---
Currentness
N/A | [ref6, ref13, ref14, ref16]
CH8 | Security vulnerability of UAC links | Security | Credibility |  | Availability,
---
Confidentiality
| [ref3, ref6, ref11, ref12]
---
[ref14, ref19]
CH9 | Power-hungry UAC data transmission | Energy efficiency* | Credibility | Recoverability | [ref3, ref10, ref14]
CH10 | Complex data usage |  Data Management |  | Usability (Appropriateness
---
recognizability)
N/A | Understandability | [ref13, ref14, ref15]
CH11 | Lack of automatic QC procedures | N/A | All | All | [ref13, ref14, ref15, ref17]
CH12 | Heterogeneous data sources |  | Compatibility
---
(Interoperability)
| Credibility,
---
Completeness,
Consistency
| Compliance
---
Portability
[ref13, ref15, ref18]
CH13 |  | Sensitive data
---
(Business and Defense critical)
Security | N/A |  | Availability,
---
Confidentiality
[ref13, ref15]
CH14 | Data reusability | (Re)usability | N/A |  | Availability,
---
Confidentiality
[ref13, ref14, ref15]
CH15 | Access control for data sharing | Security | N/A |  | Availability,
---
Confidentiality
[ref13, ref15]

  * •

* – New adopted QA $|$ Abbreviations: UAC (Underwater Acoustic Communication); OTA (Over-The-Air); N/A (Not Applicable).

###  III-A Compatibility

Compatibility of System is affected in the underwater data acquisition layer
because of the sensor integration. It implies that heterogeneous communication
protocols and associated output data formats need to be unified at the UWSN
level to ensure a common syntax and semantics within data producers’ sub-
systems (CH3). It affects also the data management layer as the originating
dataset from the integration of measurements from different sensors is
supplied by data producers’ sub-systems in various formats. Additionally,
there might be different types of data, such as time series, images, or
videos, which are categorized into point-based and array-based data [ref15].
At the cloud service level, where multiple data sources are merged,
interoperability is required to ensure that the different processing
components interpret data based on the same metrics and criteria (CH12). When
data has proprietary or organization-dependent syntax and semantics, its
compliance to standards and portability, i.e., “degree to which data has
attributes that enable it to be installed, replaced or moved from one system
to another” [iso25012], can be affected.

###  III-B Explainability and Usability

Because of the low bandwidth and high propagation delay of UAC at the UWSN
level, there is an aggregation or local processing of data to filter important
information or events, which will be sent up the data delivery chain. The raw
data is often kept for retransmission and can be retrieved during recovery or
maintenance of the sensing platforms at sea. Despite that, storage might also
be an issue when operating over a long time. Since the raw data records can be
crucial for data analytics tasks, their absence can have implications in the
understandability of data and the explainability of automatically detected
phenomena or actions performed based on the data (CH5). Lack of metadata,
which can provide information regarding the required data quality inherent
dimensions hindering its adequate use for a specific context, is another
challenge affecting understandability (CH10). These challenges impact the
usability, and more specifically the ability to “recognize whether a product
or system is appropriate for their needs” [iso25010]. Also, a lack of
explainability of current procedures makes it difficult to fully automate data
quality control procedures (CH11). Because of the high complexity of data,
such activities currently require domain experts’ intervention and usually
cause delays of up to six months. This makes the process subjective and
strongly dependent on the experience of the person in charge. Since marine
data is prone to errors due to the uncertainty of the environment and to
technological constraints, existing procedures often focus on assessing the
inherent characteristics of data. Still, it is of high importance to perform
data quality control before employing the data further considering the quality
dimensions required for its context of use.

###  III-C Recoverability

The Recoverability data quality attribute, i.e., “the degree to which data has
attributes that enable it to maintain and preserve a specified level of
operations and quality, even in the event of failure” [iso25012], is impacted
by challenges affecting reliability, performance efficiency, and energy
efficiency software quality attributes. Regarding performance efficiency
(resource utilization), then the noise generated by the communication device’s
signals can negatively impact species that use acoustics to communicate or
prey, e.g., by leading them to confusion or causing other changes in the
behavior (CH6). Because of the impact of the underwater acoustic signals on
marine life, there could be restrictions on the transmission windows and
frequencies. This challenge has implications on the communication channels and
links utilization.

Furthermore, in the network communication layer, wireless communication
channels in IoUT have less available bandwidth per packet transmission (CH7)
compared to traditional land-based channels. This is the case for the
acoustics in underwater communications and in satellite over-the-air
communication (OTA), where latency can vary according to atmospheric or water
conditions (e.g. affected by absorption). Lastly, the OTA options (satellite
and mobile networks) to transmit data into IP networks usually have higher
costs associated with the carrier service. These challenges constrain the
overall network performance efficiency capacity of IoUT software systems.

When it comes to reliability at the underwater data acquisition layer, the
only power source for underwater equipment is the battery. Its limited
resource lifetime can vary from few weeks to years depending on the data
sampling rate, the precision of instruments, and the power consumption of the
transmission device (CH9). This last factor is due to the higher consumption
of energy associated with transmission devices when compared to computation
done locally. Thus, energy efficiency is one of the main drivers of the
overall system. Additionally, at the UWSN level, underwater sensors,
communication modems, and gateways are vulnerable to physical impacts. For
example, equipments can be damaged by human activities (e.g., hit by ships) or
by nature (e.g., dragged by sea waves, currents, or ice). This can affect
sensor measurements, device integrity and their resulting data quality.

In summary, while the physical vulnerability (CH2) of the hardware and the
limited battery (CH1) affects the availability of the software system (its
operation), the unreliability associated with the wireless underwater network
links (CH4) impacts the capacity of the software system to operate in the
presence of faults in the communication channel.

###  III-D Security

When it comes to security at the network communication layer, UAC is
susceptible to a range of attacks (CH8) including packet capture, routing
attacks, and blockage of a link between nodes (DoS) due to the accessibility
to the wireless channel. Authentication and detection strategies can be
implemented to mitigate the open UAC communication channel and spoofing of
sensor nodes. However, implementing land-based network security methods in
this context is not trivial due to the communication overhead underwater,
especially when there are many nodes in the network. A detailed description of
the types of attacks and their mitigation can be found in [ref19]. At the data
management layer, two interrelated challenges impact security in terms of
confidentiality and rightful access to data being shared: (i) the access to
data being collected needs to be carefully filtered in terms of its category
(CH15); and (ii) data categorization and filtering are motivated by data
sharing beyond the initial context in which it was acquired (CH14). Some
reasons behind this are regulations, better forecast and safety measures on
organizations’ operations areas, or adhering to initiatives to provide data
for climate and marine sciences for better public perception. In summary, the
data to be shared could be categorized into (CH13) legally restricted,
business-critical, or open-access data. An example of legally restricted data
is data that is critical for the maritime territory defence because it details
the bathymetry of a specific region at the sea, or stock market data. Open-
access data refers to “non-footprint” data valuable to a third-party entity or
to new applications, which requires resources to be shared. In terms of data-
related quality attributes, these challenges impacts data availability, i.e.
“the degree to which data has attributes that ensure that it is only
accessible and interpretable by authorized users” [iso25012]; and
confidentiality, which is defined as “The degree to which data has attributes
that enable it to be retrieved by authorized users and/or applications”
[iso25012].

###  III-E Data Product Inherent Quality Attributes Impacted

##### Accuracy

This quality attribute is impacted by all challenges that affect the sensor
measurements, deviating the measurements from the observed phenomena aimed to
be captured. For example, bio-fouling concerns microorganisms growing around
underwater sensors. It is an unavoidable problem for artificial objects
operating in the ocean. When a sensor is subject to this problem, it may
produce inaccurate measurements, e.g., due to data drift. Another example of
factors impacting data accuracy is the sensor power supply. If a battery is
running low and there are inconsistencies to the sensor energy supply, there
might be errors introduced in the sensors’ readings, which in turn originates
erroneous data. Lastly, the physical vulnerability also affects the
positioning of the sensors and thus can have a negative implication on the
reading. For instance, sensors deployed close to the water surface may
accidentally make a reading outside of the water. Another example concerns
sensors that use their static configured position as part of the data
acquisition and are dragged from their initially deployed location.

##### Completeness, Consistency and Currentness

These quality attributes are impacted by all challenges affecting the
reliability and performance (in terms of network throughput) quality
attributes of the data-producing system. The reason is that these challenges
entangle the availability of software components and data transmission. The
compatibility-related challenges can affect the completeness of the data
products because of the lack of common fields and metadata available from the
heterogeneous sources of data at the data acquisition and management layers.
In addition to the compatibility challenges, consistency with other data might
be affected as well because of the correlation of measurements. Finally, the
high latency associated with the underwater and OTA communication channels
greatly impacts the arrival time of data to data consumer applications. This
in turn affects the currentness data quality attribute.

##### Credibility

Credibility is a cross-cutting concern inherent data quality attribute, and it
relates to “truthfulness of origins” [iso25012]. In the IoUT context, it is
not possible to have the ground truth for all measurements and most quality
control procedures focus on investigating the closeness of the data to its
true value [ref17]. Trust is also impacting the cross-organizational level of
the system because of all the uncertainty affecting the data streams until its
(re)use [ref13].

##  IV Architectural Decisions

In this section, we describe the main architectural decisions to build systems
with heterogeneous marine data streams driven by data quality. The decisions
are summarized in Table III. All decisions are made by considering the
challenges presented in the previous section and thus aid in mitigating the
system’s quality attributes affected. The architectural decisions do not
address the challenges in isolation but, instead, in context with other
conflicting or related challenges. Throughout the description of architectural
decisions, we refer also to the component and connector view shown in Figure
2, which highlights the data flow components.

TABLE III: Summary of Architectural Decisions (ADs) ID |  Architectural Decision |  Challenges
---|---|---
AD1 |  Distributed data processing and transmission responsibilities |  CH1,CH4,CH5,CH6, CH7,CH8,CH9
AD2 |  Data platform |  CH12
AD3 |  Message-oriented data ingestion middleware |  CH1,CH2,CH9
AD4 |  MQTT messaging protocol |  CH4,CH7,CH9
AD5 |  Platform monitoring |  CH1,CH2,CH4, CH12,CH13,CH15
AD6 |  Data quality control |  CH5,CH11,CH12
AD7 |  Data model for integrated data sources |  CH3,CH10,CH12
AD8 |  Identity provider |  CH13,CH15
AD9 |  Data sharing access control |  CH13,CH14,CH15
AD10 |  Data classification and triage |  CH13,CH14
Figure 2: Overview of the resulting architecture - component and connector
view.

##### Distributed data processing and transmission (AD1)

Because of the challenges at the data acquisition and network communication
layers, there is a trade-off between the volume of data sent, the power
consumption to transmit data (CH9) in the UWSN, and the density of the
wireless communicating nodes in the area to cover and their impacts when
transmitting data wirelessly (CH6). On the one hand, the volume of data
depends on the number of sensor devices deployed, their configured sampling
rate, security mitigation strategies (CH8), and the power consumption in the
nodes inside the UWSN (CH1). These aspects are part of the responsibilities of
the Sensor component in the overall architecture layout in Figure 2. On the
other hand, the available bandwidth and latency can vary with the water’s
physical properties being in best conditions already very limited in
comparision to the amount of data that can be generated or the bandwidth
available in typical land-based systems, creating a bottleneck in the
throughput (CH7). Additionally, each transmitted message inside the UWSN can
impact marine life. The Local Processing component in the architecture in
Figure 2 is a consequence of this, being responsible for aggregating and
fusing raw measurement data from the sensors in the UWSN. Because of the
limitations on data transmission (CH4 and CH7), this decision brings
computation closer to data acquisition instead of sending raw data to be
processed on the cloud level where more resources are available (CH5). When it
comes to the communication inside the UWSN, ad hoc protocols and serialization
are needed when transmitting data from underwater to surface gateways. In
turn, the surface gateways have to bridge to long-range transmission channels
provided by satellite links or mobile networks (e.g., 4G or 5G) using the
carriers’ standardized APIs. This behavior is part of the responsibilities of
the Communication Management component depicted in Figure 2, which is
responsible for bridging data through heterogeneous communication channels and
devices, e.g., underwater acoustics and over-the-air technologies.

##### Data Platform (AD2)

To address the interoperability issue introduced by challenge CH12, there was
a decision to have a data platform built to allow data aggregation from
different sources before its usage on the application level for use cases
within the marine domain. The rationale behind this decision was to have a
common configurable platform that can be parametrized when interfacing with
the other layers according to its operational scenario requirements. Although
some processing is done in the lowest layers, at the platform level, data
fusion is performed, aggregating data from different sensing platforms. Thus,
it is assumed that the volume of data is larger at this level despite sharing
the property of dealing with heterogeneous data formats at the device and data
source ingestion, accordingly. In the resulting architecture in Figure 2, this
decision is reflected in the Ingested Data Processing, and the Data Space on
the right-hand side.

##### Message-oriented data ingestion middleware (AD3):

The rationale for this decision was to use a standardized way to provide data
that is delivered by different (distributed) systems to Data Consumer
Applications. By using the publish-subscribe pattern, we decouple data-
producing systems from data-consumer systems, bringing more flexibility when
handling outages from each one of these types of systems. With this pattern,
data producers and consumers do not need to know or keep information about
each other, transferring the responsibilities to a broker component that can
also handle concurrent data ingestion and provisions to the systems that might
connect to it over time. The resulting architecture in Figure 2 implements
this component via the Ingestion Broker. This decision adapts to the
uncertainty introduced by unreliable communications and the physical
vulnerability of the components in the underwater data acquisition and the
network communication layers (CH1, CH2, and CH9), affecting data reliability
and availability.

##### MQTT Protocol (AD4)

MQTT is an OASIS standard protocol for message exchange in IoT-enabled systems
and it is used on the top of the publish-subscribe communication model. Its
lightweight (low footprint and small message size) characteristics and
simplicity in implementation have fomented the creation of a large community
and services built on top of the protocol [mqtt_survey]. Other important
characteristics of the protocol are the Quality-of-Service (QoS) levels for
end-to-end communication: Level 0 (at most once) is suitable for operational
scenarios in which data loss is permitted; Level 1 (at least once) can be used
in operational scenarios in which duplicated data delivery is permitted; and
Level 2 (exactly once) in cases where data duplication cannot be tolerated.
Depending on the network protocol used inside the UWSN that defines the
behaviour for re-transmissions for the surface gateway systems, it might be
more adequate to deploy the different QoS levels from the communication
between the Surface Gateway and the Ingestion Broker component, and addressing
the uncertainty introduced by the unreliable underwater wireless communication
(CH4). The low footprint also fits well with the low communication bandwidth
and high operation costs of the satellite link (CH7), and contributes to its
low overhead to save bandwidth and potentially the number of transmissions
needed (CH9). The size of the data to be transmitted also influences the
selection of a suitable network protocol solution.

##### Platform monitoring (AD5)

The main drivers for this decision are the causes of faults that impact the
layers inside the UWSN, affecting the availability of data on the Ingested
Data Processing component. Since there is a runtime dependency of the system
behavior on data, it is crucial to detect errors that occur at runtime as
early as possible to trigger context information for root cause analysis and
shorten the recoverability of the overall system. More specifically, it
addresses the challenges at the data acquisition and network layers, causing
uncertainty in the data availability introduced by unreliable communication,
physical vulnerability, and limited battery (CH1, CH2, and CH4). This decision
also encompasses the monitoring of the interactions of the data platform with
the external systems. This concerns the ingestion of data (CH12) and data
consumption. The latter is to help assess the usage of the overall data
management layer components and ensure that data is provided to rightful
consumer applications systems (CH13 and CH15). For this decision to be
implemented, components and data instrumentation, i.e., measurement and
recording of their runtime outputted behavior, are needed. Thus, intervention
in the different parts of the architecture is required making it cross-cutting
concern.

##### Data Quality Control (AD6)

Data quality is one of the main drivers and concerns of stakeholders across
various organizations. It is reflected in challenge CH11, and understanding it
for the various marine use cases is crucial for trusting the decisions made on
the provided data. In this domain, because of the restricted wireless
underwater communication, there is an additional level of complexity when
trying to understand the data quality because of the small volume of data that
can be ingested into the data management layer (CH5). Knowledge about the UWSN
must be kept and updated to be used during the quality control process. This
task is distributed across the different processing components ( Local
Processing and Stream Processing) in Figure 2. In particular, metadata
information about the measurement systems (sensors) is needed to understand
the level of data quality and its suitability for a specific use case.
Additional contextual metadata information recorded throughout the data
delivery pipeline ( Monitoring) and other related historical data sources
might be used to assess and ensure the quality of the data on the real-time
data streams. Furthermore, the data source format standards (CH12) also affect
the understanding of data adequacy according to the available information
contained in the format in the context of different use cases.

##### Data model for integrated data sources (AD7)

On one hand, as a result of the Local Processing, there is a resulting data
source in a proprietary format for each organization that is then integrated
for the different Data Consumer Applications. The integration is needed
because data producers have to incorporate sensors manufactured by others and
deal with different device output formats (CH3). On the other hand, as a
consequence of the diverse data formats and standards used to ingest data from
the UWSN (challenge CH12), there was a need to have a uniform format for the
processing done by the different services inside the Stream Processing. This
simplifies the development of the services and addresses and fosters a single
interpretation of the data at the data management layer. This decision aims to
create a representative and flexible model to provide an adequate level of
understanding (metadata) of data and its quality, addressing the challenges of
the understandability of data for the different use cases (CH10). However, a
challenge introduced by this decision is handling the model evolution as
required information and available fields change over time and keeping
backward compatibility to expected formats on the Data Consumer Application
side. Another consequence of this decision was the separation of the brokers,
isolating the Ingestion Broker from Core Broker.

##### Identity provider (AD8)

For the ingestion and sharing of the data in the data platform, there must be
mechanisms to verify the identity of the systems interacting. There is also a
need to ensure correct access, which can only be managed by knowing the
identity of the systems. The knowledge held in the data platform intermediary
layer can be used to address the access control challenge (CH15) and to
establish a baseline for the selective process of sharing sensitive (CH13) or
insensitive data. During the integration of the systems in various
organizations, there was also an interoperability issue among the
authentication methods and solutions. The rationale behind this decision was
to unify the authentication of components and their associated authorization
to the different ingested and data sharing flows. Additionally, since various
frameworks can be deployed between the decoupled high-level components in the
architecture presented in Figure 2, especially for the ones at the cloud
level, the authentication solutions provided by those must also be integrated.
Therefore, this is a cross-cutting concern for the interactions between the
components.

##### Data sharing access control (AD9)

When data is delivered to the Data Consumer Application component, there is a
need for mechanisms to authorize access to the different flows of data (CH15)
according to the data category and its degree of “openness”. This decision
helps to address challenges in accessing or vetting sensitive data (CH13) and
managing the ingestion into the Data Consumer Application’s side because of
the reusability challenge (CH14). This decision relies on an identity solution
for the interacting systems and is thus closely related to AD8. In
conjunction, they constitute a cross-cutting concern regarding ensuring
security at the data management layer is represented by Identity Provider and
Access Control Management in Figure 2. Its implementation is based on adding
authentication to the different components and sub-components, and by adding
authorization to data accordingly. This decision encompasses rules defined in
authentication and authorization management, integrating with the various ways
to deliver data via the Core Broker and the Data Space using the push and pull
methods to the Data Consumer Application. Moreover, this might also entail
granularity of controls at brokers’ topics access.

##### Data classification and triage (AD10)

Complementary to the access control decision (AD9), an intermediary step is
needed to classify the ingested data streams. One of the major drivers behind
this decision is the sensitive data (CH13) because of its reusability (CH14)
in a context different from the one for which the data acquisition was
designed. The rationale for this decision is to filter different categories,
quality levels, and “openness” of data impacting the access control to data
shared on the Data Consumer Application components. In the resulting
architecture in Figure 2, the Stream Processing component is responsible for
implementing the behavior behind the rationale of this decision.

##  V Architecture in Context

The prototype implementation presented in Figure 3 reflects the ongoing
migration process to the proposed architecture. To realize this migration,
many factors come into play, making it a complex and slow process. More
specifically, the cross-organizational dependency of the development and
operation of different component blocks.

Figure 3: Architecture of the prototype implementation.

The tiers, graphically shown as a cube in Figure 3’s legend (Tier label),
represent physical machines at the UWSN level while at the cloud level, the
components are allocated to hybrid clouds using private and public cloud
providers.

In the prototype, there are currently two data producers organizations with
different data acquisition and network communication setups, as we can see in
Figure 3. Organization 7 has in its portfolio a vertically integrated sensor
(physical) platform that incorporates all the needed components for the data
acquisition and network layers. There are currently two of these platforms
deployed at sea and sending data approximately every 30 minutes to their
control and storage platform. While this setup avoids the use of wireless
underwater communication, it also presents a single point of failure and needs
to be combined with the deployment of other platforms to expand the area
coverage. Oganization 8 has a more flexible setup, with a mesh of nodes
distributed in the same area of interest and with adaptive roles locally
coordinated by their gateway at the edge of the UWSN. There are currently two
sensing nodes and one gateway sending data to their data platform
approximately every hour. Both organizations are using mobile networks to
transmit data over-the-air to their data platform, using the Network Carrier
Gateway component.

For the security inside the UWSN, because of the flexibility and distribution
of components, there might be no wireless underwater data transmission and
thus, the challenge CH9 (see Table II) associated with that link does not
apply. This is the case for organization’s 7 system’s components architecture.
It employs all the needed components in the same physical system with serial
or ethernet connections from the sensors to the surface gateway. On the other
hand, there could also be a mesh of nodes physically distributed, which is the
case for the configuration of the system for organization 8. The security
inside their UWSN is provided by a tailored framework that follows the NIST
recommended levels of security in [nist_csf] with focus on low overhead in the
underwater communications.

At the cloud level, the authors associated organization is responsible for the
implementation of the components at the data management layer for the
heterogeneous data streams ingested by the data producers’ systems. The
implemented Ingested Data Processing component is currently transforming,
quality controlling, and forwarding data sources ingested in JSON and XML
formats by the different data producers. The data quality control checks
whether a recently data point is good or bad. The check is triggered once a
data point arrives to cope with real-time data usage requirement from data
consumers. In case a data point is missing due to, for example, communication
issues, sensor faults, the component generates a missing value and triggers an
alarm. The quality of data is assessed by four data quality attributes as
introduced in Section III-E. The cross-organizational integration done at the
cloud level and the use of message-oriented middleware for data ingestion
(AD3), resulted the development of a new way of delivering data for the
existing data platform of organizations 7 and 8 (see Table I). These changes
were done to implement the expected behavior for the Data Pusher component of
the overall architecture in Figure 2, and receiving the data as soon as it
arrives on the different clouds. For organization 7 all the efforts where done
on their side to complete the migration process. For organization 8 data
integration using the push behavior, the Data Pusher component was implemented
on the data management side to bridge the data provided via their own MQTT
broker. For the broker components implementation on the prototype we are using
HiveMQ (https://www.hivemq.com/). Lastly, regarding data ingestion, since the
data was initially provided by organization 8 via a REST API using the Data
Fetcher component, this ingestion method can still be used to retrieve
historical data in case of down time (availability issues) on the sending or
receiving components.

For the Monitoring component, we are monitoring Key Performance Indicators
(KPI) for the data platform. These KPIs function as service level objectives
and are translated to interact with the Prometheus monitoring toolkit
(https://prometheus.io/) where runtime metrics are stored.

Concerning the data provision to Data Consumer Applications, the current
prototype is dealing with heterogeneous authentication methods challenge being
in the process of migrating to a centralized authentication method using
Keycloak (https://www.keycloak.org/) as an identity and access management
solution to enable the access control via the services’ identity associated
credentials. Nevertheless, for testing proposes, a Data Streams Visualization
GUI has being integrated to visualize the data coming from the different
streams. This component was implemented using Thingspeak
(https://thingspeak.com). Finally, on the Data Consumer Application side,
efforts are being made to deliver data to a data visualization and analytics
software operated by organization 2, and to a marine data archive managed by
organization 13 (see Table I).

##  VI Discussion

The architectural decisions proposed conceptually address concerns raised by
the identified challenges, providing a clear understanding of data quality in
the different stages of the data flow: data acquisition, processing, and
(re)usage. At the Underwater Wireless Sensor Network (UWSN) level, the
components are managed by the organization that developed and deployed them as
a service. Because of the custom hardware setup of the data producers’
systems, the data can flow among the processing and transmitting components,
traversing different traces according to the routing protocols inside the
UWSN. From the data producer actor viewpoint, the components at this level
must optimize the data to be sent up, prioritizing what is more relevant for
the operations in case there are conflicts in the bandwidth usage. At the same
time, there is a need to balance the battery consumption, the environmental
impact of the data delivery in (near) real-time, and the network security
measures (AD1).

Regarding the cross-cutting concerns at the UWSN level, on the one hand, the
data producer systems can monitor and configure the different nodes remotely.
On the other hand, concerning security, there are no domain-specific solutions
to address the challenge of securing underwater wireless communications in the
case of obstruction of the communication channels (denial-of-service) or a
compromised node (spoofing) since the wireless communication channels
underwater are open. The systems’ resource capacity imposes constraints on
adopting solutions from other wireless communication and IP networks. Overall,
these requirements enable the reliable and secure adjustment of nodes’
behavior regarding the volume of data needed for acquisition and transmission.

At the cloud level, the Ingested Data Processing sub-components are loosely
coupled for the elasticity of the computation due to the variable volume of
data pushed or pulled into the pipeline. Additionally, data might need
different processing services according to the quality requirements. The first
step into the processing of heterogeneous data streams ingested is to convert
them to a complying syntax and semantics, assuring that all the processing
components work upon the same specification and understanding of data (AD7).
This step is also responsible for validating the ingested data, contributing
to the completeness and compliance quality attributes of data. If the storage
of data in its raw format is desired for future reprocessing, this can be
achieved by the proposed architecture. After the transformation process, data
is again ingested into the Core Broker component for distribution to the
different Stream Processing services. Additional information might be needed
by these processing services not only at the UWSN level but also from external
data. Another responsibility held by the Stream Processing component is the
categorization of data, aiding the sharing access control rules implementation
and addressing availability and confidentiality data quality attributes. The
data model will have significant impact on the selection of solutions for the
database management system (Data Space component in Figure 2). It is important
to have a flexible database model to minimize the overload when updating the
components with the evolution of the data and metadata fields requirements.

Regarding the cross-organizational data flow, to enable the flexibility on the
delivery of data needed at the cloud side, there are three alternatives for
data ingestion in the data management layer. In the proposed architecture,
this can be achieved via the pusher, fetcher or the edge components. The first
component is responsible to integrate data sources at the cloud level
interacting with data producers’ systems over IP networks. In this case of
data ingestion, the responsibility lays on the data producers side to push
data into the data management layer. Second, the Data Fetcher component can
pull data from ephemeral data acquisition systems (manual/ship sea surveys),
other databases or streams into the processing pipeline. Thirdly, the Edge
Integration Management component differs from the others in its physical
location at the UWSN level. In this case, the data sources integration is
performed closer to the data acquisition, with more access to information in
this layer, transferring the costs of OTA transmissions done via the Network
Carrier Gateway component. For this component to be implemented, the data
producers’ systems have to be exposed for integration locally. The existence
of neither one of these three components is exclusive, this is a reflection of
the distribution of processing and communication responsibilities in the first
architectural decision (see Table III), as was demonstrated in the
architecture implementation in Figure 3.

Finally, on the cross-organizational data flow, there is a need to make
heterogeneous components’ authentication methods uniform to enforce ingestion
access policies and sharing rules. There is also a need to regulate the access
to data via push and pull methods (from the Stream Processing or the Data
Space respectively). This is similar to the ingestion into the data management
layer. These concerns are transversal to the architecture and must be
implemented in the organizational boundaries along the data flow.

##  VII Related Work

Important aspects of data architecture for Internet-of-Things (IoT)
applications are [abughazala2022dat]: data quality, data security,
organizational efficiency, business intelligence and analytics, and
scalability and flexibility. IoT is the foundation of IoUT in which System is
situated [pena2005itu]. We took into account those aspects while designing our
architecture.

Some software architectures have been proposed to accommodate heterogeneous
aspects [seifermann2019data, rademacher2019aspect, CORRALPLAZA2020103426].
However, none of them considers a broad range of software and data quality
concerns as we have identified, and neither consider a data actor viewpoint.
The work in [seifermann2019data] deals with the confidentiality of multiple
data streams. A metamodel built on top of the Architectural Description
Language (ADL) Palladio Component Model (PCM) [reussner2016modeling] is
proposed to detect access right mismatches regarding data consumption roles of
an information system. This solution covers only two challenges (CH13 and CH15
in Table II). In IoT environments, the work in [CORRALPLAZA2020103426]
proposes an architecture focusing on the heterogeneous data processing layer
based on nine requirements from 2 survey studies, abstracting the data sources
and consumers. The paper [rademacher2019aspect] addresses the challenges of
accommodating various different technologies used in information systems.
There are different software technologies utilized in our software
architecture (see Section IV). We rely on Service-oriented Architecture (SOA)
[siqueira2021service, hastbacka2019dynamic] to decouple the components and let
stakeholders take responsibility of maintaining their components
independently. We leverage MQTT as a plug and play mechanism
[hastbacka2019dynamic] to facilitate migrations of various data sources to the
system and address the challenge of having multiple communication protocols,
data formats, and data streams in System.

More recently, an architecture for an IoUT system has been proposed based on
four multi-vocal references and validated with three quantitative performance
efficiency metrics [RAZZAQ2023100893]. Our work has a concrete context
enhanced by challenges gathered from nineteen studies from the literature.
Consequently, our validation has a broader scope rather than performance
quality attributes metrics, allowing us to take into account factors affecting
the quality of not only software (like [ref13]) but also data (see [ref15])
while designing the architecture.

##  VIII Conclusion and Future Work

This study employed the analysis and discussion of quality attributes for
software and data impacted by domain-specific challenges in a cross-
organizational context. We presented a set of architectural decisions that
incorporate the concerns from the challenges. The resulting data-flow-oriented
architecture has been instantiated and demonstrated in a prototype
implementation, which has been built in the context of a research and
development project. As more iterations occur, we expect new challenges,
especially concerning data sharing for reusability purposes, edge integration,
and backward flow of control if exposed as a cross-organizational service. In
future works, the relation between data and software quality attributes will
be further investigated to evaluate the architecture, including how they can
be quantified and measured (metrics). In particular, the credibility data
quality attribute needs to be further investigated as it remains an open
challenge and goes beyond the scope of this paper.

## Acknowledgment

This work was partly supported by SFI SmartOcean NFR Project 309612/F40, and
PNRR MUR project VITALITY (ECS00000041), Spoke 2 ASTRA - “Advanced Space
Technologies and Research Alliance” and of the MUR (Italy) Department of
Excellence 2023 - 2027 for GSSI.