Adapting a Generic Smart Service Platform Architecture to the

Road-Based Physical Internet

Jonah Windolph

1 a

, Steffen Kaup

2 b

, Robert Wehlitz

1 c

, Bogdan Franczyk

3,4 d

and Andr

e Ludwig

5 e

Institute for Applied Informatics (InfAI), Leipzig, Germany

Mercedes-Benz AG, Group Research, B

oblingen, Germany

Leipzig University, Germany

Wrocław University of Economics, Poland

uhne Logistics University, Hamburg, Germany

Keywords:

Road-Based Physical Internet, Internet of Things, Smart Services, Service-Oriented Architecture.

Abstract:

Global trade will lead to more than a doubling of transport demand by 2050 in comparison to 2020. At the

same time, the impact of pollutant emissions on the global climate is leading to increasingly stringent legis-

lation regarding the environmental friendliness of transportation. Against this background, the transport and

logistics industry has to undergo a major transformation in the coming years. Hence, transport efﬁciency will

become more and more important. This will inevitably lead to a rethink in the industry about completely new

transport and logistics concepts, such as the Physical Internet (PI). Here, transport efﬁciency and thus more

environmental sustainability are supposed to be achieved by organizing the freight trafﬁc like the data traf-

ﬁc on the digital Internet, with the highest expected potential through a road-based Physical Internet (RBPI).

However, the realization of the RBPI depends on the existence of intelligent RBPI services enabled by suitable

smart service platforms. In this paper, we propose to adapt a generic architecture for smart service platforms

to the RBPI as a cornerstone for its technical implementation. This food for thought may serve as a starting

point for further discussions and detailed development in the future.

1 INTRODUCTION

The Green Deal of the European Union (EU) to reach

net-zero emissions of greenhouse gasses by 2050 trig-

gered a paradigm shift in the transportation indus-

try, forcing companies to rethink their logistics and

supply chain operations (Laurent, 2020). As climate

change has been recognized and accepted as a ma-

jor societal challenge of the 21st century, it is becom-

ing increasingly apparent that emissions in the trans-

port sector need to be drastically reduced to meet the

EU’s ambitious targets. 77 % of freight trafﬁc in Eu-

rope is caused by transport vehicles on the road (Eu-

rostat, 2022). In 2020, around one-ﬁfth of the total

road freight transport in the EU was carried out by

https://orcid.org/0000-0001-5371-0952

https://orcid.org/0000-0002-6679-3387

https://orcid.org/0009-0002-6288-7797

https://orcid.org/0000-0002-5740-2946

https://orcid.org/0000-0002-0358-3470

empty vehicles (Eurostat, 2021). Transport demand

is expected to greatly increase by 2050 (ITF, 2021).

The Physical Internet (PI) is a vision of how phys-

ical objects could be transported from a point of ori-

gin to a desired destination in a manner similar to the

routing of data packets on the digital Internet (Mon-

treuil, 2012). Here, freight loads are divided into

subcomponents that can take different paths through

an agile intermodal transportation network. This ap-

proach enables a higher utilization of transport vehi-

cles as well as a higher degree of resilience due to re-

dundant connections of transshipment points, and the

resulting scalability of the entire transport system.

Since the majority of freight transportation takes

place on the road, the potential for implementing a

road-based Physical Internet (RBPI) appears to be the

largest in this transport sector.

Research on the PI in the form of a cross-transport

carrier system has been going on for more than 10

years (Ballot et al., 2021; Montreuil, 2012). The

focus of research was directed to the RBPI with in-

Windolph, J., Kaup, S., Wehlitz, R., Franczyk, B. and Ludwig, A.

Adapting a Generic Smart Service Platform Architecture to the Road-Based Physical Internet.

DOI: 10.5220/0011987700003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 1, pages 749-756

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

749

Figure 1: ALICE Roadmap to Zero-Emission Logistics by 2050 (Liesa et al., 2020).

creased engagement of the automotive industry (Kaup

and Singer, 2016). In a next step, the gap to the last

mile was closed by the integration of crowd-delivery

into the RBPI (Kaup and Demircioglu, 2017). This

research has resulted in a concrete framework for the

RBPI (Kaup et al., 2021) that provides a basis for this

paper.

The goal of the RBPI is to reduce road freight traf-

ﬁc while maintaining the same transport volume with

fewer number of vehicles and at the same time im-

proved efﬁciency. Hence, this will lead to a higher

degree of scalability even in the event of an increase

in transport demand. In contrast to today’s processes

in transport logistics, where the routing of goods is

determined by proprietary forwarders, in the RBPI,

freight loads and freight components are forwarded

decentrally from network node to network node and

thus routed to the destination.

Digital logistics services related to the vi-

sion of the RBPI ”bring numerous advantages in

the optimization of integrated logistics ecosystems”

(Osm

olski et al., 2019). However, their technical

implementation requires suitable smart service plat-

forms. Such platforms leverage Internet of Things

(IoT) technologies as well as advanced data process-

ing and analytics capabilities to automatically ac-

quire, integrate, analyze and use transport-relevant

data beneﬁcially. In this paper, we propose to adapt

a generic smart service platform architecture, that al-

ready has proven itself in other ﬁelds of application,

to the RBPI in order to enable intelligent RBPI ser-

vices, such as dynamic routing of freight transports.

The remainder of this paper is structured as fol-

lows: Section 2 gives the background and current

state of the art in terms of smart service platform ar-

chitectures in the PI. In Section 3, the architectural

proposal adapted to the RBPI is presented. Finally,

conclusions were drawn in Section 4 with an outlook

to further work.

2 BACKGROUND

The main milestones of the PI are visualized in the

form of a roadmap in Figure 1 (Liesa et al., 2020).

This roadmap was created by European researchers

who are mostly part of the ‘Alliance for Logistics In-

novation for Collaboration in Europe’ (Ballot et al.,

2021). It describes the path of implementation to-

wards a sustainable logistics vision of zero emissions

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

750

for freight transport within Europe by 2050 (Liesa

et al., 2020). Important and yet unachieved imple-

mentation goals lie speciﬁcally in the area of In-

formation Systems (IS) for interconnected logistics.

Here, smart service platforms that enable full trans-

parency of supply chains and open logistics networks

are needed.

The current state of the art for smart service plat-

forms in the context of the PI is still in early stages of

development and implementation. Already existing

approaches aim to improve the efﬁciency and effec-

tiveness of logistics and supply chain management by

utilizing advanced technologies, such as IoT, artiﬁcial

intelligence, and blockchain.

Hasan et. al (2021) describe potential applica-

tions and beneﬁts of integrating blockchain technol-

ogy with the PI. The authors also compare two differ-

ent blockchain architectures they found most promis-

ing to meet PI service requirements. The work mainly

addresses decentralized and secure data exchange

within PI networks but does not cover data integration

and data analytics aspects that are crucial for intelli-

gent RBPI services.

Fahim et. al (2021) propose an information archi-

tecture for track-and-trace in the PI with the focus on

maritime ports. The architecture is based on the Ref-

erence Architecture Model for Industry 4.0 (RAMI

4.0) and concentrates on four layers. At the busi-

ness layer, logistics processes are deﬁned on an oper-

ational level. The functional layer comprises compo-

nents that process track-and-trace data and make them

available through a PI open interface system. The in-

formation layer is responsible for data exchange, stor-

age and quality assurance. The asset layer enables the

data acquisition for track-and-trace functionality. The

proposed architecture lacks technical details and also

does not consider data integration, processing and an-

alytics.

A service-oriented architecture (SOA) for creat-

ing IoT logistics services for the PI is described by

Tran-Dang and Kim (2018) and Tran-Dang et. al

(2020). The authors deﬁne IoT technologies as an im-

portant enabler in regard to the PI and view SOA as

a means to meet PI requirements best. Their proposal

extends across a physical layer, a network layer, a ser-

vice layer and an interface layer. The physical layer

comprises identiﬁcation, sensing and processing tech-

nologies to acquire transport-relevant data. The net-

work layer connects heterogeneous IoT devices and

allows for data exchange between them. In order

to integrate multiple heterogeneous resources the ser-

vice layer provides a middleware as well as logistics

and SOA infrastructure services. The interface layer

exposes services, e.g. through web services, so that

they can be accessed by the end users. Despite the

proposal addressing data integration, it is missing a

data analytics perspective that is needed to develop

sophisticated PI services. Furthermore, the publica-

tion only provides a high-level overview of the archi-

tecture.

Mededjel et. al (2021) propose a cloud-fog archi-

tecture to optimize the freight routing in the PI and to

increase visibility and traceability throughout supply

chains. It consists of an edge, fog and cloud layer.

At the edge layer, sensing data is collected as well as

preprocessed and transmitted through an IoT gateway.

The fog layer is responsible for the acquisition, aggre-

gation and processing of the data transmitted from the

edge layer. Data analytics and permanent data storage

are realized at the cloud layer. Overall, the authors

also describe a high-level architecture that is follow-

ing basic fog computing principles. Speciﬁc system

components to support the development and opera-

tions of intelligent PI services are not further consid-

ered.

Since the approaches mentioned above focus on

the PI in general and have their limitations and short-

comings, our goal is to investigate how a generic

smart service platform architecture, that has been

evaluated in other application domains, can be suc-

cessfully adapted to the RBPI. As a starting point, we

use preliminary work that was initially published in

2017 and originally addressed the smart energy do-

main (Wehlitz et al., 2017). The described architec-

ture comprises four core system areas, that are inter-

faces, data, services, and processes. The initial con-

cept and its system areas have been continuously en-

riched and developed over time. As an example, a

generic metadata model was introduced to abstract

implementation details on IoT devices and to enable

a uniﬁed access on them (Wehlitz et al., 2020). In ad-

dition, much emphasis has been placed on data pro-

cessing and data analytics capabilities in order to be

able to develop powerful smart services for different

use cases, e. g. smart home, weather and environ-

mental monitoring, as well as predictive maintenance

in industrial applications (Zsch

ornig et al., 2022). In

the following, we present a new and adapted version

of the mentioned smart service platform architecture

that addresses the technical implementation of the so

far conceptual RBPI and shall serve as a basis for fur-

ther discussions.

3 PLATFORM ARCHITECTURE

The proposed architecture is depicted in Figure 2 and

has ﬁve different functional layers: edge layer, inte-

Adapting a Generic Smart Service Platform Architecture to the Road-Based Physical Internet

751

Data Layer

Integration Layer

Middleware

Imports

Exports

Connector Connector ...

Edge Layer

Sensors Actuators

Communication Technologies

Connector Connector ...

Edge Processing Unit

Raw Data Processed Data

Streaming Platform

Metadata

Analytics Layer

Operator Operator ...

Pipelines

Smart Service Layer

Design

Module

Release

Module ...

Worker Worker ...

Flows

Cloud

Stratum

Fog

Stratum

Tags

Figure 2: Platform Architecture.

gration layer, data layer, analytics layer and smart

service layer. They serve the purpose of acquiring and

integrating data as well as processing and analyzing it

in order to derive meaningful insights that are the ba-

sis for intelligent RBPI services. Dividing the archi-

tecture into fog and cloud stratum follows the the fog

computing paradigm, in which computation may be

performed closer to the edge of the network in order

to improve latency, energy efﬁciency and bandwidth

usage (Mouradian et al., 2018; Abdali et al., 2021).

In the following, each of the layers, their interactions

and their relation to the RBPI will be described in a

bottom-up fashion.

3.1 Edge Layer

In the context of the RBPI, the edge layer’s main

purpose is to acquire, transmit and process transport-

relevant data inside vehicles. In addition to basic

vehicle data, such as its location and speed, this

also includes metadata about planned transport routes,

loaded freight items and the measurement of remain-

ing free capacity in the freight compartment. Free ca-

pacity can basically have two different dimensions:

volume and weight. When transporting fast moving

consumer goods, which is what the RBPI is almost al-

ways about, the volume limit is usually exhausted be-

fore the weight limit. Therefore, a volume-optimized

utilization of vehicles is desirable.

The edge layer is placed in the fog stratum and

comprises different edge components, that are sen-

sors, actuators, and tags that may support a variety of

different communication technologies, such as Wi-Fi,

ZigBee or Bluetooth Low Energy.

The seamless recording of transported goods can

be achieved by using camera-based sensors. The data

collected from these sensors can also be used to as-

sess whether a product or group of products, such

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

752

as those positioned on a pallet, can be stacked and

thus whether the space above them can be used for

other goods. Alternatively, ultrasonic or ‘light de-

tection and ranging’ (LiDAR) sensor systems can be

used. Ultrasonic sensors are easy to integrate into the

cargo space of transport vehicles, but can only detect

the outline of the cargo space. LiDAR, on the other

hand, has a good range of environment detection and

good 3-D characteristics, but is comparatively expen-

sive and complex. The identiﬁcation of freight objects

can be achieved by means of AUTO-ID methods that

use tags with different underlying technologies such

as QR codes, RFID or NFC tags or bluetooth beacons.

Another important category of edge components

includes actuators. For example, an actuator might be

used to enable remote access to a vehicle in order to

allow for unattended transport goods exchange. Fur-

thermore, they are used to secure loads, i.e. to protect

cargo against slipping and damage. This can be real-

ized by variably adjusting a matrix of piezoresistive

expansion actuators that create a 3-D contour in the

cargo space that conforms to the shape of the loaded

cargo, and thereby securing it (Kaup et al., 2021).

The mentioned edge components are connected to

an edge processing unit through hard- and software

connectors that enable different communication tech-

nologies and protocols. The edge processing unit not

only serves as a connection point between the fog

stratum and other layers in the cloud stratum for data

forwarding, but also provides the option for data ana-

lytics at the edge level based on speciﬁc edge device

processing capabilities.

Gradually, vehicles are being equipped with more

and more computing power in the form of vehicle

processing units, not least because of the require-

ments arising from autonomous driving. These com-

puting resources might serve as a suitable base for an

edge processing unit. In respect to the RBPI, possi-

ble analytics tasks are the aggregation and ﬁltering of

sensor data to reduce the required bandwidth during

the transmission to cloud backends, the encryption,

anonymization and pseudonymization of data for pri-

vacy and security reasons as well trafﬁc-related algo-

rithms such as route planning or arrival time estima-

tions.

3.2 Integration Layer

The integration layer addresses the registration, con-

nection and management of heterogeneous edge com-

ponents of different vendors as well as the communi-

cation between the fog and the cloud stratum of the ar-

chitecture. It also enables the integration of data from

third-party systems using imports, e.g. for integrating

data of supply chain management and ﬂeet manage-

ment systems or open data providers, such as trafﬁc

data services. Imports must ﬁrst be implemented as

an import type that addresses the speciﬁc format and

protocol used by the data source. The import type

must then be registered with the platform. After these

preliminary steps, imports can be conﬁgured and in-

stantiated (Windolph et al., 2021).

On the other hand, the integration layer allows

data access for external systems using exports. An ex-

port collects raw or processed data from the data layer

and makes it available to external systems. Analogous

to imports, exports may use a variety of different tar-

get formats and protocols in order to support a wide

range of external systems. The middleware translates

incoming messages (e. g. sensor data) into a uniﬁed

platform-internal message format using metadata and

connectors, and stores the data at the data layer. The

middleware also retranslates outgoing messages (e.g.

control commands to actuators) into device-speciﬁc

requests that are handled by the edge layer.

In terms of the RBPI, the integration layer refers

to the integration of all the systems and technologies

that are part of the RBPI. These include, for exam-

ple, available transshipment points and additional ren-

dezvous points identiﬁed by vehicles, but also infor-

mation about the vehicles themselves, their currently

loaded transport goods, available routes, the condi-

tions of the roads and the toll sections along them.

This data is so far stored in a variety of different iso-

lated systems. The integration layer now enables the

combined processing of all these different sorts of

data.

3.3 Data Layer

The data layer stores all raw and processed data in

a streaming platform that provides access to the data

for other layers. In the scalable streaming platform

raw sensor data and processed analytics data is stored

in topics that multiple platform components can use

at the same time by publish and subscribe mecha-

nisms. Playback of historical data in the original or-

der as well as the consumption of real-time data is

possible. In contrast to typical database access, data

is processed one message at a time.

The metadata required for the integration of het-

erogeneous sensors and actuators is stored in this

layer as well. In contrast to the raw sensor data, this

metadata is stored outside of the streaming platform

to enable access to them without having to imple-

ment a streaming client. Metadata is described by a

purpose-built model that eases the integration of sen-

sor data and actuator control through semantic inte-

Adapting a Generic Smart Service Platform Architecture to the Road-Based Physical Internet

753

gration (Wehlitz et al., 2020).

Concerning the RBPI, the data layer refers to the

data that is collected by the various systems and tech-

nologies of the physical internet. This data includes

the location of vehicles, the speed of vehicles, the traf-

ﬁc conditions, and the utilization of cargo spaces. It

also refers to the metadata of vehicles, transport goods

and the road infrastructure.

3.4 Analytics Layer

The analytics layer refers to the software and hard-

ware infrastructure that enables the analysis of all data

collected by the integration layer and stored at the

data layer. In the analytics layer, pipelines are used to

analyze the data collected by vehicles and other com-

ponents of the road infrastructure. Analytics pipelines

are designed as analytics ﬂows and constituted of

one or more analytics operators. An analytics op-

erator consumes data from the streaming platform,

performs a speciﬁc analytics task and writes the re-

sults back to the streaming platform (Zsch

ornig et al.,

2020; Zsch

ornig et al., 2022). From there, they can

be used in other layers, but also reused in other ana-

lytics pipelines to avoid redundant processing. Chain-

ing multiple analytics operators enables the creation

of complex analytics pipelines, while the segmenta-

tion of complex tasks into multiple analytics opera-

tors allows horizontal scaling of analytics pipelines

and the reuse of analytics operators in different an-

alytics ﬂows. Analytics pipelines can be deployed

in cloud, hybrid or fog fashion to address use case-

speciﬁc processing requirements and edge processing

unit capabilities.

In regards to the RPBI, the analytics layer could

be used to implement algorithms that predict trafﬁc

congestion and systems that forecast trafﬁc accidents,

but also algorithms that provide data aggregation and

anonymization to ensure data protection. Combin-

ing these analytics results into a complex analytics

pipeline could enable a system that determines the op-

timal route for a vehicle.

3.5 Smart Service Layer

The smart service layer simpliﬁes the implementation

of complex use cases by combining all other layer

functionalities in order to allow for the orchestration

of data integration, data analytics and actuator con-

trol. When creating a smart service, the ﬁrst step is

to model it as a design. A design consists of multiple

tasks that need to be run in order to prepare all re-

sources that are required for a speciﬁc use case. Once

a design has been created, it can be prepared for use

by creating a release. Releases are versioned designs,

which enables update mechanics. After a release has

been made, users can deploy it as a smart service in-

stance. If a smart service uses additional conﬁgura-

tions, such as the selection of a speciﬁc sensor, this

conﬁguration has to be provided during this step.

If a smart service requires the instantiation

of other platform resources, such as an analytics

pipeline, this task is handled by resource-speciﬁc

smart service workers that instantiate the resource and

save a reference to it in a smart service module. Us-

ing this approach allows for other workers to further

use instantiated resources (e.g. an export could make

results of an analytics pipeline accessible for external

systems). Referencing all resources in modules also

enables deleting them once the smart service instance

is discarded.

The smart service layer would serve as the inter-

face between the smart service platform and its users.

In this layer, intelligent RBPI services, such as route

planning, trafﬁc monitoring and incident management

could be developed, evaluated and provided to the

user. Using this layer of the architecture has the po-

tential to conceal complex implementation details of

the RBPI to users by reducing the required contact

points, resulting in an improved usability of the over-

all platform.

4 CONCLUSION AND OUTLOOK

The RBPI vision is expected to have great potential

to revolutionize road-based transportation in terms of

increased efﬁciency, robustness, scalability, and sus-

tainability. By providing a reliable, high-speed sens-

ing and communication infrastructure in combina-

tion with a suitable smart service platform, intelligent

RBPI services enable vehicles to share data and coop-

erate with each other in order to optimize trafﬁc ﬂow,

reduce congestion, and improve safety.

However, research in the ﬁeld of RBPI is still in

its beginning stage and almost always theoretical in

nature. In this paper, we propose an adapted version

of a generic smart service platform architecture that

aims to bring the RBPI a step closer to its technical

realization.

As future work, the individual layers of the pro-

posed architecture need to be detailed and investi-

gated deeper. Furthermore, each of them as well

as their interaction as a whole have to be evaluated

against the speciﬁc requirements of the RBPI. Think-

ing ahead, a possible extension could be direct com-

munication between multiple edge processing units in

local ad-hoc networks to enable additional use cases

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

754

such as handling freight exchange among each other

in the near distance or to compensate for the outage

of a cloud connection.

ACKNOWLEDGEMENTS

The work presented in this paper represents results

by the Institute for Applied Informatics (InfAI) and

Mercedes-Benz AG on the research project ‘Require-

ments and Application of GAIA-X in the Edge-

Device Automobile’ (GAIA-X 4 AGEDA) that is

partly funded by the German Federal Ministry for

Economic Affairs and Climate Protection (BMWK

19S22004P). The sole responsibility for the content

lies with the authors.

REFERENCES

Abdali, T.-A. N., Hassan, R., Aman, A. H. M., and Nguyen,

Q. N. (2021). Fog Computing Advancement: Con-

cept, Architecture, Applications, Advantages, and

Open Issues. IEEE Access, 9:75961–75980. https:

//doi.org/10.1109/access.2021.3081770.

Ballot, E., Barbarino, S., van Bree, B., Liesa, F.,

Rod Franklin, J., ‘t Hooft, D., Nettstr

ater, A., Pa-

ganelli, P., and A. Tavasszy, L. (2021). Roadmap to

The Physical Internet. http://www.etp-logistics.eu/

wp-content/uploads/2020/11/Roadmap-to-Physica

l-Intenet-Executive-Version Final.pdf, Accessed 25

January 2023.

Eurostat (2021). A ﬁfth of road freight kilometres by empty

vehicle. https://ec.europa.eu/eurostat/web/produc

ts-eurostat-news/-/ddn- 20211210-1, Accessed 25

January 2023.

Eurostat (2022). Modal split of freight transport. https:

//ec.europa.eu/eurostat/databrowser/view/tran hv frm

od/default/table?lang=en, Accessed 25 January 2023.

Fahim, P. B., An, R., Rezaei, J., Pang, Y., Montreuil, B., and

Tavasszy, L. (2021). An information architecture to

enable track-and-trace capability in Physical Internet

ports. Computers in Industry, 129:103443. https://do

i.org/10.1016/j.compind.2021.103443.

Hasan, H. R., Salah, K., Jayaraman, R., Yaqoob, I., and

Omar, M. (2021). Blockchain Architectures for Phys-

ical Internet: A Vision, Features, Requirements, and

Applications. IEEE Network, 35(2):174–181. https:

//doi.org/10.1109/mnet.021.2000442.

ITF (2021). ITF Transport Outlook 2021. OECD. https:

//doi.org/10.1787/16826a30-en.

Kaup, S. and Demircioglu, A. V. (2017). Von der Crowd-

Logistik hin zu einem ganzheitlichen Ansatz hochef-

ﬁzienten Warentransports. Wirtschaftsinformatik &

Management, 9(3):18–27. https://doi.org/10.1007/

s35764-017-0052-z.

Kaup, S., Ludwig, A., and Franczyk, B. (2021). Framework

Artifact for the Road-Based Physical Internet based on

Internet Protocols. https://arxiv.org/abs/2106.08286.

Kaup, S. and Singer, E. (2016). Logistics in 2050: Hitch-

hiking through the Physical Internet. Mercedes-Benz

NeXt – The Innovation Magazine, 01/2016:6–13. http

s://ﬁgshare.com/articles/journal contribution/Logistic

s in 2050 Hitch-hiking through the Physical Interne

t/13489563, Accessed 25 January 2023.

Laurent,

E. (2020). The European Green Deal: from

growth-strategy to social-ecological transition? So-

cial policy in the European Union: state of play, pages

97–110.

Liesa, F., ‘t Hooft, D., and Ilves, I. (2020). Physical Internet

Roadmap. https://www.etp-logistics.eu/, Accessed 25

January 2023.

Mededjel, M., Belalem, G., and Neki, A. (2021). A cloud-

fog architecture for physical-internet-enabled supply

chain. Supply Chain Forum: An International Jour-

nal, 23(3):307–322. https://doi.org/10.1080/162583

12.2021.1996861.

Montreuil, B. (2012). Physical Internet Manifesto, Version

1.11. 1. https://www.slideshare.net/physical interne

t/physical-internet-manifesto-eng-version-1111-201

21119-15252441, Accessed 25 January 2023.

Mouradian, C., Naboulsi, D., Yangui, S., Glitho, R. H.,

Morrow, M. J., and Polakos, P. A. (2018). A Com-

prehensive Survey on Fog Computing: State-of-the-

Art and Research Challenges. IEEE Communications

Surveys & Tutorials, 20(1):416–464. https://doi.org/

10.1109/comst.2017.2771153.

Osm

olski, W., , Voronina, R., Koli

nski, A., and and (2019).

Veriﬁcation of the Possibilities of Applying the Princi-

ples of the Physical in Economic Practice. Logforum,

15(1):7–17. https://doi.org/10.17270/j.log.2019.310.

Tran-Dang, H. and Kim, D.-S. (2018). An Information

Framework for Internet of Things Services in Phys-

ical Internet. IEEE Access, 6:43967–43977. https:

//doi.org/10.1109/access.2018.2864310.

Tran-Dang, H., Krommenacker, N., Charpentier, P., and

Kim, D.-S. (2020). Toward the Internet of Things for

Physical Internet: Perspectives and Challenges. IEEE

Internet of Things Journal, 7(6):4711–4736. https:

//doi.org/10.1109/jiot.2020.2971736.

Wehlitz, R., H

aberlein, D., Zsch

ornig, T., and Franczyk,

B. (2017). A Smart Energy Platform for the Inter-

net of Things – Motivation, Challenges, and Solu-

tion Proposal. In Business Information Systems, pages

271–282. Springer International Publishing. https:

//doi.org/10.1007/978-3-319-59336-4 19.

Wehlitz, R., Jauer, F., R

oßner, I., and Franczyk, B. (2020).

Increasing the Reusability of IoT-aware Business Pro-

cesses. In Position Papers of the 2020 Federated Con-

ference on Computer Science and Information Sys-

tems. PTI. https://doi.org/10.15439/2020f209.

Windolph, J., Wehlitz, R., Zsch

ornig, T., and Franczyk, B.

(2021). Integrating External Data Sources into Inter-

net of Things Architectures for Weather and Environ-

mental Monitoring in Former Mining Areas. In IN-

Adapting a Generic Smart Service Platform Architecture to the Road-Based Physical Internet

755

FORMATIK 2021. Gesellschaft f

ur Informatik, Bonn.

http://dl.gi.de/handle/20.500.12116/37730.

Zsch

ornig, T., Windolph, J., Wehlitz, R., Dumont, Y., and

Franczyk, B. (2022). A Fog-Based Multi-Purpose In-

ternet of Things Analytics Platform. SN Computer

Science, 3(3). https://doi.org/10.1007/s42979-022

-01110-3.

Zsch

ornig, T., Windolph, J., Wehlitz, R., and Franczyk,

B. (2020). A Cloud-based Analytics-Platform for

User-centric Internet of Things Domains – Prototype

and Performance Evaluation. In Proceedings of the

Annual Hawaii International Conference on System

Sciences. Hawaii International Conference on System

Sciences. https://doi.org/10.24251/hicss.2020.808.

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

756