# Efficient Data Management and Interoperability Middleware in Business-Oriented Smart Port Use Cases

Achilleas Marinakis, Matilde Julian Segui, Andreu Belsa Pellicer, Carlos E. Palau, Christos-Antonios Gizelis, Anastasios Nikolakopoulos, Antonios Misargopoulos, Filippos Nikolopoulos-Gkamatsis, Michalis Kefalogiannis, Theodora Varvarigou, et al.

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

## To cite this version:

Achilleas Marinakis, Matilde Julian Segui, Andreu Belsa Pellicer, Carlos E. Palau, Christos-Antonios Gizelis, et al. Efficient Data Management and Interoperability Middleware in Business-Oriented Smart Port Use Cases. 18th IFIP International Conference on Artificial Intelligence Applications and Innovations (AIAI), Jun 2022, Hersonissos, Greece. pp.108-119, 10.1007/978-3-031-08341-9_10.hal-05335618

HAL Id: hal-05335618

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

Submitted on 28 Oct 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>
<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.
Efficient Data Management
and Interoperability Middleware
in Business-Oriented Smart Port
Use Cases

Achilleas Marinakis<fnref n="1" /> ID, Matilde Julian Segui<fnref n="2" /> ID, Andreu Belsa Pellicer<fnref n="2" /> ID,
Carlos E. Palau<fnref n="2" /> ID, Christos-Antonios Gizelis<fnref n="3" /> ID

Anastasios Nikolakopoulos<fnref n="1" /> ID, Antonios Misargopoulos<fnref n="3" /> ID

Filippos Nikolopoulos-Gkamatsis<fnref n="3" /> ID, Michalis Kefalogiannis<fnref n="3" /> ID

Theodora Varvarigou<fnref n="1" />, Konstantinos Nestorakis<fnref n="3" /> ID, and Vrettos Moulos<fnref n="1" /> ID

**Abstract.** The interoperability of critical infrastructures, such as ports, has become a primary concern of EU in recent years. Information systems that have the control of these infrastructures are continuously evolving and handle heterogeneous collections of data, processes, and people. Moreover, cross-infrastructure dependencies may give rise to cascading and escalating data model discrepancies across interconnected systems. In this article, we present a data model -following the newest technology standards- that tries to consolidate APIs and services of highly complex infrastructures. Port environments are a characteristic example of them, since massive amount of data and services from different sources are processed and used. We adopt a bottom-up approach, considering every service interconnection as an independent entity, which must be aligned with the proposed common vocabulary and data model. The strict guidelines that are injected into the lifecycle of a service/component development, lead to explicitly enforce interoperability between each one service that lives inside the ecosystem of the port. That is -and should be- a step towards “the cognitive port of the future”, where developers, SMEs and huge vendors can exchange and reuse data from a shared repository. Consequently, ports will play key role in the new information system model, as in-house marketplaces will be developed, for companies to disseminate and exploit their data and services.

<footnote n="1">¹ School of Electrical and Computer Engineering, National Technical University of Athens, 9 Iroon Polytechniou St., 15780 Athens, Greece</footnote>

<footnote>`{achmarin,tasosnikolakop,vrettos}@mail.ntua.gr, dora@telecom.ntua.gr`</footnote>

<footnote n="2">² Department of Communications, Universitat Politècnica de València,
Camino de Vera, s/n, 46022 Valencia, Spain</footnote>

<footnote>`{majuse,anbelpel}@upv.es, cpalau@dcom.upv.es`</footnote>

<footnote n="3">³ IT Innovation Center OTE Group, 99 Kifissias Avenue, 15124
Marousi, Athens, Greece</footnote>

<footnote>`cgkizelis@cosmote.gr`</footnote>

<footnote>`{amisargopo,fnikolop,mkefalogiannis,knestorakis}@ote.gr`</footnote>
**Keywords:** Smart Ports · Marketplaces · Interoperability · Smart Data Model · Data virtualization

# 1 Introduction

Seaports constitute a cornerstone of the global economy, since they serve as the connecting tissue between all the other modes of transport. Ports activity in terms of international shipping trade has exploded in the recent decades, resulting in the dynamic evolution of the harbours and the increasing degree of complexity of their management [1]. In order to support port management process under transparency, data-driven intelligence is introduced. The latter requires the aggregation of miscellaneous data that can be gathered from the port itself, as well as any stakeholders that are involved in its operations. In fact, the maritime domain involves data sources of a high magnitude that may include information about vessels, oceans, wave stations, observations from environmental conditions, fishing and maritime biodiversity, routes, trajectories, and incidental or voluntary oil spill events [18]. Furthermore, concerning Smart Ports and the interrelated IoT technology, the rapidly growing presence of smart logistics mechanisms and smart sensing systems in ports, realize the automation of the port’s functionality and thus the generation of large amounts of data. The range of this generated information is wide while involving a plethora of communication, sensor systems and control technologies to facilitate data collection throughout the supply chain for decision-making in real time and information sharing between the various stakeholders of the port [6]. Moreover, the collection of maritime data is performed through a variety of ways and stored in many different data formats, while the harvested data itself might be structured, semi-structured or unstructured.

Big Data techniques applied to this huge amount of data could provide ports the necessary tools for automating decision processes and controlling job queues. Those techniques would allow -for example- dynamic job assignment for container handling, integrating not only operational data but also global data coming from other actors along the value chain. In other words, unleashing the potential power of the existing data derived from port operations could optimize the usage of its resources and infrastructure. However, this scenario is far from being real, due to the lack of interoperability among data combined with efficient data management schemes, which is preventing ports from adopting data-driven solutions in their production environments. This is where DataPorts project [4] kicks in, and more specifically its data processing middleware that is introduced in this paper.

From business perspective, increasing data interoperability is a way to assist seaport authorities to optimize their passengers’ facilitation, improve traffic around the port region and by that improve the approach routes, the embarkation and disembarkation processes aiming to have a positive economic effect for the Port (potential increase of the serving ships), as well as for the shipping
<figure><img src="image_4.png" /><figcaption>Fig. 1. External potential beneficiaries</figcaption></figure>

companies (cost reduction). Potentially, besides the economic benefits for the port authorities, various stakeholders can be beneficiaries from the data interoperability, in order to improve their services. Telecom operators, by exploiting their vast amounts of data, are considered as a valuable player in this emerging data-driven market. Offering data, or services through APIs, can provide great insights for improved decision making to external interested stakeholders (e.g. Public authorities, Municipalities, Shipping Companies, Transportation Authorities, Cultural and Trade Associations, etc.). In many cases it is considered challenging to fuzz such data with streams coming from other sources and therefore the benefit is increased.

## 2 Business Model and Services

Envisage the following brief scenario: on the day of their travelling, passengers are going to use a mobile application that will inform them in real time about the best route to approach the port and board on ship. This approach may have as an outcome the orchestration of the passenger flow in an optimal way towards their boarding. In order to achieve this scenario, it needs to rely on historic and real-time data residing in mobile application, as well as web services. Several external stakeholders might be beneficiaries of such data-driven services. Some of them have no previous relation with shipping ports community. They are listed in Fig. 1, along with the potential benefit.

Concerning Telecom companies, they could generate revenues from the data and services offerings/usage and the respective fees and also benefit from
customer loyalty and possible additional communication services sales. In principle, they need to take into account various assumptions both regarding the CAPEX/OPEX and the revenues parameters depending on the individual case (e.g. country, market size, penetration, income per capita, and prices). The business case analysis would be required in a long-term timeframe, for an estimation of the breakeven point and the expected profits that can be obtained. More specifically, based on the selected data market, the revenues and costs that are incurred should also be considered (e.g. number of customers and the increasing rate, average monthly volumes of data, H/W and S/W costs and the cost for upgrading/deployment of additional H/W, customer acquisition, etc.). Telecoms, collect, handle or own large amounts of data that usually are exploited internally. In a data-driven market, the Telecoms' involvement may include mobility and usage traffic, demographics, and other network related data that can be associated with the population density [13]. Such datasets fused with port authorities' available data, like the ship's arrival/departure schedules and the number of passengers of each ship provided by the shipping lines, will offer valuable cognitive information to be accessed and exploited by many shipping ports' ecosystem stakeholders, not excluding those that until now are not related to the ports. In such an emerging market the mobility data -real and non-real time ones- can be of significant value. Those datasets may be also used by Port Authorities, Shipping Companies, Cargo/Logistics Companies. These stakeholders may be considered as consumers of the Data as a Product service, where they can use the offered data as a source for decision support and new services. Similarly, available data might also be used by Research Institutes, Universities, Startups and SMEs in order to develop AI-based cognitive services that can be sold to various stakeholders in shipping port ecosystem, not excluding other non-shipping related ones. They may be considered as consumers or partners towards the development of Data bundle as a Service category.

Moreover, there are several other consumer categories such as, the Municipalities and other Public Sector Bodies, Commerce Associations, Cultural Heritage and Museum entities, Transportation (public or private), LEAs and Medical Bodies that can be considered as consumers to both categories (i.e. Data as a Product and Data bundle as a Service) by using offered datasets as information for their customers (e.g. citizens) or by fuzzing them with other services or develop new ones. Having so many heterogeneous stakeholders, a detailed data model should be developed in order to adapt, collect and safely store the data. On top of that interoperability analysis should take place forehand, as most of the services have to exchange information in such an interconnected environment.

## 3 Data Model and Interoperability

Interoperability is the ability to share data and services among different computer systems and depends on the ability of the involved systems to understand the structure and meaning of the data that they receive and present the data that they send in a way that can be interpreted by the others. Semantic interoperability is based on the definition of an unambiguous way to interpret the
data that is being exchanged between computer systems. This can be achieved through the use of an ontology, which provides a vocabulary for a domain where the concepts present in that domain are defined without any ambiguity and may be related to each other or organized according to different criteria. Hence, an ontology provides a common understanding of the domain of interest [12].

However, in the case of DataPorts, enabling interoperability is not a trivial task because the different organizations in transportation and logistics do not follow a common standard. Instead, they usually have their own vocabularies, which may have a poor definition of semantics or no explicit semantic formulation at all. For this reason, the proper definition of a common vocabulary for this domain, following the appropriate guidelines and best practices, is necessary to enable interoperability. Moreover, the actual needs of the market must be taken into account during the definition of a common data model in order to be able to implement solutions that are valuable for the different stakeholders. The DataPorts project has developed a common data model for describing the data of the port domain in a systematic and standardized way, with mappings to standard vocabularies in order to facilitate interoperability with other solutions. The use of this common data model will enable the reuse and exploitation of the data in cognitive port applications, as well as the reuse of those applications.

The first step in the definition of the common data model was the identification and analysis of the different data sources that had to be integrated in the DataPorts platform. This analysis considered the meaning and format of the data, as well as the storage and data management mechanisms. From this analysis, the main concepts of the vocabulary were identified and classified as possible classes, attributes or relationships. Next, the existing ontologies and vocabularies related with the application domain were studied in order to identify which of their concepts could be reused in the DataPorts data model. In this step, the following ontologies and vocabularies have been analyzed in order to reuse the appropriate concepts in the DataPorts common data model: Fiware Smart Data Models [11], IDSA Information Model [15], United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) model, Blockchain in Transport Alliance (BiTAS) [2], DCSA Interface for Track & Trace [5], IPSO Smart Objects (OMA SpecWorks) [16] and Smart Applications REFERENCE (SAREF) ontology [22]. In particular, the Fiware Smart Data Models have been especially relevant for DataPorts because components of the Fiware platform [10] have been selected as part of the core elements of the DataPorts platform. The concepts from the identified vocabulary that were not found in the standard ontologies and vocabularies were defined following the Fiware Smart Data Models guidelines.

The Fiware Smart Data Models are based on open standards and real use cases and have been developed by a collaborative Fiware-related initiative focused on the definition of data models to facilitate interoperability in different application domains by the provision of harmonised formats and semantics for the data. Following those guidelines, the DataPorts common data model is compatible with Fiware NGSI v2 and the European Telecommunications Standards
Institute (ETSI) [7] standard NGSI-LD [20], which is an evolution of NGSI v2 to support Linked Data. NGSI defines an information model and an interface for sharing context information, while the use of Linked Data enables the automatic association of the data with an ontology.

The DataPorts common data model is hosted in a Git repository. Following the structure of Fiware Smart Data Models, the concepts in the DataPorts data model have been grouped under a set of subjects inside the Smart Ports domain (Fig. 2). Each subject contains the corresponding NGSI-LD context document, which describes how the data is interpreted according to the ontology, as well as other shared resources and information, and provides access to the different entity types that it contains. The representation of the entity types is described using JSON schema. In addition, the specifications of each entity type and the corresponding examples in NGSI v2 and NGSI-LD, as well as in plain JSON and JSON-LD, are provided. Thus, the data model is fully compatible with the Fiware ecosystem and the Smart Data Models initiative.

<figure><img src="image_5.png" /><figcaption>Fig. 2. Domain and subjects of the DataPorts common data model</figcaption></figure>

The DataPorts platform enables semantic interoperability between the different data providers and data consumers through the definition of a unified semantic model and interface to access the data. In addition to the common data model, the necessary mechanisms and enablers to provide access to the data from the existing data sources were implemented. Since the data sources are heterogeneous in terms of their interfaces, data formats and data models, a set of agents was developed to connect each data source with the DataPorts platform. An agent is a piece of software able to obtain data from a source and translate it into the common data model and format. When certain conditions are met, the agent retrieves the data from the data source, translates it and sends it to the upper layers of the platform (Fig. 3). As a result, the data sent to the analytics services of the platform and any other potential data consumers that have the proper access permissions, follow the same format and semantic model, regardless of the particular aspects of the data source. The agents send the translated data to the Orion Context Broker, which provides a common API to access the data from the different data sources, and also to another component of the Fiware ecosystem, named Cygnus, which is designed to facilitate the management of historical data. The Orion Context Broker [9] and Cygnus [8] compose one of the building blocks of the Connecting Europe Facility (CEF)
[3] digital catalogue, which is known as the CEF Context Broker. In addition, the DataPorts platform provides mechanisms to enable security and data governance.

<figure><img src="image_6.png" /><figcaption>Fig. 3. NGSI agent</figcaption></figure>

This approach to interoperability offers the following advantages:

- Interoperability, allowing the connection of heterogeneous data sources while offering a common data model.

- Ease of use and deployment, since the components of the Fiware ecosystem and the agents can be deployed on Docker.

- Modular, scalable and extensible solution, since it could be extended with added value tools, and it is also possible to scale the components on demand according to the needs of the users.

- Less development effort, since the data will be available through a common API following the same format and semantics regardless of the type of data source, thus decoupling the applications that consume the data from the data sources.

- Fully compatible with the Fiware ecosystem and common open-source software.

# 4 Data Processing and Virtualization

Given that the data are translated and harmonized according to the data model described in Sect. 3, the next step is to provide those data as a service, so that developers can build cognitive data-driven applications on top of the platform. Therefore, a data processing and virtualization middleware is needed, as an abstraction layer between data providers and consumers. The goal is to assist the application developers to focus only on the required data, relying on the proposed middleware to deliver them, thus encapsulating all the underlying technical complexity. In fact, data virtualization is a data integration technique that provides access to information via a virtualized service layer, regardless of the location of the data sources. It allows applications to access data through a unique endpoint, thus providing a unified, abstracted, and encapsulated view of
information, while also being able to transform and process the data in order to prepare it for consumption. Furthermore, data-intensive applications, that use a virtualized data source, still expect certain quality of service guarantees from the system, such as performance, availability, etc.

DataPorts project attempts to deal with those challenges, putting emphasis on the quality of the data as well. For that reason, the so-called Data Abstraction and Virtualization (DAV) component has been developed, to simplify the data management in heterogeneous, complex, and distributed infrastructure, following the Data as a Service (DaaS) paradigm. More specifically, DAV is responsible for the proper pre-processing, cleaning, and filtering of the data coming from the agents, storing them to a secure and scalable data repository (data lake), and then making them available as data ponds to any potential recipients. Data ponds are created by applying specific filtering rules, defined by the users upon request. DAV also transforms and serves the data in a format selected by the developer, such as JSON, Parquet or CSV. Figure 4 depicts the internal structure of DAV, which is based on an already proposed information life cycle management framework [19]. The following subsections describe DAV’s subcomponents from functional and technical point of view.

<figure><img src="image_7.png" /><figcaption>Fig. 4. Data abstraction and virtualization internal structure</figcaption></figure>

## 4.1 Pre-processing and Filtering Software

PaFS is responsible for the initial pre-processing, cleaning and filtering of the datasets. It pre-processes the data by the means of fully collecting them, transforming into a Python code-friendly format and taking care of proper column/row structure. It cleans the data by detecting values such as NaNs, empty fields, outliers, wrong values, and finally filters the dataset by the means of eliminating all those values found, either by replacing, or removing them along with their respective rows. In more detail, to all the datasets available in the Data-Ports platform, PaFS applies the following generic pre-processing techniques:
- Removal of whitespaces from all string-type cells

- Conversion of empty cells and 'NULL' string values to 'nan' in all cells

- Removal of rows without datetime values, or with wrong ones

- Conversion of datetime values to UTC format

The scope of those techniques is to improve the quality of the data and thus to increase the performance of the applications that exploit them. Indeed, input data is a major concern for analytics services. For example, the quality of the data used to train the models has a huge impact on the efficiency, accuracy and complexity of machine learning tasks [14]. Furthermore, PaFS calculates a correlation matrix between the columns of each dataset. Last but not least, it detects outliers in numerical attributes, creating additional columns that indicate which corresponding column cell is considered as an outlier. The detection is implemented using the method of “three standard deviations from the mean”, as a cut-off radius/threshold.

## 4.2 Virtual Data Repository

VDR is the distributed infrastructure where all the pre-processed, cleaned, and filtered datasets, coming from PaFS, are saved. It is constructed based on MongoDB, carrying modifications and custom parameters to comply with DAV's efficiency standards. MongoDB was selected due to its auto-scaling/sharding capabilities, as well as its allowance of vital modifications/custom configurations by the designer. VDR lives inside a Kubernetes cluster, which is the optimal solution and fits perfectly to the needs of DAV, as it achieves proper load balancing, whilst offering replication, scaling and scheduling techniques [17]. Since DAV's main functionality is data virtualization, MongoDB's co-existence with Kubernetes (as a container management tool) seems imperative. VDR goes beyond existing frameworks that offer real time scaling capabilities in a MongoDB cluster [21]. Such frameworks enable the cluster to scale in order to handle rapidly changing number of users. However, the proposed system is capable of scaling in a fully automated way according to the workload, aiming at optimizing resource utilization and decreasing response times for applications in need of high availability. In particular, VDR takes full advantage of the Kubernetes built-in monitoring system, in order to automatically increase or reduce the number of replicas in a sharded MongoDB cluster, when the nodes CPU usage is higher or lower than certain thresholds.

## 4.3 Virtual Data Container

VDC is the interface through which communication with data recipients is achieved, for data stored in VDR to be made available, as shown in Fig. 5. Its role is to further process and filter the data, by applying specific filtering rules defined by the data consumers via HTTP POST requests. The scope of those rules is twofold: i) to filter the datasets and thus to serve only the specific data pond that a user is interested in and ii) to detect and remove wrong values
<figure><img src="image_8.png" /><figcaption>Fig. 5. Virtual data container information flow</figcaption></figure>

(from columns where those values are not acceptable e.g., outdoor temperatures at minus 50°C), which are most probably caused by sensors malfunction. Through that request, the data consumers also define the format (JSON, Paragraph or CSV) in which they want to receive the data (data transformation). The filtering rules are structured as an Array of JSON Objects, which consist of three core elements:

- The “subject_column”, which shall have the name of a dataset’s column

- A logical “operator”

- The “object”, which shall be a value in the same datatype as the “subject_column” or the name of another column that has the same datatype

Most of the common logical operators (greater than, less than, (not) equal, or, etc.) are supported by VDC and can be used by the rules' author (data scientist, application developer, end-user etc.). It is worth mentioning that a rule's main objective is to apply filters to only one subject column at a time and not combining subjects. If more than one columns are concerned as subjects in the same rule, then this step is considered more as a pre-processing and less as a filtering action, thus out of scope of VDC. The goal is to enable any potential DataPorts user to define a list of filtering actions on a requested dataset. For that reason, the rules structure is kept simple, so that they can be specified not only by data scientists and experts, but also by users with limited or no technical background within a ports ecosystem, who are nevertheless interested
in using analytics services on top of the available data. The tangible outcome
is a common access layer, where the data consumers simply define queries (in
the form of rules) in a unified format, and the VDC designer is responsible for
developing the suitable module to execute those queries, in compatibility with
the selected storage technology (MongoDB in the case of DataPorts).

5 Conclusion

The unique business characteristics of Critical Infrastructures -like ports- reveal
the need of a middleware where the data should be formulated in a way that
can be analysed accurately. On top of that, services should be refactored before-
hand in order to accomplish the desired interoperability between the intercon-
nected components. DataPorts project, through data-centric by design approach,
presents a solution where SMEs, telecom operators, data providers, service con-
tent creators and port authorities can collaborate and coexist into a friendly
data-sharing environment. That accomplishment is -and should be- the main
goal of platforms that have the ambition to build and populate an ecosystem,
able to attract companies, startups and individual developers.

**Acknowledgement.** The research leading to these results has received funding from
the European Commission under the H2020 Programme's project DataPorts (grant
agreement No. 871493).

References

1. Benedicto, M.I., Morales, R.M.G., Marino, J., de los Santos, F.: A decision support tool for port planning based on Monte Carlo simulation. In: 2018 Winter Simulation Conference (WSC). IEEE (December 2018). https://doi.org/10.1109/wsc.2018.8632389

2. Blockchain in Transport Alliance. https://www.bita.studio/. Accessed 28 Mar 2022

3. CEF Digital Home. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/. Accessed 28 Mar 2022

4. DataPorts H2020 EU Project. https://dataports-project.eu/. Accessed 28 Mar 2022

5. DCSA Interface for Track & Trace. https://dcsa.org/standards/track-trace/. Accessed 28 Mar 2022

6. Douaioui, K., Fri, M., Mabrouki, C., Semma, E.A.: Smart port: design and perspectives. In: 2018 4th International Conference on Logistics Operations Management (GOL). IEEE (April 2018). https://doi.org/10.1109/gol.2018.8378099

7. European Telecommunications Standards Institute. https://www.etsi.org/committee/cim. Accessed 28 Mar 2022

8. FIWARE Cygnus. https://fiware-cygnus.readthedocs.io/en/latest/. Accessed 28 Mar 2022

9. FIWARE Orion Context Broker. https://fiware-orion.readthedocs.io/en/master/. Accessed 28 Mar 2022

10. FIWARE Platform. https://www.fiware.org/. Accessed 28 Mar 2022
11. FIWARE Smart Data Models. https://github.com/smart-data-models. Accessed 28 Mar 2022

12. Ganzha, M., Paprzycki, M., Pawlowski, W., Solarz-Niesluchowski, B., Szmeja, P., Wasielewska, K.: Semantic interoperability. In: Palau, C.E., et al. (eds.) Interoperability of Heterogeneous IoT Platforms. IT, pp. 133–165. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-82446-4_5

13. Gizelis, C.-A., Mavroeidakos, T., Marinakis, A., Litke, A., Moulos, V.: Towards a smart port: the role of the telecom industry. In: Maglogiannis, I., Iliadis, L., Pimenidis, E. (eds.) AIAI 2020. IAICT, vol. 585, pp. 128–139. Springer, Cham (2020). https://doi.org/10.1007/978-3-030-49190-1_12

14. Gupta, N., et al.: Data quality for machine learning tasks. In: Proceedings of the 27th ACM SIGKDD Conference on Knowledge Discovery & Data Mining. ACM (August 2021). https://doi.org/10.1145/3447548.3470817

15. IDSA Information Model. https://github.com/International-Data-Spaces-Association/InformationModel. Accessed 28 Mar 2022

16. IPSO Smart Objects. https://omaspecworks.org/develop-with-oma-specworks/ipso-smart-objects/. Accessed 28 Mar 2022

17. Jawarneh, I.M.A., et al.: Container orchestration engines: a thorough functional and performance comparison. In: ICC 2019–2019 IEEE International Conference on Communications (ICC). IEEE (May 2019). https://doi.org/10.1109/icc.2019.8762053

18. Lytra, I., Vidal, M.E., Orlandi, F., Attard, J.: A big data architecture for managing oceans of data and maritime applications. In: 2017 International Conference on Engineering, Technology and Innovation (ICE/ITMC). IEEE (June 2017). https://doi.org/10.1109/ice.2017.8280019

19. Moulos, V., et al.: A robust information life cycle management framework for securing and governing critical infrastructure systems. Inventions 3(4), 71 (2018). https://doi.org/10.3390/inventions3040071

20. Privat, G., Medvedev, A.: Guidelines for modelling with NGSI-LD. ETSI White Paper (42) (2021)

21. Psomakelis, E., et al.: A scalable and semantic data as a service marketplace for enhancing cloud-based applications. Futur. Internet 12(5), 77 (2020). https://doi.org/10.3390/fi12050077

22. Smart Applications Reference Ontology. https://saref.etsi.org/. Accessed 28 Mar 2022