From IoT Servitization to IoT Assetization

Zakaria Maamar

1 a

, Amel Benna

2 b

, Vanilson Buregio

1 c

and David Alves

3 d

University of Doha for Science and Technology, Doha, Qatar

Research Center for Scientiﬁc & Technical Information (CERIST), Algiers, Algeria

Department of Computing, Federal Rural University of Pernambuco, Recife, Brazil

Keywords:

Asset, IoT, Service, Management.

Abstract:

This paper discusses the stages and techniques to guide the conversion of IoT-compliant things into assets

and then, services. While existing initiatives focus on the conversion of things into services as part of the

servitization process, there are not initiatives that focus on thing conversion into assets as part of the asseti-

zation process. Assetization permits to model things from a management perspective in terms of depreciation

over time, transferability across locations, disposability after use, and convertibility across platforms. Thanks

to assetization, things would provide economical, informational, operational, and regulatory beneﬁts to their

owners (whether moral or juridical). A system demonstrating the technical doability of thing assetization is

also discussed in the paper.

1 INTRODUCTION

In today’s ICT landscape, Internet-of-Things (IoT)

perfectly demonstrates Weiser’s deﬁnition of ubiqui-

tous computing when he states in 1999 that “the most

profound technologies are those that disappear. They

weave themselves into the fabric of everyday life until

they are indistinguishable from it” (Weiser, 1999). IoT

has become ubiquitous where 41 billion IoT devices

are predicted to exist by 2027 and 70% of vehicles are

predicted to be connected to the Internet by 2023

In line with IoT growing research interest, we pre-

sented in (Maamar et al., 2021b) an IoT-servitization

framework exposing things as services to potential

users. On top of this exposure, the framework ad-

dressed 3 concerns undermining IoT adoption: lack

of cognitive things, lack of semantics between things,

and thing conﬁnement into silos. Servitization has

been around for many years (Vandermerwe and Rada,

1988) where organizations like Rolls-Royce sells

power-by-the-hour and salesf orce.com offers pay-

per-use software on the cloud. Nowadays, everything-

as-a-service (XaaS) is a well-established operation

https://orcid.org/0000-0003-4462-8337

https://orcid.org/0000-0002-9076-5001

https://orcid.org/0000-0001-5122-6075

https://orcid.org/0009-0008-2729-4068

www.businessinsider.com/internet-of-things-report.

model (Duan et al., 2016).

Despite the role of servitization in sustaining IoT,

the service model that underpins any form of serviti-

zation is tightly coupled to the request-response pat-

tern; upon receiving requests, services direct them in

our case to things and then, collect responses back,

if necessary. Although this service model has proven

itself over the years from an interaction perspective,

aspects from a management perspective like thing de-

preciation over time, thing transferability across loca-

tions, thing disposability after a time-period/use, and

thing convertibility across platforms are overlooked.

To address the management-aspect overlook, we ad-

vocate in this paper for IoT assetization in order to en-

capsulate things into assets, a term commonly used in

the ﬁnance world. The basis of our thing-assetization

proposal is an asset model that would cater for the

speciﬁcities of IoT like physical versus digital thing,

online versus ofﬂine thing, etc.

An asset “is something that provides a current, fu-

ture, or potential economic beneﬁt for an individual

or other entity”

. When things are assetized, they

provide economical beneﬁts (generates money like

parking meter), informational beneﬁts (produces data

like sensor), operational beneﬁts (performs operations

like AC unit), and regulatory beneﬁts (enforces poli-

cies like road radar) to their owners (whether moral

www.investopedia.com/terms/a/asset.asp.

236

Maamar, Z., Benna, A., Buregio, V. and Alves, D.

From IoT Servitization to IoT Assetization.

DOI: 10.5220/0012794500003753

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Software Technologies (ICSOFT 2024), pages 236-247

ISBN: 978-989-758-706-1; ISSN: 2184-2833

or judicial). To achieve these beneﬁts, an asset cost-

model could be used to track the “costs” of managing

a thing as an asset. These costs could vary depending

on things’ afore-mentioned speciﬁcities. In this paper,

we present our IoT assetization framework in terms of

motivations, guidelines, and demonstration. Section 2

deﬁnes asset. Section 3 details the assetization frame-

work in terms of motivations, thing, asset, and service

modeling, and guidelines. Section 4 implements the

framework. Section 5 introduces future work. Finally,

Section 6 concludes the paper.

2 ASSET OVERVIEW

The International Financial Reporting Standards

framework states that “an asset is a resource con-

trolled by the enterprise as a result of past events and

from which future economic beneﬁts are expected to

ﬂow to the enterprise”(Team, 2022a). Being a multi-

disciplinary topic, we provide hereafter an overview

of how asset is deﬁned and perceived in 3 separate

communities namely, ICT:security, digital-right man-

agement, and ﬁnance.

In the ICT:security community, Kuzminykh

and Carlsson adopt assets to isolate IoT system

risks (Kuzminykh and Carlsson, 2018). Recognizing

IoT systems’ unique characteristics and requirements,

the authors’ threat-risk modeling approach identiﬁes

security stakeholders (i.e., devices, services, and cus-

tomers), security assets, possible attacks, and, ﬁnally,

threats for the concerned IoT system. In the same

community, Chehida et al. present a methodology

to identify security risks, assess these risks’ impacts

on IoT systems’ assets, and, ﬁnally, protect these as-

sets from these risks. Along with assets upon which

a security-risk assessment strategy could be built, ser-

vices and business processes could help deﬁne a sim-

ilar strategy. Finally, Matsumoto et al. discuss how

important cyber-security countermeasures are for the

Industrial Internet of Things (IIoT) and how different

IIoT is from IoT requiring specialized means to man-

age assets. The authors’ assets correspond to edge de-

vices being monitored by an asset conﬁguration man-

agement agent.

In the digital-right management community, the

objective is to ensure a proper and trusted use and

protection of digital media assets and ﬁles in the

age of social media and widespread ﬁle sharing. A

well known W3C speciﬁcation for this management

is ODRL. It expresses that “something is permitted,

forbidden, or obliged, possibly limited by some con-

straints” (W3C, 2018; Becker et al., 2013) and pro-

vides a ﬂexible and interoperable information model,

vocabulary, and encoding mechanisms to represent

statements about assets’ uses. An asset is an iden-

tiﬁable resource or a collection of resources such

as data/information, content/media, applications, and

services. On top of ODRL, Custers questions the

appropriateness of existing digital-right management

practices for today’s world due to the heavy reliance

on social media and adoption of advanced technolo-

gies like big data and IoT (Custers, 2022). Accord-

ing to Custers, should not the ICT community deﬁne

new fundamental rights for the digital era? Finally,

in the same community of digital-right management,

IBM deﬁnes digital asset management solution as “a

software and systems solution that provides a system-

atic approach to efﬁciently storing, organizing, man-

aging, retrieving, and distributing an organization’s

digital assets”

In the ﬁnance community, asset is any resource

that an organization owns or controls as part of

its daily operations to produce positive economic

value (O’Sullivan and Sheffrin, 2021). According to

the Corporate Finance Institute (Team, 2022a), the

properties of an asset include ownership (can be even-

tually turned into cash and cash equivalents), eco-

nomic value (can be exchanged or sold), and re-

source (can be used to generate future economic ben-

eﬁts). And, in term of classiﬁcation assets can be

referred to as convertibility (how easy they are con-

verted into cash), physical existence (tangible versus

intangible), and usage (based on their business opera-

tion usage/purpose).

The paragraphs above offer a summary of the mul-

tiple uses of assets making them a cornerstone to any

organization’s development strategy. At the end of

the day, whether tangible or intangible, physical or

digital, limited or unlimited, etc. we expect assets to

provide beneﬁts to their owners. In the remaining sec-

tions, we elevate things to assets enabling a process of

identifying and then, describing the management as-

pects of these things.

3 ASSETIZATION FRAMEWORK

After motivating thing assetization, we model the as-

setization framework’s elements. Then, we present

the guiding stages for a successful assetization.

3.1 Motivations

Today’s things suffer from several limitations like

reduced size, restricted connectivity, limited energy,

www.ibm.com/ae-en/topics/

digital-asset-management.

From IoT Servitization to IoT Assetization

237

and constrained storage, which undermines their in-

tegration opportunities into mission-critical applica-

tions, for example. In addition, existing speciﬁ-

cations, e.g., W3C Web of Things-Thing Descrip-

tion (WoT-TD, (W3C, 2020)), primarily focus on

things’ technical aspects like whether they are phys-

ical or digital along with what interaction and secu-

rity protocols they support. Finally, thing servitiza-

tion develops proxy services on top of things neglect-

ing how to manage these things. With thing assetiza-

tion, we tap into some asset management principles

like value added/level of service, lifecycle, and total

cost of ownership to handle the following IoT-related

management aspects:

- Depreciation is related to the (selling) value

and/or (ongoing) performance of assets in the long

run. In IoT, we foresee depreciation as a con-

cern when things are used outdoor in harsh con-

ditions, which would over time negatively impact

their performance, for example. In addition, hav-

ing things installed outdoor would likely expose

them to physical tampering, which could acceler-

ate their depreciation.

- Transferability is related to ownership change of

assets from a legal perspective. In IoT, we fore-

see transferability as a concern when things shift

from one location to another forcing them to com-

ply with new data-privacy regulations, for exam-

ple. The way we foresee transferability is not

in line with Gunnarsson and Gehrmann who fo-

cus on security requirements during ownership

change (Gunnarsson and Gehrmann, 2022). They

note that backward and forward secrecy with re-

spect to old and new owners should be preserved.

An IoT system’s new owner shall not deduce any-

thing that the old owner did before the owner-

ship transfer, and vice versa. Gunnarsson and

Gehrmann also mention that there should not be

any time period where an IoT system would be

under the simultaneous control of both owners.

- Disposability is related to the availability of as-

sets. In IoT, we foresee disposability as a concern

when things cannot be used after a date or a num-

ber of times, which could result in replacing them.

To extend things’ lifetimes, measures like regular

servicing could be planned.

- Convertibility is related to the monetization of

assets, i.e., how easy it is to turn an asset into

cash. In IoT, we foresee convertibility as a con-

cern when things cannot adjust/mutate because of

changes of their environments. In (Maamar et al.,

www.nexgenam.com/blog/

the-principles-of-asset-management.

2021a), Maamar et al. discuss 3 arguments sup-

porting thing mutation: performance, so things re-

main competitive; awareness, so things “know”

their contextual surroundings; and survivability,

so things remain in business.

It is worth noting that the management aspects

above should offer a better return-on-investment on

things based on the following beneﬁts:

- Economical beneﬁt is about money that organi-

zations could make from things. Some things like

parking meters generate direct moneys, while oth-

ers like sensors generate indirect moneys since

their owners could potentially sell the collected

data to third parties.

- Information beneﬁt is about data that organiza-

tions could obtain from things. Some things like

sensors generate direct data, while others like ac-

tuators generate indirect data after processing the

data that they would receive.

- Operational beneﬁt is about the commands that

organizations could exercise on things. Some

things like electric switches respond to direct

commands originating from users, while others

like ﬁre sprinklers respond to indirect commands

originating from third parties like detectors.

- Regulatory beneﬁt is about the use of things to

enforce organizations’ policies. Some things like

road radars directly enforce speed limits by ﬂash-

ing violating vehicles, while others like automatic

door locks indirectly enforce accesses based on

signals received from face recognition programs

embedded into cameras.

3.2 Modeling Things

For the sake of illustration, we use WoT-TD to model

things. An excerpt of WoT-TD information-model

presented in Fig. 1 where Thing representing a con-

crete thing is a core class supporting 3 types of inter-

actions with end-users and/or peers. All classes asso-

ciated with these interaction types are derived from

the InteractionAffordance class and correspond, re-

spectively, to PropertyAffordance that allows to sense

and control parameters, ActionAffordance that refers

to a thing’s operations, and EventAffordance that al-

lows to asynchronously push communications such as

notiﬁcations, discrete events, and streams of values

to receivers. Regarding a thing’s security mechanism

and resources, 2 relevant classes exist namely, Secu-

rityScheme and Link. To describe how a thing’s oper-

ations are exercised over properties, actions, events,

www.w3.org/TR/wot-thing-description.

ICSOFT 2024 - 19th International Conference on Software Technologies

238

Figure 1: Excerpt of WoT-TD information-model.

and the thing itself, protocol bindings are serialized

and represented with the Form class. Finally, the data

format of an operation’s inputs/outputs is described

with the DataSchema class.

Listing 1 instantiates WoT-TD information-model

for a thing denoted by lamp. It has an id (line 2),

a title that is MyLampThing (line 3), and a ba-

sic security scheme (basic sc) included in securi-

tyDeﬁnitions (line 4) requiring username and pass-

word (line 5). In term of interaction affordance,

there exist one property affordance that is sta-

tus (line 8) accessible via https://mylamp.example.

com/status (line 10), one action affordance that is

speciﬁed to toggle (line 12) the switch status avail-

able at https://mylamp.example.com/toggle as a re-

source (line 15), and, ﬁnally, one event affordance

that is overheating (line 17) to allow MyLampThing

to send asynchronous messages to concerned persons.

Listing 1: Excerpt of WoT-TD speciﬁcation of MyLamp.

1 {" @con t e x t ": " h ttps : // ww w . w 3 . o rg / 2 0 1 9 / w ot / td / v 1 "

2 " id " : " u rn : d ev : o ps : 32 4 7 3 - Wo TLa m p -1 23 4 " ,

3 " t i t le " : " M yLampThin g " ,

4 " se c u r i t yDe f i n i t i ons " :{

5 " basic_sc " : {" sc h e m e " : " ba s i c " , " in " : " hea d e r "

}},

6 " sec u r i t y " : [ " b a s i c _ s c " ],

7 " properties " :{

8 " sta t u s " :{

9 " ty pe " : " s t r ing " ,

10 " fo r m s " : [{" hre f " : " ht t p s : // m y l a m p . e x a m p le .

co m / stat u s "}]}},

11 " ac t i o n s " :{

12 " tog g l e " :{

13 " fo r m s " : [{

14 " op " :" i n v o k e a c t i o n " ,

15 " hr ef " : " h t tps : // m y lamp . examp l e . c om / t o g g l e

"}]}},

16 " e v e n t s " :{

17 " ov e r h e a t i n g " :{

18 " da ta " :{" t y pe " : " s t ring "},

19 " fo r m s " : [{

20 " hr ef " : " h t tps : // m y lamp . exampl e . c om / oh " ,

21 " su b p r o t o c o l " : " l o ngpoll "}]}}}

3.3 Modeling Assets

To assetize things, we design an asset static-model

and an asset dynamic-model. The static model iden-

tiﬁes constructs that capture the functional and non-

functional characteristics of a future asset encapsulat-

ing a thing. And, the dynamic model identiﬁes states

that capture the lifecycle of the future asset when it

becomes available for use. For design needs, UML no-

tation is adopted to represent both models.

Fig. 2 is an asset’s class-based static model where

asset is a key class specialized into physical and dig-

ital sub-classes. For an organization, an asset pro-

vides beneﬁts captured with the beneﬁt class and spe-

cialized into informational, operational, regulatory,

and economical. These beneﬁts would depend on the

asset’s domain of use (e.g., hospitality) represented

with the domain class. On top of representing the

purpose and owner of an asset using operation and

owner classes, respectively, how an asset is invoked

and secured is regulated with the protocol class.

In Fig. 3 we represent an asset’s state-based dy-

namic model where activated is the starting state hav-

ing put-to-use and depreciated as 2 nested concurrent

sub-states. When using an asset, it is automatically

subject to depreciation. From:put-to-use state, the rest

of states capture the following situations:

- To:transferred state corresponds to the situation

where an asset is shifted from one place to an-

other. This results in forcing the asset to comply

From IoT Servitization to IoT Assetization

239

Figure 2: Asset’s class-based static model in IoT.

Figure 3: Asset’s state-based dynamic model in IoT.

with the new place’s regulations and/or to work

under the new place’s conditions.

- To:converted state corresponds to the situation

where an asset is on-the-ﬂy loaded with extra ca-

pabilities. This allows the asset to respond to

changes in the environment without suspension.

- To:disposed state corresponds to the situation

where an asset is withdrawn due to a fault.

From:depreciated state, the rest of states capture

the following situations:

- To:disposed state corresponds to the situation

where an asset is withdrawn due to out-of-

existence triggered by excessive and/or long-time

use.

Each situation listed above sheds light on a par-

ticular management aspect; e.g., from depreciated

state to disposed state corresponds to the disposabil-

ity management aspect, and from activated state to

converted state corresponds to the convertibility man-

agement aspect.

3.4 Modeling Services

In Fig. 4 we represent a service’s state-based dynamic

model where prepared is the starting state having ac-

tivated and suspended as 2 exclusive successor states.

Figure 4: Service’s state-based dynamic model in IoT.

The last 2 states, done and failed, illustrate whether a

service execution completed with success or failure,

respectively.

3.5 Guiding Stages

Fig. 5 represents our 2 stage approach for thing as-

setization and asset servitization, respectively. These

stages are in complete opposition to what we did ear-

lier in thing servitization where things were directly

encapsulated into services (Maamar et al., 2021b).

Although Fig. 5 shows a bottom-up progress from

the physical level (thing) to the digital level (asset)

and ﬁnally, the abstract level (service) in support of

thing assetization and asset servitization, this progress

is also complemented by another top-down progress

from the abstract level to the digital level and ﬁ-

nally, the physical level demonstrating how both asse-

tization and servitization are concretized at run-time.

This happens by passing details from instantiating rel-

evant constructs when speciﬁc details are passed on

from one level to another. In the following, we de-

compose the discussions of the 2 stage approach into

Bottom-Up (BU) and Top-Down (T D).

3.5.1 Bottom-up Discussion

In the thing-assetization stage covering the physical

and digital levels, the objective is to encapsulate a

thing into an asset. This happens by identifying in

ICSOFT 2024 - 19th International Conference on Software Technologies

240

Thing

Asset

Service

encapsulated

into

encapsulated

into

Applications

interact

Physical level

Digital level

Abstract level

Figure 5: Thing assetization followed by asset servitization.

WoT-TD information-model the relevant constructs,

i.e., classes and relations, that would semantically

correspond to their counterpart constructs in Fig. 2’s

asset static-model. This is summarized in Table 1

where c|r/x stands for class|relation/either class’s

name or relation’s name(class

,class

). Should there

be any missing correspondence (indicated by not-

available in the table), then we will take corrective

actions by adding new constructs to the asset static-

model along with ﬁnalizing this addition, as we deem

appropriate. Fig. 6 shows the new constructs in terms

of classes (event, state, and upgrade) and relations

(event, state, upgrade, and invocation) that become

attached to Fig. 2’s asset static-model.

Figure 6: New classes/relations in the asset’s class-based

static model.

We now continue with the asset-servitization stage

covering this time the digital and abstract levels. The

objective is to encapsulate an asset into a service

that future applications would interact with. This

happens by traversing the updated asset static-model

(Fig. 2 and Fig. 6) to identify speciﬁc constructs that

would semantically correspond to their counterpart

constructs in Fig. 7’s service static-model. This iden-

tiﬁcation is driven by the needs and requirements of

the interface that would expose the service to appli-

cations for interaction. By analogy with Table 1, we

proceed with the same as per Table 2.

Figure 7: Service’s class-based static model in IoT.

3.5.2 Top-Down Discussion

Contrarily to the objective of the bottom-up asset-

servitization stage that is to encapsulate an asset into

a service, the objective of top-down is to cascade con-

crete details about applications interacting with ser-

vices from the abstract level to the digital level. These

details correspond to 2 types of values; those values

that applications directly submit to interfaces when

invoking them (e.g., interface’s name) and those val-

ues that are indirectly obtained based on what these

applications submitted to these interfaces (e.g., ser-

vice’s id is obtained based on interface’s name). In ei-

ther way, cascading details requires identifying prop-

erties in the relevant constructs of both the service and

the asset static-models that will act as value contain-

ers. This cascading is summarized with Table 3 where

examples of properties in the respective service static-

model include id to identify the service and url to in-

teract with the interface of the service, and examples

of corresponding properties in the asset static-model

include id to identify the asset related to the service

and link to associate the path of the operation to in-

voke with the url of the interface.

We now complete the thing-assetization stage

where the objective now is to cascade concrete de-

tails from the digital level to the physical level allow-

ing this time to effectively activate/trigger a particular

thing based on speciﬁc constructs in the WoT-TD in-

formation model. These details refer to corresponding

properties in the asset static model as per Table 3. Ta-

ble 4 summarizes the detail cascading from the asset

static-model to the WoT-TD information-model where

examples of corresponding properties in this model

include href to associate the submission path of the

operation to perform with the invocation link and in-

put to capture the operation’s input.

3.6 Handling Management Aspects

One of the objectives of the IoT-assetization frame-

work is to manage things as assets. 4 management

aspects along with this framework’s beneﬁts are dis-

cussed in Section 3.1 and will hereafter be speci-

ﬁed based on what has been achieved during bottom-

up construct correspondences and top-down construct

concretization.

From IoT Servitization to IoT Assetization

241

Table 1: BU:construct correspondences between WoT-TD and the asset static-model.

WoT-TD information-model Asset static-model’s

construct construct corrective action

c/T hing c/Asset

c/EventA f f ordance Not available Add c/Event

c/PropertyA f f ordance Not available Add c/State

c/ActionA f f ordance c/Operation

c/Form c/Invocation

c/VersionIn f o Not available Add c/U pgrade

r/actions(T hing,ActionAddordance) r/operation(Asset,Operation)

r/events(T hing,EventsAddordance) Not available Add r/event(Asset,Event)

r/properties(T hing,PropertyAddordance) Not available Add r/state(Asset,State)

r/ f orms(T hing,Form) r/invocation(Asset,Invocation)

r/ f orms(InteractionA f f ordance,Form) Not available Add r/invocation(Operation,Invocation)

r/versions(T hing,VersionIn f o) Not available Add r/upgrade(Asset,U pgrade)

Table 2: BU:construct correspondences between the asset

static-model and service static-model.

Asset static-model Service static-model’s

construct construct

corrective

action

c/Asset c/Service

c/Owner c/Provider

c/Operation c/Inter f ace

c/Event c/Inter f ace

c/State c/Inter f ace

r/operation(Asset,Operation) r/inter f ace(Service,Inter f ace)

r/event(Asset,Event) r/inter f ace(Service,Inter f ace)

r/state(Asset,State) r/inter f ace(Service,Inter f ace)

r/owner(Asset,Owner) r/provider(Service,Provider)

Table 3: T D:detail cascading from the service static-model

to the asset static-model.

Service static-model Asset static-model

construct property construct corresponding property

c/Service p/id c/Asset p/id

c/Inter f ace p/name c/Operation p/name

c/Inter f ace p/url c/Invocation p/link

c/Inter f ace p/args c/Operation p/input

• Depreciation: in the literature (Department of the

Treasury, 6pdf), many techniques to assess asset

depreciation exist such as straight-line, declining-

balance, and unit-of-production. Countries use

these techniques, as they see ﬁt; for instance,

capital-cost-allowance in Canada

and straight-

line and declining balance in the USA

. Despite

Table 4: T D:detail cascading from the asset static-model

to WoT-TD information-model.

Asset static-model’s WoT-TD information-model

construct property construct corresponding property

c/Asset p/id c/T hing p/id

c/Operation p/name c/ActionA f f ordance p/properties

c/Invocation p/link c/Form p/hre f

c/Operation p/input c/ActionA f f ordance p/input

tinyurl.com/mr3sa4v9.

tinyurl.com/dyhpv378.

the diversity of these techniques, they have some

properties in common (Panicker, ions): original

cost (asset’s acquisition amount including sales

tax, transportation, set-up, training, etc.), useful

life (number of years one expects to have the as-

set in use depending on its type and is expected to

be at least 1 year), and number of units produced

before the asset is worn.

During thing assetization, depreciation as per Sec-

tion 3.1 would require the following details about

a thing: ﬁrst-date-of-use, original-cost, level-of-

use (e.g., number of invocation requests per day),

number-of-years-of-use, and condition-of-use (in-

door versus outdoor). These details are properties

in the asset static-model and the values of these

details are collected from WoT-TD-based thing

speciﬁcation. Table 5 illustrates potential cor-

respondences between these properties and this

speciﬁcation’s constructs. Should a correspon-

dence be missing, i.e., reported as not-available

in this table, then we would suggest corrective ac-

tions like done in Section 3.5.1.

• Transferability: in the literature (Heather et al.,

2019), transferring assets is a multi-facet exer-

cise that ranges from agreeing on what is eligi-

ble for transfer to preparing transfer agreements

and identifying the necessary intervenants during

the transfer. Both physical assets like lands (Patil

and Shyamasundar, 2021) and virtual assets like

cryptocurrency (Keundug and Heung-Youl, 2021)

could be transferred requiring each a different

handling mainly from legal and ﬁnancial perspec-

tives. Many details could be included in a trans-

fer agreement with emphasis on price, assignee,

rights and obligations relating to title, warranty,

and indemnities

. An interesting discussion about

asset transfer in IoT sheds light on shared own-

www.contractscounsel.com/t/us/

asset-transfer-agreement.

ICSOFT 2024 - 19th International Conference on Software Technologies

242

ership when both buyers and sellers retain con-

trol over the same assets, but in independent con-

texts (Raina and Palaniswami, 2021). Despite

being sold to buyers, Tesla cars’ software can

be remotely altered over the Internet by a few

keyboard-clicks at Tesla Inc.’s Palo Alto control

center raising the question of who owns what.

During thing assetization, transferability as per

Section 3.1 requires the following details about

a thing: previous-location, current-location, and

transfer-date. By analogy with depreciation, Ta-

ble 6 illustrates potential correspondences be-

tween the asset class-model’s properties and WoT-

TD information-model’s constructs. The same vo-

cabularies and notation are adopted as earlier.

• Disposability: in the literature (FreshBooks,

2022; Team, 2022b), organizations proceed with

disposing of their (often long-term) assets for

multiple reasons, such as the asset’s value has

fully depreciated, the asset is no longer useful,

unforeseen circumstances, asset replacement, and

repair/service costs exceed the asset’s value. In-

dependently of these reasons, organizations need

to accurately document any disposal-related trans-

actions in their ﬁnancial books. Asset disposal is

either normal exempliﬁed with transfer of owner-

ship or trading exempliﬁed with exchanging old

goods with new ones (FreshBooks, 2022).

During thing assetization, disposability as per

Section 3.1 would require the following details

about a thing: salvage-cost and disposability-

reason. By analogy with depreciation and trans-

ferability, Table 7 illustrates potential correspon-

dences between the asset class-model’s proper-

ties and WoT-TD information-model’s constructs.

The same vocabularies and notation are adopted

as earlier.

• Convertibility: it is the exchange of a convert-

ible type of asset into another type of asset usu-

ally at a previously agreed-upon price on or be-

fore a previously agreed-upon date. According to

Chen (Chen, 2022), examples of assets that can

undergo conversions are convertible bonds and

preferred shares. Conversion is useful as it per-

mits to categorize assets into current (those with a

shorter life span and easily transferable into cash)

and ﬁxed (intended for long-term use and unlikely

to convert quickly into cash).

During thing assetization, convertibility as per

Section 3.1 would require the following details

about a thing: upgrade-date and upgrade-type.

By analogy with depreciation, transferability, and

disposability, Table 8 illustrates potential cor-

respondences between the asset class-model’s

properties and WoT-TD information-model’s con-

structs. The same vocabularies and notation are

adopted as earlier.

4 SYSTEM IMPLEMENTATION

A system was developed to demonstrate the IoT-

assetization framework’s technical doability. It

is described below in terms of architecture, IoT-

assetization API, and usage scenarios. Documentation

is available at assetizationapp.ﬂy.dev/docs.

4.1 Architecture

Fig. 8 illustrates the main components of the system’s

architecture. Key quality attributes like modularity

as well as incorporation of best-in-class tools were

adopted during the development to achieve efﬁciency,

versatility, and seamless capability integration. The

different components are as follows.

Data Acquisition: serves as an entry point to col-

lect data about things. This is done by harnessing

Node-RED’s (nodered.org) ﬂow-based mechanisms.

Node-RED is an open-source tool for IoT applica-

tions, featuring a user-friendly graphical interface

for creating workﬂows through drag-and-drop. It is

widely used for connecting devices, APIs, and ser-

vices, and is good at automation, data processing, and

prototyping. Some key strengths include real-time

testing and debugging that allow for incremental de-

ployment of changes along with their real-time eval-

uation. This enables continuous system monitoring

and reﬁnement of ﬂows, aiding in achieving accuracy

and maintaining a consistent system state.

IoT-assetization API: ensures seamless data trans-

mission between the data acquisition component and

data processing and management components, as

well as provides services to the dashboard module.

IoT-assetization API is implemented with FastAPI

(fastapi.tiangolo.com) framework in compliance with

REST principles. FastAPI is a Web framework for

building APIs in Python 3.7+, known for its ease of

use and speed. It generates interactive API documen-

tation (using Swagger UI and ReDoc) and employs

token-based authentication. It uses stateless com-

munication and standard HTTP methods for clarity

and consistency in client-server interactions. FastAPI

framework also ensures a very high speed and efﬁ-

ciency in handling Web requests and response. Fi-

nally, token-based authentication offers secure access

to the IoT-assetization API functionalities.

Data Processing and Mmanagement: collects,

From IoT Servitization to IoT Assetization

243

Table 5: Property/Construct correspondences for the needs of depreciation.

Asset static-model’s WoT-TD information-model

property Construct Corrective action

p/ﬁrst-date-of-use:Asset p/created:Thing

p/original-cost:Asset Not available add p/amount[schema.org] from InvestmentOrDeposit class to Thing class

p/level-of-use:Invocation Not available add c/SystemLifetime[ssn] to Thing class

p/number-of-years-of-use:Invocation Not available add p/validThrough[schema.org] from Offer class to Thing class

p/condition-of-use:Invocation Not available add c/Condition[ssn] to InteractionAffordance class

Table 6: Property/Construct correspondences for the needs of transferability.

Asset static-model’s WoT-TD information-model

property Construct Corrective action

p/previous-location:Invocation Not available add p/fromLocation[schema.org] from TransferAction class to Thing class

p/current-location:Invocation Not available add p/toLocation[schema.org] from TransferAction class to Thing class

p/transfer-date:Invocation Not available add p/endTime[schema.org] from TransferAction class to Thing class

Figure 8: Components and interactions in the system.

transforms, and manages telemetry data and manages

users’ accounts and asset-related data, such as types,

usage information, depreciation over time, and other

details.

Data Repository. is a PostgreSQL (postgresql.org)

database used by the data processing and manage-

ment component to store all thing- and asset-related

data.

Dashboard. is a front-end application imple-

mented using Svelte (svelte.dev) framework to pro-

vide a visual representation and monitoring interface

of assets.

4.2 IoT-Assetization API

We delve into the architectural design, functionalities,

and potential applications of the IoT-assetization API,

explaining its role in asset management. The API is

divided into modules that expose a variety of end-

points, each serving a speciﬁc purpose within the as-

set’s management lifecycle, accepting JSON payloads

for requests and responding with JSON-encoded data.

Key modules include:

- Asset Management: groups endpoints to create,

list, update, and delete assets. Actions over assets

are also registered, providing a history of interac-

tions.

- Task Management: provides capabilities to track

to-do items, with endpoints to create, retrieve,

modify, and delete.

- User Administration: handles user accounts, pro-

viding endpoints for creating, updating, and delet-

ing users. Users must ﬁrst obtain an access token

through a login endpoint, which is then used for

subsequent requests. This module also provides a

token refresh mechanism, ensuring uninterrupted

access for authenticated users.

- Type Management: allows the deﬁnition and ma-

nipulation of asset and action types, ensuring ﬂex-

ibility in asset categorization. Any asset has a data

ﬁeld ”type” in which values like sensor, lamp,

smart lock, and others can be informed.

4.3 Usage Scenarios

Some screenshots from the system’s dashboard are

presented in Fig. 9 and 10 offering a visual represen-

tation of the system’s capabilities in managing assets.

Fig. 9 is a consolidated view of all things that are

subject to assetization, enabling users to quickly view

basic details like type, description, lifespan, and date

of creation. Such a layout not only aids in efﬁcient

asset management, but, also, ensures transparency re-

garding asset health, usage, and depreciation.

Fig. 10 is a detailed breakdown of a particular as-

set, in this case, “ultramegawide sensitive sensor”.

Here, the system provides a clear depiction of asset

management principles applied to things, including

the following key elements:

- Asset Depreciation Graph: displays the deprecia-

tion cost of an asset over time, providing insights

ICSOFT 2024 - 19th International Conference on Software Technologies

244

Table 7: Property/Construct correspondences for the needs of disposability.

Asset static-model’s WoT-TD information-model

property Construct Corrective action

p/salvage-cost:Invocation Not available add p/minPrice[schema.org] from PriceSpeciﬁcation class to Thing class

p/disposability-reason:Asset Not available add either p/comment[schema.org] from CreativeWork class or c/Observation[sosa] to Thing class

Table 8: Property/Construct correspondences for the needs of convertibility.

Asset static-model’s WoT-TD information-model

property Construct Corrective action

p/upgrade-date:Asset p/modiﬁed:Thing

p/upgrade-type:Asset not available add p/comment[schema.org] from CreativeWork class to VersionInfo class

into the asset’s ﬁnancial value and expected lifes-

pan.

- Asset Usage Information: details how long an as-

set has been in use, its active usage time, and the

condition of use.

- General Asset Information: shows different asset

types (e.g., washing machine, sensor, smart light),

allowing users to quickly comprehend the distri-

bution of asset by type.

- Asset Health Indicator: represents assets that are

above or below the salvage price, offering a quick

overview of their overall health.

In the detailed asset analytics view, users can

check nuanced insights, ranging from depreciation-

cost trend to usage information and overall health.

Such granularity in data presentation facilitates com-

prehensive asset tracking, ensuring timely mainte-

nance and informed decision-making. Our system

showcases the transformative potential of blending

IoT capabilities with asset management principles.

5 FUTURE WORK

Our future work is to design an asset cost-model that

would help estimate the costs of assetizing things and

the potential economical, operational, informational,

or regulatory beneﬁts of this assetization. We recall

that things are subject to depreciation, transferability,

disposability, and/or convertibility that would impact

the cost of operationalizing them. For instance, de-

preciation could constitute a source of expense due to

maintenance cost while transferability could consti-

tute a source of income due to change of ownership.

According to FasterCapital, a cost model has a

scope, drivers, equations, and validation (FasterCap-

ital, 2023). Costs could be of different types such

as marginal, average, full, and sunk contributing dif-

ferently to the ﬁnal cost model. Our initial thoughts

would be a 2-stage asset cost-model where the ﬁrst

stage would cover costs to encapsulate things into as-

sets and the second stage would cover costs to en-

capsulate assets into services. When working out

the asset cost-model, we deem necessary to consider

the speciﬁcities of things like physical versus digi-

tal, static versus mobile, and online versus ofﬂine. A

physical think like sensor could require on top of an

acquisition cost, a maintenance cost over a period of

time. Contrarily, a digital thing like software could

require a lease cost (in compliance with SaaS), only,

leaving the maintenance cost to the software’s owner.

- From:thing To:asset cost-model would cover sep-

arate costs related to things, assets, and encapsu-

lation, respectively. These costs would vary de-

pending on the nature of thing with focus on car-

rying out encapsulation operations between things

and assets as reported in Table 1. Encapsulation

operations are also complemented with additional

operations reported in Table 4 where concrete de-

tails are cascaded from assets to things in order to

have these things activated.

- From:asset To:service cost-model would cover

separate costs related to assets, services, and en-

capsulation, respectively. These costs would vary

depending on the nature of asset with focus on

carrying out encapsulation operations between as-

sets and services as reported in Table 2. Encapsu-

lation operations are also complemented with ad-

ditional operations reported in Table 3 where con-

crete details are cascaded from services to assets

in order to have these assets activated.

6 CONCLUSION

This paper discussed the stages and techniques

enabling to transition from Internet-of-Things to

Internet-of-Assets by elevating things to assets. Or-

ganizations own assets to produce positive economic

values. Contrarily to existing initiatives that ex-

pose things as services, we “squeeze” assets between

things and services allowing to track things’ depreci-

ation over time, transferability across locations, dis-

From IoT Servitization to IoT Assetization

245

Figure 9: List of available things after assetization.

Figure 10: Summary of asset analytics.

ICSOFT 2024 - 19th International Conference on Software Technologies

246

posability after time/use, and convertibility across

platforms. These 4 management aspects provide bet-

ter insights into how to handle things. For a success-

ful thing-asset transition, we developed an IoT asseti-

zation framework that encompasses 3 models, thing,

asset, and service, and supports 2 stages driving thing

assetization and asset servitization, respectively. The

implemented system demonstrates the practicality of

thing assetization and shows how to effectively han-

dle things as assets. Finally, future research in-

volves the development of an asset cost-model, focus-

ing on the economic implications of IoT assetization

through some economical, informational, operational,

and regulatory beneﬁts to things’ owners.

REFERENCES

Becker, S., H

uck, B., Naujokat, K., Schmeiser, A., and Kas-

ten, A. (2013). ODRL 2.0 Revisited. In Proceedings

of INFORMATIK’2013, Koblenz, Germany.

Chen, J. (April 2022 (Visited in September 2022)). Con-

version in Finance. www.investopedia.com/terms/c/

conversion.asp.

Custers, B. (2022). New Digital Rights: Imagining Addi-

tional Fundamental Rights for the Digital Era. Com-

puter Law & Security Review, 44.

Department of the Treasury, I. R. S. (2021 (visited in Au-

gust 2022, www.irs.gov/pub/irs-pdf/p946.pdf)). Pub-

lication 946 How to Depreciate Property.

Duan, Y., Sun, X., Longo, A., Lin, Z., and Wan, S. (Jan-

uary 2016). Sorting Terms of “aas” of Everything as a

Service. International Journal of Networked and Dis-

tributed Computing, 4(1).

FasterCapital (2023). Create Effective Cost Models for your

Business. https://fastercapital.com/. (Visited in Au-

gust 2023).

FreshBooks (2021 (Visited in September 2022)). What

Is Disposal of Assets? Deﬁnition & Explana-

tion. www.freshbooks.com/en-gb/hub/accounting/

disposal-of-assets.

Gunnarsson, M. and Gehrmann, C. (2022). Secure Owner-

ship Transfer for the Internet of Things. In Proceed-

ings of ICISSP’2020, Valletta, Malta.

Heather, M., Heid, N., and Lien, N. (2019). System-

atic mapping of checklists for assessing transferabil-

ity. Systematic Reviews, 8.

Keundug, P. and Heung-Youl, Y. (2021). Proposal for

Customer Identiﬁcation Service Model Based on Dis-

tributed Ledger Technology to Transfer Virtual As-

sets. Big Data and Cognitive Computing, 5(3).

Kuzminykh, I. and Carlsson, A. (2018). Analysis of Assets

for Threat Risk Model in Avatar-oriented IoT Archi-

tecture. In Proceedings of NEW2AN’2018, Saint Pe-

tersburg, Russia.

Maamar, Z., Faci, N., Ugljanin, E., Baker, T., and Bur

egio,

V. (2021a). Towards a Cell-inspired Approach for a

Sustainable Internet-of-Things. Internet of Things, 14.

Maamar, Z., Faci, N., and Yahya, F. (2021b). A Guiding

Framework for IoT Servitization. In et al., A., ed-

itor, Next-Gen Digital Services. A Retrospective and

Roadmap for Service Computing of the Future.

O’Sullivan, A. and Sheffrin, S. (2021). Economics: Princi-

ples in Action. Prentice Hall, Washington.

Panicker, P. (February 23, 2022 (visited in August 2022,

www.quicsolv.com/blog/internet-of-things/asset-

tracking/types-depreciation-calculations)). Types of

Depreciation and their Calculations.

Patil, V. and Shyamasundar, R. (2021). Landcoin: A Practi-

cal Protocol for Transfer-of-Asset. In Proceedings of

ICISS’2021, Patna, India.

Raina, A. and Palaniswami, M. (2021). The Ownership

Challenge in the Internet of Things World. Technology

in Society, 65.

Team, C. (2022a). Types of Assets.

corporateﬁnanceinstitute.com/resources/knowledge/

accounting/types-of-assets. (Visited in July 2022).

Team, I. E. (2021 (Visited in September 2022)b).

What is Asset Disposal? Deﬁnition, Beneﬁts

and Examples. www.indeed.com/career-advice/

career-development/asset-disposal.

Vandermerwe, S. and Rada, J. (1988). Servitization of Busi-

ness: Adding Value by Adding Services. European

Management Journal, 6(4).

W3C (2018). ODRL Information Model 2.2. https://www.

w3.org/TR/2018/REC-odrl-model-20180215/. (Vis-

ited January 2023).

W3C (2020). Web of Things (WoT) Thing Description.

www.w3.org/TR/wot-thing-description. (Visited in

January 2021).

Weiser, M. (1999). The Computer for the 21

Century.

Newsletter ACM SIGMOBILE Mobile Computing and

Communications Review, 3(3).

From IoT Servitization to IoT Assetization

247