Inter
national
J
our
nal
of
Inf
ormatics
and
Communication
T
echnology
(IJ-ICT)
V
ol.
14,
No.
1,
April
2025,
pp.
334
∼
346
ISSN:
2252-8776,
DOI:
10.11591/ijece.v14i1.pp334-346
❒
334
Conceptualization
of
IoT
ar
chitectur
es
Gaetanino
P
aolone
1
,
Romolo
P
aesani
2
,
J
acopo
Camplone
1
,
Andr
ea
Piazza
1
,
P
aolino
Di
F
elice
3
1
B2B
S.r
.l.,
T
eramo,
Italy
2
Gruppo
SI
S.c.a.r
.l.,
T
eramo,
Italy
3
Department
of
Industrial
and
Information
Engineering
and
Economics,
Uni
v
ersity
of
L
’Aquila,
L
’Aquila,
Italy
Article
Inf
o
Article
history:
Recei
v
ed
Jun
17,
2024
Re
vised
Oct
14,
2024
Accepted
No
v
19,
2024
K
eyw
ords:
Archiecture
vie
wpoint
Architecture
description
Frame
w
ork
Internet
of
things
Stak
eholder
perspecti
v
e
Stak
eholder
Standard
ABSTRA
CT
Although
there
is
a
lar
ge
interest
about
int
ernet
of
things
(IoT)
architectures,
still
there
is
no
consensus
on
their
conceptualization
in
the
e
xtant
literature.
This
lack
of
information
in
conceptualization
is
problematic
because
it
hampers
the
deep
understanding
of
the
appeared
proposals,
as
well
as
the
adoption
of
a
shared
w
orko
w
by
the
in
v
olv
ed
architects
of
these
systems.
Thus,
a
concise
and
agreed-upon
conceptualization
of
IoT
architectures
is
call
ed
for
.
This
paper
aims
at
gi
ving
a
contrib
ution
on
the
topic.
W
e
start
by
re
vie
wing
the
a
v
ailable
standards,
then,
in
light
of
their
suggestions,
a
w
orko
w
to
be
follo
wed
in
the
denition
of
the
architecture
descriptions
(ADs)
of
IoT
s
ystems
is
detailed
and,
in
addition,
a
sample
case
study
,
which
implements
that
w
orko
w
,
is
proposed.
The
contrib
utions
are
suf
ciently
abstract
to
be
applicable
also
to
the
description
of
the
architecture
of
articial
intelligence
of
things
(AIoT)
systems.
This
is
an
open
access
article
under
the
CC
BY
-SA
license
.
Corresponding
A
uthor:
P
aolino
Di
Felice
Department
of
Industrial
and
Information
Engineering
and
Economics,
Uni
v
ersity
of
L
’Aquila
L
’Aquila,
Italy
Email:
paolino.difelice@uni
v
aq.it
1.
INTR
ODUCTION
This
section
starts
by
introducing
the
internet
of
things
(IoT).
Then,
the
role
of
architecture
description
(ADs)
is
emphesized
as
the
means
to
manage
the
comple
xity
of
IoT
-based
systems.
Gap
identication
and
contrib
utions
of
the
study
are
successi
v
ely
gi
v
en;
while
paper’
s
structure
ends
the
section.
The
IoT
is
a
netw
ork
of
ph
ysical
de
vices,
interf
aces,
and
other
items
embedded
with
sensors,
ac-
tuators,
electronics,
and
connecti
vity
.
The
number
of
IoT
connected
de
vices
w
orldwide
in
2023
w
as
15.14
billions
(source:
https://www
.statista.com/statistics/1183457/
iot-connected-de
vices-w
orldwide/
-accessed
11
April,
2024).
An
IoT
infrastructure
includes
the
follo
wing
basic
components:
-
Sensors
(the
y
g
ather
real-time
data
from
the
en
vironment
and
con
v
ert
it
into
a
digital
signal),
-
Microcontrollers
(the
y
process
and
manage
the
data
collected
by
the
sensors),
-
Communication
modules
(the
y
transmit
the
data
o
v
er
the
netw
ork),
and
-
Cloud
(it
of
fers
infrastructures,
serv
ers
and
storage,
needed
for
the
data
processing).
Data
is
only
useful
if
it
creates
an
action.
T
o
mak
e
data
truly
actionable,
it
needs
to
be
s
up
pl
emented
with
conte
xt.
Articial
intelligence
(AI)
and
IoT
together
(shortly
,
articial
intelligence
of
things
(AIoT))
are
the
conte
xt
[1],
[2].
Combining
IoT
with
AI
technologies
can
create
“smart
machines”
able
to
mak
e
decisions
with
little
or
no
human
interv
ention.
The
benets
deri
ving
from
the
marriage
of
AI
and
IoT
ha
v
e
been
highlighted
for
all
IoT
application
domains.
Hereafter
we
will
talk
generically
of
IoT
,
b
ut
with
fe
w
e
xceptions,
that
will
be
clear
from
the
conte
xt,
the
reasonings
embrace
also
the
AIoT
.
J
ournal
homepage:
http://ijict.iaescor
e
.com
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Inf
&
Commun
T
echnol
ISSN:
2252-8776
❒
335
The
comple
xity
of
IoT
systems
has
gro
wn
to
an
unprecedented
le
v
el.
This
has
created
ne
w
oppor
-
tunities,
b
ut
at
the
prize
of
a
long
list
of
challenges
for
the
stak
eholders
that
create
and/or
use
these
systems.
Stak
eholders
interests
about
thes
e
systems
are
e
xpressed
as
concerns
about
them.
Concerns
are
the
result
of
the
stak
eholders’
perspecti
v
es,
the
latter
originating
from
domain
kno
wledge,
skill,
responsibility
and
role
played
in
the
or
g
anization.
In
academia
and
industry
,
architecting
IoT
syst
ems
is
usually
proposed
to
help
manage
the
comple
xity
f
aced
by
the
in
v
olv
ed
stak
eholders.
This
claim
is
pro
v
ed
by
the
high
number
of
distinct
IoT
architectures
that
ha
v
e
been
already
published.
F
or
instance,
Alshohoumi
et
al.
[3]
analyzed
148
studies
and
identied
sixteen
dif
ferent
architectures.
Because
of
the
high
number
of
proposals,
IoT
architectures
ha
v
e
been
classied
ac-
cording
to:
(i)
the
pro
v
enance
(academia
or
industry);
(ii)
the
appli
cation
domain;
and
(iii)
the
style
(layered,
service-oriented,
middle
w
are-oriented,
and
computing-paradigm-oriented)
[4]-[6].
As
a
quite
ob
vious
conse-
quence
of
the
v
ariety
of
a
v
ailable
distinct
solutions,
the
terms
adopted
in
the
description
of
IoT
architectures
v
ary
considerably
from
one
technological
solution
to
the
other
[7].
This
issue
is
conrmed
by
the
w
ork
by
W
ang
et
al.
[8],
carried
out
a
deep
re
vie
w
of
20
highly
cited
papers
on
the
basic
(“functional”)
components
of
the
IoT
.
71
distinct
sentences
result
ed
to
be
used
to
denote
those
components,
b
ut
there
were
man
y
o
v
erlapping
and
duplicate
w
ords
among
them.
The
71
sentences
were
di
vided
into
the
follo
wing
v
e
independent
sets:
smart
de
vice,
perception,
cloud,
transportation,
and
application.
Accordingly
,
the
authors
concluded
that
the
predominant
IoT
systems
are
composed
of
v
e
parts:
a
de
vice
layer
,
a
perception
layer
,
a
cloud
layer
,
a
transport
layer
,
and
an
application
layer
.
The
e
xamination
of
the
e
xtant
literature
on
architect
ures
highlights
tw
o
opposing
attitudes.
In
one
(e
xpressed
by
the
minority
of
scholars),
it
is
dreamed
a
unique
IoT
architecture
which
is
acce
p
t
able
for
all
applications
[9],
[10].
In
the
other
,
the
claim
is
that
a
single
architecture
is
not
enough
for
abstracting
the
di
v
erse
needs
of
all
the
potential
IoT
applications
[4]-[6],
[11]-[16].
As
pre
viously
said,
most
pu
bl
ished
research
studies
belonging
to
the
IoT
domain
talk
about
ar
chitectures
of
these
heterogeneous
systems,
b
ut
too
often
there
is
no
information
on
the
stak
eholders
the
proposal
is
intended
to
reach,
on
the
concerns
the
proposal
addresses,
and
neither
,
and
e
v
en
w
orse,
on
the
process
ho
w
the
proposal
is
b
uilt.
In
this
paper
,
we
use
the
term
conceptualization
to
refer
to
such
a
process.
Collins
English
Dictionary
denes
conceptualization
as
“The
process
of
forming
a
concept
out
of
observ
ations,
e
xperience,
and
data.
”
The
position
e
xpressed
in
this
w
ork
is
in
line
with
the
pre
v
ailing
one
mentioned
abo
v
e,
b
ut
the
basic
assumption
of
our
study
is
that
the
AD
must
be
guided
by
a
deterministic
w
orko
w
that
implements
the
stages
en
visaged
by
an
architectural
frame
w
ork
shared
by
the
scientic
community
.
Moreo
v
er
,
the
steps
of
the
w
orko
w
must
highlight
the
stak
eholders
to
whom
the
description
of
the
architecture
is
addressed
and
the
concerns
that
the
latter
intercepts.
Specically:
-
W
e
recall
the
fundamentals
of
the
ISO/IEC/IEEE
42010
standard
published
in
2022
[17]
that
has
replaced
the
ISO/IEC/IEEE
42010:2011;
-
Then,
three
distinct
proposals
based
on
[17]
are
summarized:
the
ISO/IEC
30141:2018
standard
elaborated
by
the
international
or
g
anization
for
standardization
(ISO)
and
the
international
electrotechnical
commis-
sion
(IEC)
joint
technical
committee
1:
information
technology
[18];
the
IEEE
Std
2413-2019
standard
elaborated
by
the
IEEE
SA
standards
board
[19],
and
the
report
by
the
industrial
internet
consortium
(IIC)
[20].
-
The
comparati
v
e
study
of
the
four
documents
allo
wed
us
to
highlight
ho
w
the
recommendations
in
the
ISO/IEC/IEEE
42010
standard
ha
v
e
been
implemented
in
the
subsequent
three
proposals.
-
It
w
as,
also,
possible
to
dene
the
deterministic
w
orko
w
comprising
the
stages
en
visaged
by
the
architec-
tural
frame
w
ork
shared
among
the
recalled
four
proposals.
-
Finally
,
a
case
study
,
brok
en
do
wn
into
the
steps
that
mak
e
up
the
dened
w
orko
w
,
is
sk
etched.
The
paper
is
structured
as
follo
ws.
Section
2
recalls
the
related
w
ork;
while
section
3
presents
the
research
method
of
this
study;
then
section
4
summarizes
the
results.
The
enucleation
of
the
w
orko
w
that
lists
the
sequence
of
stages
in
the
production
of
the
artif
acts
that
describe
the
IoT
system
to
be
de
v
eloped
is
part
of
the
section.
Section
5
applies
the
w
orko
w
to
a
case
study;
e
v
entually
,
section
6
ends
the
paper
.
2.
RELA
TED
W
ORKS
This
section
recalls
three
studies
that
before
ours
ha
v
e
pointed
out
the
need
to
bring
order
to
the
dispersed
body
of
kno
wledge
about
IoT
architectures.
W
e
didn’
t
spend
further
time
to
search
for
other
studies
Conceptualization
of
IoT
ar
c
hitectur
es
(P
aolone)
Evaluation Warning : The document was created with Spire.PDF for Python.
336
❒
ISSN:
2252-8776
that
could
had
e
xpressed
the
same
position,
simply
because
we
considered
the
rele
v
ance
of
the
three
selected
papers
suf
cient
to
moti
v
ate
our
w
ork.
The
common
basic
assumption
of
the
three
selected
w
orks
is
that
to
understand
the
a
v
ailable
proposals
and
maps
similarities
and
dif
ferences
among
them,
it
is
necessary
to
adopt
an
IoT
standard
reference
architecture.
The
need
to
refer
to
a
shared
w
orko
w
in
the
construction
of
architecture
vie
ws
that
intersect
specic
stak
eholders’
concerns
is
not
mentioned
in
those
studies.
In
other
w
ords,
the
y
ha
v
e
tak
en
a
direction
independent
of
the
philosoph
y
embedded
in
the
ISO/IEC/IEEE
42010
standard
[17],
on
which
our
study
is
based.
Muccini
et
al.
[4]
carried
out
a
systematic
mapping
study
on
IoT
architectural
styles
i
n
order
to
identifying
characteristics
and
publication
trends.
The
y
selected
63
papers
out
of
about
2,300
possible
choices.
Then,
the
y
classied
the
architectural
styles
as
a
set
of
abstract
IoT
reference
architectures.
Di
Martino
et
al.
[7],
pro
vide
a
re
vie
w
of
the
most
common
IoT
architectural
solutions
a
v
ailable
up
to
2018.
Extant
commercial
proposals
and
tw
o
standards
were
tak
en
into
account
in
the
study
.
In
detail,
authors
adopted
the
layered-functional
architecture
proposed
in
[21]
as
a
reference
architecture
to
analyze
and
compare
the
reference
architectures
introduced,
respecti
v
ely
,
in
the
standards
[18],
[22].
Ame
yed
et
al.
[23],
authors
carried
out
a
qualitati
v
e
and
quantitati
v
e
comparati
v
e
analysis
of
four
commercial
architectures
(namely
,
Intel,
Microsoft,
Cisco,
and
Google)
ag
ainst
the
Domain-based
model
part
of
the
ISO/IEC
30141
reference
IoT
arc
hitecture
[18].
The
assessment
w
as
carried
out
by
means
of
an
e
v
alu-
ation
frame
w
ork
based
on
quantitati
v
e
metrics
and
scoring
methods
proposed
b
y
authors.
The
nal
aim
of
the
study
w
as
to
map
the
similarities
and
dif
ferences
of
the
commercial
solutions.
3.
RESEARCH
METHOD
The
method
utilized
in
this
study
in
v
olv
ed
a
detailed
e
xamination
of
pre
vious
ef
forts
to
dene
guide-
lines
for
promoting
the
conceptualization
of
the
IoT
architecture.
The
w
orko
w
of
the
research
method
looking
for
issued
standards’
proposals
is
illustrated
in
Figure
1.
This
section
comprises
four
sub-sections
as
man
y
are
the
e
xtant
proposals,
[17]-[20].
Each
sub-section
pro
vides,
in
sequence,
a
primer
of
the
conceptual
frame
w
ork
gi
v
en
in
those
documents.
The
comparison
of
the
four
proposals
is
the
subject
of
ne
xt
section.
Figure
1.
The
research
method
w
orko
w
3.1.
The
ISO/IEC/IEEE
42010:2022
standard
This
standard
introduces
the
guidelines
useful
for
describing
architectures
of
comple
x
systems
(the
latter
generically
called
entity
of
interest
in
the
document).
Stak
eholders,
stak
eholder
perspecti
v
es,
stak
eholder
concerns,
ADs
are
the
main
concepts
at
the
bottom
of
such
a
standard.
Hereafter
,
the
y
are
briey
recalled.
Int
J
Inf
&
Commun
T
echnol,
V
ol.
14,
No.
1,
April
2025:
334-346
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Inf
&
Commun
T
echnol
ISSN:
2252-8776
❒
337
3.1.1.
Ar
chitectur
e
descriptions
The
architecture
of
an
entity
of
interest,
e
xpressed
by
one
or
more
ADs,
assist
s
in
understanding
the
basic
concepts
or
properties
of
the
entity
,
referring,
for
instance,
to
its
structure
and
beha
vior
.
ADs
are
useful
to
i
mpro
v
e
communication
and
cooperation
among
stak
eholders.
Figure
2
depicts
the
relationships
among
the
basic
concepts
this
standard
relies
on.
The
entry
point
in
the
conceptual
graph
is
the
stak
eholder
concept.
Figure
2.
The
graph
about
the
main
concepts
(the
nodes)
and
their
relationships
(the
edges)
in
the
ISO/IEC/IEEE
42010:2022
standard
[17]
A
stak
eholder
is
an
indi
vidual
or
an
or
g
anization
ha
ving
an
interest
or
a
right
in
an
entity
of
inte
rest.
End
users,
operators,
o
wners,
suppliers,
architects,
de
v
elopers,
b
uilders,
maintainers,
certifying
agencies
are
e
xamples
of
stak
eholders.
W
ithin
this
paper
,
IoT
systems
are
the
entity
of
interest.
Entity
of
interests
are
situated
in
an
en
vironment;
the
latter
can
ha
v
e
v
arious
inuences
upon
them
[17].
Interest
in
an
entity
comprises
interest
in
its
en
vironment,
requirements,
architecture,
design,
implementation,
operation,
and
life
c
ycle.
Aspects,
concerns
and
stak
eholder
perspecti
v
es
allo
w
to
e
xpress
such
interests.
A
stak
eholder
pers
pec-
ti
v
e
is
a
w
ay
of
thinking
about
an
entity
of
interest.
Rele
v
ant
perspecti
v
es
include:
strate
gic,
or
g
anizational,
operational,
logical,
ph
ysical
and
technological
ones.
Perspecti
v
es
result
in
concerns.
A
concern
is
a
matter
of
rele
v
ance
to
a
stak
eholder
.
Architecture
vie
wpoints
comprise
con
v
entions
necessary
for
the
creation,
interpre-
tation
and
use
of
architecture
vie
ws
in
order
to
frame
concerns.
An
architecture
vie
w
constitutes
a
portion
of
an
AD,
the
latter
being
an
artif
act
that
e
xpresses
an
architecture
to
be
pro
vided
to
the
stak
eholders.
An
AD
may
contain
more
architecture
vie
ws.
Or
g
anizing
ADs
into
architecture
vie
ws
go
v
erned
by
architecture
vie
wpoints
allo
ws
the
separation
of
concerns
based
on
stak
eholders
perspecti
v
es,
pro
viding,
at
the
same
time,
an
inte
grated
vie
w
of
the
whole
entity
.
3.1.2.
Ar
chitectur
e
description
framew
orks
An
ADF
re
g
ards
a
set
of
best
practices
for
creating,
int
erpreting,
analyzing
and
using
ADs
within
a
particular
domain
of
interest.
In
ot
her
w
ords,
according
to
the
ISO/IEC/IEEE
42010:2022
standard,
an
ADF
is
the
umbrella
under
which
ADs
must
be
done.
Figure
3
sho
ws
the
UM
L
class
diagram
collecting
the
concepts
that
all
together
are
referred
to
as
ADF
in
[17],
namely:
domain
of
interest,
concerns,
stak
eholders,
vie
wpoints,
and
model
kinds.
Model
kind
is
a
set
of
con
v
entions
for
the
formali
zation
of
concerns,
while
a
Model
is
the
artif
act
produced
by
applying
a
specic
model
kind
(e.g.,
UML).
An
architecture
v
i
e
wpoint
may
specify
se
v
eral
model
kinds.
Conceptualization
of
IoT
ar
c
hitectur
es
(P
aolone)
Evaluation Warning : The document was created with Spire.PDF for Python.
338
❒
ISSN:
2252-8776
Figure
3.
The
conceptual
model
of
the
ADF
dened
in
[17]
Figure
4
sho
ws
a
meta
e
xample
about
the
basic
concepts
part
of
the
ISO/IEC/IEEE
42010
standard.
T
w
o
stak
eholders
are
inte
rested
in
the
same
entity
of
i
nterest
(a
smart
city).
Both
ha
v
e
perspect
i
v
e
vie
wpoints
about
the
entity
of
interest.
From
each
perspecti
v
e
originates
an
architecture
vie
wpoint
that,
i
n
turn,
gi
v
es
rise
to
an
architecture
vie
w
.
Figure
4.
A
meta
e
xample
depicting
the
mapping
from
the
ADF
to
ADs
3.2.
The
ISO/IEC
30141:2018
standard
This
standard
has
the
follo
wing
merits:
(i)
it
is
technology-neutral;
(ii)
it
gi
v
es
a
clear
picture
of
IoT
systems
to
the
in
v
olv
ed
stak
eholders;
(iii)
it
simplies
the
communication
between
them.
Ov
erall,
ISO/IEC
30141:2018
[18]
con
v
e
ys
useful
advices
to
the
IoT
architect
to
b
uild
his
o
wn
ADs
as
meant
in
the
pre
vious
sub-
section
and
then
actual
systems.
IoT
characteristics,
conceptual
model,
and
reference
model
are
the
constituent
pillars
of
this
standard
(Figure
5).
The
y
are
recalled
belo
w
.
Int
J
Inf
&
Commun
T
echnol,
V
ol.
14,
No.
1,
April
2025:
334-346
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Inf
&
Commun
T
echnol
ISSN:
2252-8776
❒
339
Figure
5.
The
structure
of
the
ISO/IEC
30141:2018
standard
T
able
1
collects
the
most
rele
v
ant
IoT
characteristics.
The
concept
ual
model
abstracts
these
charact
er
-
istics.
It
is
presented
by
means
of
UML
class
diagrams
concerning
concepts
as:
virtual/ph
ysical
entities;
IoT
de
vices;
IoT
users;
IoT
g
ate
w
ays;
the
netw
ork,
the
services.
The
reference
model
is
presented
from
tw
o
com-
plementary
perspecti
v
es:
the
rst
(perspecti
v
e)
is
entity-based
(IoT
users,
IoT
g
ate
w
ays,
IoT
de
vices,
netw
orks,
ph
ysical
entities
are
e
xamples
of
entities),
while
the
second
one
is
domain-based.
The
identied
domains
are:
user
domain,
operations/management
domain,
application/service
domain,
resource
access
and
interchange
domain,
sensing
and
controlling
domain,
and
ph
ysical
entity
domain.
T
able
1.
Characteristics
of
IoT
systems
according
to
[18]
T
rustw
orthiness
Architecture
Functional
A
v
ailability
Composability
Accurac
y
Condentiality
Functional
and
management
capability
separation
Auto-conguration
Inte
grity
Heterogeneity
Compliance
Protection
of
personally
identiable
information
Highly
distrib
uted
systems
Content-a
w
areness
Reliability
Le
g
ac
y
support
Conte
xt-a
w
areness
Resilience
Modularity
Data
characteristics:
v
olume,
v
elocity
,
..
Safety
Netw
ork
connecti
vity
Disco
v
erability
Scalability
Fle
xibility
Shareability
Manageability
Unique
identication
Netw
ork
communication
W
ell-dened
components
Netw
ork
management
and
operation
Real-time
capability
Self-description
Service
subscription
From
this
three
pillars,
four
architectural
vie
ws
are
discussed
(Figure
6):
a
functional
vie
w;
a
syst
em
deplo
yment
vie
w;
a
netw
orking
vie
w;
and
a
usage
vie
w
.
Briey
,
Figure
6.
The
architectural
vie
ws
discussed
in
[18]
Conceptualization
of
IoT
ar
c
hitectur
es
(P
aolone)
Evaluation Warning : The document was created with Spire.PDF for Python.
340
❒
ISSN:
2252-8776
-
The
functional
vie
w
is
a
technology-agnostic
vie
w
of
the
components
necessary
to
form
an
IoT
system.
-
The
system
deplo
yment
vie
w
describes
the
actual
components
that
form
an
IoT
system,
namely
de
vices,
subsystems,
and
netw
orks.
-
The
netw
orking
vie
w
describes
the
principal
communications
netw
orks
which
are
in
v
olv
ed
in
IoT
systems
and
the
entities
with
which
the
y
connect.
-
The
usage
vie
w
focuses
on
ho
w
the
IoT
system
is
de
v
eloped,
tested,
operated,
and
used
from
a
user
per
-
specti
v
e.
The
e
xpression
“IoT
reference
architecture”,
used
in
[18],
corresponds
to
the
ADF
in
[17].
In
f
act,
it
encapsulates
the
whole
architectural
frame
w
ork
described
in
the
standard
as
a
generic
conceptual
template
from
which
a
certain
number
of
conte
xt-specic
IoT
archit
ecture
vie
ws,
go
v
erned
by
architecture
vie
wpoints,
can
be
dened.
W
e
do
not
use
this
e
xpression
in
this
w
ork
to
pre
v
ent
misunderstandings,
since
the
e
xpression
“Reference
Architecture”
seems
to
con
v
e
y
the
message
that
e
xists
just
one
IoT
architecture,
at
the
opposite
it
has
been
remark
ed
(subsection
3.1.)
that
there
is
at
least
one
architecture
vie
w
for
each
Architecture
vie
wpoint.
3.3.
The
IEEE
2413:2019
standard
Such
a
standard
[19]
introduces
an
architecture
frame
w
ork
for
the
IoT
which
conforms
to
the
inter
-
national
standard
ISO/IEC/IEEE
42010:2011
and
hence
to
the
ISO/IEC/IEEE
42010:2022.
The
architecture
frame
w
ork
is
moti
v
ated
by
concerns
commonly
shared
by
IoT
system
stak
eholders
across
the
follo
wing
six
rele
v
ant
domains:
smart
manuf
acturing,
smart
grid,
smart
b
uildings,
smart
cities,
smart
healthcare,
intelligent
transport
systems.
The
concerns
are
elaborated
as
a
set
of
architecture
vie
wpoints
that
form
the
body
of
the
frame
w
ork
descript
ion.
A
peculiarity
feature
of
standard
[19]
is
the
emphasis
it
puts
on
pointing
out
stak
ehold-
ers
vie
wpoints
and
concerns.
15
stak
eholders
(T
able
2),
13
vie
wpoints
(T
able
3),
and
62
concerns
(see
T
able
2;
p.37
in
[19])
are
lis
ted.
From
each
vie
wpoint,
it
is
possible
to
b
uild
an
architecture
vie
w
,
in
line
with
[17].
IEEE
[19]
describes
in
detail
the
13
vie
wpoints
(pp.
44–163).
Hereaf
ter
,
we
restrict
our
attention
to
the
conceptual
vie
wpoint.
T
able
2.
The
stak
eholders
Stak
eholder
Stak
eholder
(1)
Stak
eholder
(2)
Acquirers
Maintainers
Suppliers
Assessors
Operators
Support
staf
f
Builders
Owners
System
administrators
Communicators
Production
engineers
T
esters
De
v
elopers
Re
gulators
Users
T
able
3.
The
vie
wpoints
V
ie
wpoint
V
ie
wpoint
(1)
V
ie
wpoint
(2)
Conceptual
vie
wpoint
Function
vie
wpoint
Pri
v
ac
y
and
trust
vie
wpoint
Compatibility
vie
wpoint
Threat
model
vie
wpoint
Collaboration
vie
wpoint
Lifec
ycle
vie
wpoint
Security
and
safety
monitoring
vie
wpoint
Computing
resources
vie
wpoint
Communication
vie
wpoint
Access
control
vie
wpoint
Information
vie
wpoint
Adequate
design
for
required
security
vie
wpoint
Conceptual
vie
wpoint
concerns
the
denition
of
a
v
ocab
ulary
and
semantics
about
IoT
systems.
In
the
process
of
b
uilding
architecture
vie
ws,
it
is
necessary
to
b
uild
such
a
vie
w
in
order
to
ensure
that
the
in
v
olv
ed
stak
eholders
emplo
y
a
shared
language
when
talking
about
these
heterogeneous
systems.
The
conceptual
vie
wpoint
comprises
six
complementary
models:
the
entity
model,
the
system
model,
the
intent
model,
the
component
model,
the
component
capability
model,
and
the
representation
model.
It
is
w
orth
noting
that
the
w
ay
to
construct
the
conceptual
vie
wpoint
is
not
unique.
W
e
will
come
back
to
this
aspect
in
ne
xt
section.
3.4.
The
industrial
inter
net
of
things
r
efer
ence
ar
chitectur
e
This
report
details
an
industrial
internet
architecture
frame
w
ork
(IIAF)
based
on
the
ISO/IEC/IEEE
42010:2011
standard.
Then,
an
industrial
internet
reference
architecture
(IIRA)
i
s
b
uilt
according
to
the
IIAF
.
IIRA
abstracts
common
characteristics,
features
and
patterns
from
se
v
eral
industrial
domains.
F
our
vie
wpoints
Int
J
Inf
&
Commun
T
echnol,
V
ol.
14,
No.
1,
April
2025:
334-346
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Inf
&
Commun
T
echnol
ISSN:
2252-8776
❒
341
are
discussed
in
[20]:
b
usiness
vie
wpoint,
usage
vie
wpoint,
functional
vie
wpoint,
and
implementation
vie
w-
point.
In
the
intention
of
the
industrial
internet
consortium,
system
architects
may
adopt
these
vie
wpoints
as
starting
point
and
then
e
xtend
them
by
dening
additional
vie
wpoints
to
or
g
anize
system
concerns
based
on
the
specic
system
requirements.
F
or
e
xample,
in
ref.
[24]
authors
specialize
the
three-tier
architecture
pattern
that
is
part
of
the
implementation
vie
wpoint
in
[20].
4.
RESUL
TS
AND
DISCUSSION
This
study
re
vie
wed
four
well-kno
wn
documents
about
the
conceptualization
of
IoT
architectures
[17]-
[20].
Each
document
underlined
the
rele
v
ance
of
the
topic
gi
v
en
the
increasing
role
that
the
IoT
technology
plays
in
the
solution
of
a
huge
number
of
e
v
ery-day
problems.
Unfortunately
,
there
is
still
no
consensus
on
the
conceptualization
w
orko
w
.
Moreo
v
er
,
despite
there
are
earlier
studies
referring
to
some
of
the
four
proposals
(see
section
2),
so
f
ar
,
it
has
not
e
xplicitly
in
v
esti
g
a
ted
the
correspondence
of
their
basic
notions.
The
present
study
lls
both
these
g
aps,
as
it
is
detailed
in
the
follo
wing
tw
o
sub-sections.
4.1.
Concepts
corr
espondence
Belo
w
,
it
is
described
the
correspondence
of
the
main
concepts
of
the
ADFs
in
[17]
into
the
three
alternati
v
es
architecture
frame
w
orks
recalled
in
sub-sections
3.2,
3.3,
and
3.4.
In
detail,
T
ables
4-6
compare,
in
sequence,
the
ISO/IEC/IEEE
42010:2022
[17]
ag
ainst
ISO/IEC
30141:2018
[18],
IEEE
2413:2019
[19],
andthe
IIRA
[20].
T
able
4.
ISO/IEC/IEEE
42010:2022
vs.
ISO/IEC
30141:2018
ISO/IEC/IEEE
42010:2022
ISO/IEC
30141:2018
Entity
of
interest
IoT
systems
Stak
eholders
Users,
de
v
elopers,
architects,
...
Stak
eholder
perspecti
v
es/concerns
Get
an
o
v
ervie
w
of
basic
entities
(of
IoT
systems)
Get
an
o
v
ervie
w
of
tasks
to
be
performed
Architecture
vie
wpoint
Entity-based
vie
wpoint
Domain-based
vie
wpoint
Architecture
vie
w
IoT
RA
functional
vie
w
IoT
RA
system
deplo
yment
vie
w
IoT
RA
communications
vie
w
IoT
RA
usage
vie
w
T
able
5.
ISO/IEC/IEEE
42010:2022
vs.
IEEE
2413:2019
ISO/IEC/IEEE
42010:2022
IEEE
2413:2019
Entity
of
interest
IoT
systems
Stak
eholders
15
stak
eholders
are
listed
Stak
eholder
perspecti
v
es/concerns
62
concerns
are
listed
Architecture
vie
wpoint
13
vie
wpoints
are
listed
Architecture
vie
w
Architecture
vie
w
T
able
6.
ISO/IEC/IEEE
42010:2022
vs.
[20]
ISO/IEC/IEEE
42010:2022
[17]
RA
stands
for
reference
architecture
[20]
Entity
of
interest
End
users,
de
v
elopers,
architects,
.
.
.
Stak
eholder
perspecti
v
es/concerns
Get
an
o
v
ervie
w
of
basic
entities
(of
IoT
systems)
Get
an
o
v
ervie
w
of
tasks
to
be
performed
Architecture
vie
wpoint
Business
vie
wpoint
Usage
vie
wpoint
Functional
vie
wpoint
Implementation
vie
wpoint
Architecture
vie
w
IIoT
RA
b
usiness
vie
w
IIoT
RA
Usage
vie
w
IIoT
RA
IIoT
RA
functional
vie
w
IIoT
RA
implementation
vie
w
Conceptualization
of
IoT
ar
c
hitectur
es
(P
aolone)
Evaluation Warning : The document was created with Spire.PDF for Python.
342
❒
ISSN:
2252-8776
It
is
w
orth
noting
that
the
w
ay
to
construct
the
conceptual
vie
wpoint
is
not
unique.
F
or
e
xample,
T
able
7
sho
ws
that
in
the
standard
[19],
such
a
vie
wpoint
emplo
ys
six
UML
models,
while
in
the
standard
[18],
the
conceptual
model
is
composed
of
a
number
of
k
e
y
properties
that
an
IoT
system
typically
e
xhibits
(briey
called
characteristics
-
T
able
1)
and
a
certain
number
of
UML
class
diagrams
describing
the
k
e
y
concepts
characterizing
these
systems.
T
able
7.
Instantiation
of
the
Conceptual
vie
wpoint
in
[18],
[19]
The
standard
Implementation
of
the
conceptual
vie
wpoint
Modeling
language
ISO/IEC
30141:2018
[18]
IoT
characteristics
(T
able
1)
A
certain
number
of
class
diagrams
UML
IEEE
Std
2413-2019
[19]
Entity
m
odel
UML
System
model
UML
Intent
model
UML
Component
model
UML
Component
capability
model
UML
Representation
model
UML
4.2.
W
orko
w
f
or
ar
chitectur
e
description
T
able
8
lists
the
stages
of
the
w
orko
w
for
AD
that
results
from
the
ISO/IEC/IEEE
42010:2022
stan-
dard.
Each
stage
has
a
name
(second
column)
and
a
justication.
The
underlying
h
ypothesis
is
that
in
our
case
the
entity
of
interest
concerns
the
IoT
,
while
the
domain
remains
generic.
T
able
8.
Stages
of
the
recommended
w
orko
w
(AD
stands
for
architecture
description)
Step
Name
Comment
1
Explanation
of
the
AD
purpose
An
AD
must
include
a
statement
of
its
intended
purpose.
2
Identication
of
stak
eholders
An
AD
must
identify
the
stak
eholders
ha
ving
concerns
about
the
architecture
of
the
IoT
system
and
consistent
with
the
purpose
of
the
AD.
3
Identication
of
stak
eholder
perspecti
v
es
An
AD
must
identify
stak
eholder
perspecti
v
es
about
the
architecture
of
the
IoT
system
and
consistent
with
the
purpose
of
the
AD.
4
Identication
of
concerns
F
or
each
identied
perspecti
v
e,
an
AD
must
enumerate
the
pertinent
concerns
from
among
the
list
of
concerns.
An
AD
must
associate
each
identied
concern
with
the
stak
eholders
holding
that
concern.
5
Enucleation
of
architecture
vie
wpoints
F
or
each
identied
perspecti
v
e
must
be
established
the
architecture
vie
wpoints
necessary
to
frame
the
identied
concerns.
6
Production
of
the
architecture
vie
ws
T
o
each
identied
architecture
vie
wpoint,
at
least
an
architecture
vie
w
that
addresses
the
concern
has
to
be
bounded.
5.
CASE
STUD
Y
This
section
elaborates
a
sample
ca
se
study
that
implements
the
stages
listed
in
the
pre
vious
section.
The
IoT
is
the
entity
of
interest,
while
the
application
domain
is
k
ept
undened
on
purpose.
W
ithin
the
case
study
,
the
intended
purpose
of
the
AD
is
limited
to
produce
the
UML
class
diagram
about
the
component
capability
model
of
an
IoT
system
that
adopts
edge
computing.
The
in
v
olv
ed
stak
eholders
are
listed
in
T
able
9.
T
able
9.
Stak
eholders
and
their
role
Stak
eholder
Role/Responsibility
Users
Collaborate
in
the
denition
of
the
IoT
system
requirements.
Use
it
once
deplo
yed.
Engineers
Design
the
hardw
are
and
softw
are
necessary
to
run
the
IoT
system
according
to
the
requirements.
De
v
elopers
Deplo
y
the
IoT
system.
Operators
and
maintainers
Run
the
IoT
system
once
it
has
been
deplo
yed.
Manage
the
e
v
olution.
Owners
Deri
v
e
the
benets
of
the
solution
when
in
use.
5.1.
The
concer
ns
W
e
list
rele
v
ant
requirements
to
be
tak
en
into
consideration
when
designing
and
deplo
ying
an
IoT
system:
Int
J
Inf
&
Commun
T
echnol,
V
ol.
14,
No.
1,
April
2025:
334-346
Evaluation Warning : The document was created with Spire.PDF for Python.
Int
J
Inf
&
Commun
T
echnol
ISSN:
2252-8776
❒
343
-
Data
v
olume
v
e
rsus
bandwidth:
IoT
sensors
can
produce
more
data
than
is
economically
feasible
to
transmit
to
the
cloud
because
of
communication
costs
that
represent
a
rele
v
ant
quota
of
the
e
xpenses.
So,
the
issue
is
to
nd
a
sustainable
tradeof
f.
-
Performance
constraints:
netw
ork
latenc
y
is
an
obstacle
to
meet
the
need
of
real-time
reaction
posed
by
man
y
actual
applications.
processing
the
sensed
data
as
close
as
possible
to
the
sensors
has
been
pro
v
ed
to
be
the
solution.
-
Anticipate
decision-making:
it
becomes
possible
by
introducing
intelligence
at
the
source
nodes
of
the
IoT
system.
-
Pri
v
ac
y
constraints:
to
limit
the
risk
that
the
data
crossing
the
netw
ork
mo
ving
to
w
ards
the
cloud
w
ould
be
stolen,
it
is
necessary
to
process
it
near
to
the
source.
-
Intermittent
connecti
vity:
when
de
vices
and
sensors
are
in
locations
with
only
intermittent
connecti
vity
,
the
y
need
local
data
processing
and
decision-making
in
order
to
k
eep
operating.
Reducing
the
time
when
the
IoT
de
vice
is
connected
to
the
netw
ork
has
the
e
xtra
benet
of
preserving
the
battery
life
of
sensors.
It
has
been
pointed
o
ut
that
an
edge-computing-oriented
solution
(Figure
7)
may
address
all
the
pre
vi-
ous
v
e
concerns.
Edge
computing
is
performed
on
a
platform
at
the
netw
ork
edge
near
the
things,
inte
grating
netw
ork,
computing,
storage,
and
application
main
capabilities
adding
edge
intelligent
services
[1],
[25]-[27].
In
particular
,
using
caching
and/or
local
algorithms
to
pre-process
the
data
at
the
edge
re
d
uc
es
the
communica-
tion
cost.
This
feature
supports
autonomous
operation
as
well,
especially
when
the
connecti
vity
is
intermittent.
Figure
7.
Edge
computing
scenario
As
it
emer
ges
from
the
ISO/IEC/IEEE
42010
standard,
and
e
xplained
in
detail
by
the
standard
[19],
to
achie
v
e
an
ef
fecti
v
e
description
of
the
architecture
of
the
entity
of
interest
it
may
be
useful
to
adopt
multiple
vie
wpoints.
F
or
the
purposes
of
this
e
xample,
we
l
imit
the
attention
to
the
conceptual
vie
wpoint
(T
able
3).
Among
the
6
models
that
it
pro
vides
[19],
belo
w
,
we
focus
on
the
component
capability
model
(T
able
7).
5.2.
Conceptual
model:
IoT
component
capability
model
The
UML
class
diagram
of
Figure
8
sho
ws
the
pertinent
capability
classes
of
an
IoT
system.
A
brief
description
of
each
of
them
follo
ws.
Preliminary
,
the
diagram
sho
ws
that
an
IoT
system
may
be
composed
of
an
arbitrary
number
of
IoT
components.
The
follo
wing
capabilities
apply
to
each
of
them.
-
Sensing
capability:
pro
vides
a
v
alue
of
a
property
of
the
ph
ysical
entity
of
interest
in
the
form
of
digital
data.
Data
g
ained
by
sensors
may
be
pro
vided
to
other
IoT
components
through
the
component’
s
netw
ork
interf
ace
for
processing
and
storage.
Examples
of
observ
ations
concern
temperature,
position,
and
audio.
-
Actuating
capability:
pro
vides
the
ability
to
mak
e
a
change
in
the
ph
ysical
w
orld,
based
on
a
digital
input
to
the
component.
An
electronic
door
lock
is
an
e
xample
of
the
actuating
capability
.
-
Data
storing
capability:
pro
vides
the
ability
to
store
and
retrie
v
e
data.
Databases
and
data
brok
ers
(such
as
the
message
queue
telemetry
transport
brok
er)
are
e
xamples
of
data-storing
capabilities.
-
Data-transferring
capability:
pro
vides
the
ability
to
transmit
data
from
one
location
to
another
.
Data
net-
w
orks
based
on
ethernet
and
long-term
e
v
olution
(L
TE)
are
e
xamples
of
data-transferring
capabilities.
Conceptualization
of
IoT
ar
c
hitectur
es
(P
aolone)
Evaluation Warning : The document was created with Spire.PDF for Python.