Mapping a Set of Tools to Ensure Cloud and Distributed Computing,

Virtualization Tools and Data Storage Systems in the Work of the

Transport and Logistics Center

NIKITA SHAGOV, NATALIA MAMEDOVA, ARKADIY URINTSOV

Basic Department of Digital Economy,

Higher School of Cyber Technologies, Mathematics and Statistics,

Plekhanov Russian University of Economics,

RUSSIA

Abstract: - The existing "gaps" in approaches to the deployment of transport and logistics centers (TLC) within

the edges of the backbone network lead to errors in the implementation of the spatial development strategy.

Information support solutions for the implementation of terminal, transportation, and warehousing technologies

are the least elaborated. As a result, errors have to be corrected in the process of operating the information

architecture. There is a need to complement the existing TLC deployment management system with new tools

that enhance the validity of TLC location assessment and eliminate the randomness factor in the choice of

information architecture for TLC backbone network objects. This research aims to develop a flexible solution

for network architecture design using cloud, fog, and edge layers. The main requirement for a flexible solution

is that it can be rapidly deployed when the technology architecture changes. The proposed tool visualizes the

structure of the network architecture and allows the analysis of information flows by capturing data on the

movement of material cargo within the center and between TLC network facilities. The mapping tool considers

the network computational load evaluation factor for the cloud, fog, and edge layers. The scientific novelty of

the research results is achieved by the principle of system management of the components of complex systems.

The practical significance of the results of the study lies in the possibility of using the mapping tool in the

process of information architecture design at the stage of making decisions about the deployment of TLC

network objects.

Key-Words: - transport and logistics center, backbone network, information architecture, cloud and distributed

computing, visualization tools, storage system, cloud, fog, and edge layers.

Received: July 29, 2022. Revised: June 16, 2023. Accepted: July 24, 2023. Published: September 7, 2023.

1 Introduction

The issue of construction and effective functioning

of transport and logistics centers (TLC) is a priority

of strategic development on a national scale. The

difficulties of solving this issue are not only related

to the size of the state territory and the level of

transport infrastructure development, although these

factors also largely determine the choice of tools for

the deployment of TLC in the backbone network.

The variability in the decisions made is also due to

the level of integration of the off-the-shelf

distributed infrastructure into the TLC information

support system.

At the same time, even the process of deploying

a single TLC based on a distributed algorithm to

build an information architecture is complex. After

all, it must take into account the allowable limits of

TLC parameters, such as computing power of

nodes, peak power consumption and workload of

CPUs (processors) and storage (memory) during

operations, information network bandwidth, etc, [1].

The deployment process, which must consider the

parameters of TLC in the backbone network,

becomes a task that requires a unique solution for

each project. There are, however, general

approaches to this, which aim to reduce and

distribute the computational load on the network.

Thus, there is a need to take into account the

parameters of TLC location in the backbone

network – TLC equipment, TLC cargo handling

capacity, etc, [2].

A factor that increases entropy in the decision-

making process for information architecture TLC is

that within the backbone network, individual TLCs

are scalable, and the structure of the network

architecture differs. A set of cloud and distributed

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

243

Volume 11, 2023

computing provisioning is also not a standard

solution. Scaling limits are determined by modeling

(mapping) the structure of network components and

analyzing their behavior to select the best solution,

[3].

The hypothesis of this study was to test the thesis

that the characteristics of the information

architecture of TLC within the backbone network

create risks of achieving deployment performance

criteria.

This study seeks to improve the validity of the

decision to deploy TLC within a backbone network

by visualizing the set of enablers of cloud and

distributed computing. The mapping of the set of

facilities will be in demand for network architecture

simulation design and for subsequent calculation of

the cost of the TLC deployment project. The

proposed method of visualizing a set of network

architecture facilities by mapping eliminates the

entropy factor when selecting TLC deployment

parameters within a backbone network.

2 Problem Formulation

The growing need to use network resources and

servers that process and store information at the

edge of the network has shown the limits of the

cloud computing paradigm and provoked the active

development of the fog and edge computing

paradigm, [4]. As a result, we can operate intelligent

devices whose parameters in terms of storage

capacity, computing power, and query processing

time allow us to significantly reduce the response

time of the generated processes, [5]. This is a major

advantage of distributed computing paradigms in

storing and processing end-user information in

distributed nodes.

The design of the distributed infrastructure for

TLC within a backbone network can be performed

according to different scenarios, the variability of

which is determined by the multiplicity of devices

and connections involved. In addition, the nodes of

the TLC backbone network differ from each other –

they have different logistical constraints, different

freight flow, and multimodal transport

characteristics. At the same time, they are

synchronized into one backbone network.

When deploying TLC, the development of its

information architecture is based on a project-based

approach, [6]. The functional requirements side of

the project includes such factors as multi-platform

interfaces, as well as the ability to flexibly configure

business intelligence, scenario modeling, and

planning of transport and logistics processes. The

implementation of the project involves taking into

account the interests of the owners of business

processes, which constitutes the subjective side of

the project implementation, [7]. The distributed

infrastructure must take into account the human

factor and offers settings for the work of a wide

range of users TLC, [8] which include cargo

owners, freight customers and their representatives,

logistics companies, freight forwarders, first- and

last-mile carriers, owners of containers, railcars, and

vehicles, as well as logistics infrastructure,

controlling organizations, TLC operators, and

system integrators. This approach is aimed at

spreading the practice of considering human factors

in the design of production and logistics systems,

which is opposed to the current approaches to

engineering design. In general, researchers point out

that today's transportation logistics problems require

solutions based on intelligent transportation systems

that take advantage of artificial intelligence, [9],

[10].

Mapping of a set of cloud and distributed

computing facilities, virtualization facilities, and

storage systems is performed to visualize the

designed distributed infrastructure. The

infrastructure at the stage of operation should

provide the implementation of a set of services that

form the main volume of operations that load the

distributed infrastructure, which includes

transportation and logistics services proper and

related information and technological services for

TLC users.

Variability in the design of TLC deployment

scenarios involves the use of simulators to conduct

preliminary studies and build fundamentally feasible

scenarios for the implementation of distributed

infrastructure. Simulators allow for diagnosing the

deployment environment, building device and

application integration scenarios based on input

parameters for CPU and storage (memory) usage,

communication channels, and bandwidth.

Separate studies focus on demonstrating the

capabilities or comparing simulators for configuring

components and configuring cloud, fog, or edge

environments, [11], [12]. Given the diversity of

distributed infrastructure topology, it is believed that

there is no simulator capable of covering all aspects

of each experiment, [1].

It has been observed that design teams

experience the greatest difficulty in developing

simulation scenarios for mobile sensors or mobile

devices. While for TLC deployments, as the node

element of a backbone network, scenarios with

integration of mobile devices are of particular

interest. TLCs of different capacities form the

backbone network, which is made up of the

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

244

Volume 11, 2023

necessary and sufficient number of synchronized

TLCs to be commissioned. Accordingly, the

integration of mobile sensors and mobile devices

into the distributed infrastructure will ensure the

efficient organization of freight intermodal routes

and scheduled freight speeds.

Another challenge, in addition to building TLC

deployment scenarios based on the advantages of

mobile devices and sensors, is determining the

scalability boundaries of the distributed architecture.

Designing TLC within the edges of a backbone

network assumes a simulator capable of handling

scenarios with hundreds or thousands of

components without sacrificing computational

resources. Regardless of the functional

characteristics of the various simulators, their use

involves parameter loading. And it is logical to

assume that simply enumerating their combinations

is not the best option. The optimal solution is to load

a mapped network architecture configuration in

emulation mode. This practice is widely used to

evaluate critical components of the software and

application architecture, [13].

Application of the simulator, however, does not

solve the separate problem – to take into account the

factor of assessing the location of logistics

infrastructure, [14], because we are talking about a

chain of TLC nodes within the backbone network.

The complexity of the task lies in the uneven

density of nodes and varying lengths of backbone

networks. Therefore, the deployment of a new TLC

node includes such a parameter as the demand for

processing freight flow data not provided by the

existing nodes or resulting from errors in the design

and operation of the information architecture.

Calculation of the demand should be based on the

volume of operations that load the distributed TLC

infrastructure of each node and section of the

backbone network.

Another factor to be considered in the design of

the distributed infrastructure for TLC within the

backbone network is the rational use of the potential

of the cloud, fog, and edge layers. The potential of

the layers is a topic of discussion at the intersection

of the three concepts of edge technologies: edge

devices, edge computing, and edge analytics, [15].

The range of possible solutions is correspondingly

narrowed when the TLC design involves all three or

at least two frontier technologies, [16]. For example,

peripheral devices cannot execute advanced

analytical algorithms due to various constraints such

as limited power supply, small memory capacity,

limited resources, etc. And yet, using the potential

of the cloud, fog, and edge layers to design a TLC

information architecture within the backbone

network is the most promising solution, [17].

Based on the fact that the project of building an

information architecture involves the

implementation of an information support system

for each of the nodes within the backbone network,

it should be said that the volume of processed

information is so large that the project involves data

processing centers with specifications close to cloud

nodes. However, if we talk about deploying TLC,

which is a group of specialized terminals for the

implementation of intermodal transportation, such

distributed infrastructure does not require large

computing power. A rational solution, then, is to use

fog and edge layer nodes to assemble a

configuration of devices located at the edge of the

network with wireless connectivity capabilities and

allow the use of mobile applications.

It is possible to reconcile such diverse distributed

infrastructure requirements by applying a universal

approach to mapping deployable TLC based on a

model that combines all three layers in the

architecture, [18].

A generalization of the results on the research

topic, [3], [12], [14], [17], showed the insufficiency

of empirical (applied) solutions for modeling the

structure of network components. We faced the task

of effectively utilizing the hardware and software of

the fog and edge layers of the architecture. With all

the variety of hardware choices for distributed

infrastructure design in the given studies, [6], [7],

[9], [16], no solution adequate to the task was found

that could be deployed within the framework of

TLC architecture development.

3 Problem Solution

To begin with, let’s highlight the main structural

blocks – the departments that make up the pilot

transportation and logistics center. These are the

TLC security service, input and output cargo

terminals for rail and automotive transport, transport

fleet, cargo distribution center, warehouse complex,

customer service department, economic department,

and customs and logistics department, as well as

technical and IT departments as auxiliary services.

The structure and the order of interaction between

the elements of the structure are shown in Figure 1

(Appendix).

The following is a description of the entities

shown in Figure 1 (Appendix) and the links between

them. In the diagram, solid lines show the routes of

incoming and outgoing traffic and cargo, and dashed

lines show the information communication within

the complex. The flows of arriving traffic equipped

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

245

Volume 11, 2023

with passes arrive through the entry checkpoint. The

specific checkpoint is determined depending on the

type of cargo traffic (automotive or rail) to the

appropriate type of terminal. Next, unloading,

handling, labeling, and registration of incoming

cargo takes place on the territory of the terminal.

Data on the incoming cargo enters the terminal

database, as well as the economic and customs-

logistics department databases. Then the transport is

sent and placed in the parking lot or in the depot of

the transport fleet, where, if necessary, it is

additionally repaired and serviced. After being in

the transport park, the vehicle can be loaded with

new cargo as part of the outbound freight process

through an outbound terminal of the appropriate

type. Information about this is also recorded in the

databases of terminals, economic and customs, and

logistics departments. The end of the logistics

process within the TLC is the departure of the cargo

after verification of the compliance of the exported

cargo with the travel documents at the exit

checkpoint.

The logistics process in terms of a business

process can be considered more broadly, but in

conjunction with the hardware and architecture of

the TLC network, the event “the departure of the

cargo” is considered the final event. The processes

represented on the map are terminated by the event,

as the current study considers the logistics processes

of the internal telematics contour. The outer

telematics contour might also be an object for

mapping, however, this is beyond the scope of this

study.

As for the cargo, once it has been registered, it

goes through the cargo distribution center to the exit

terminal or, depending on the type and dimensions,

to the appropriate sector of the warehouse complex.

Information about this is recorded in the database of

the cargo distribution center. After arrival,

verification of marking, and placement of cargo in

the appropriate sector of the warehouse complex,

the information is also recorded in the database of

the complex.

Interaction with customers is carried out through

the customer service department, and records are

made and added to the department’s database at

each stage of the logistics process. The entire

document flow for the transport of goods and

additional services provided by the TLC, the

customer data is supplemented by the corresponding

entries in the databases of the economic and

customs and logistics departments and is associated

with the cargo stored and already available in the

database of the TLC warehouse complex.

The presented TLC transport and information

flow diagram (Figure 1, Appendix) shows the links

of information and transport flows of the enterprise

and is the departure point for the subsequent

mapping.

Mapping of a set of facilities of the distributed

architecture of the TLC is carried out in the system

in terms of the cloud-fog-edge-user model of the

device, [19], [20]. The following presents the

proposed mapping of computing and networking

devices that are part of the warehouse complex

architecture. As an example, the working diagram of

mapping for the warehouse complex is shown, since

it is for this building block of the TLC architecture

that most of the distributed infrastructure devices

are required.

According to the CFEU model, [18], for each of

the computational vertices it is necessary to specify

a set of parameters of the form:

 

1 1 1 1 1

41 41 41 41 4 1

, , ,

E E E E E

oe e e enteiu

V c w tc tc

(1)

where for the vertice

with the number

the level

– vertice internal storage volume

– computing power of the vertice

in n

– vertice input capacity

out n

– vertice output capacity

, and for each of

the edges – by parameters of the form:

 

KL KL

mn mn

tcE

(2)

where its weight

– between these vertices.

To mark the vertices on the map we introduce

indices of the form

wXY

(3)

where w, W is the first letter of the name of the TLC

architecture layer to which the specified vertice

belongs, X is the vertice hierarchy level in the layer,

Y is the ordinal number of the vertice, Z is the

number of the vertice group to which the vertice

belongs at the current hierarchy level.

Thus, an entry of the form

 

1 1 1 1 1

31 31 31 31 3 1

, , ,

E E E E E

oe e e enteiu

V c w tc tc

(4)

will mean "computational vertice, level 3, at layer E

(edge) with computational power

, storage

capacity

, input throughput capacity

, and

output throughput capacity

out

», and a notation of

the form

 

1 1 1 1

31 , 11 31 , 11

EU e

e u u

tcE

(5)

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

246

Volume 11, 2023

will mean "a channel between vertices at layer E

(edge) level 3 and layer U (user) level 1 with

throughput capacity

».

For the user layer vertices (sensors, command

interpreters, and users), since they are the source of

computational tasks and data, having only the output

bandwidth, the set of parameters is valid:

 

00 , ,0,

tun ou un

V tc

(6)

For command interpreters in the same layer,

converting verbal and physical units of employee

interaction into commands for computers and

mobile devices of the edge layer, it is true

 

0 , , ,0

U U U tun in un ou un

V tc tc

(6)

The basic part of the devices that relate directly

to the edge and user layer of the warehouse complex

is shown in Figure 2 (Appendix).

The edge layer contains the main processing

units of automatic forklifts and AGV carts (ALD),

warehouse drones (Dr), zonal RFID scanners (ZRF),

employee personal computers (PC), etc. The

compute units are connected via zonal routers

(Rout) and hubs (Hubs) into a single network and

transmit data via a local multiport switch (Sw. L) to

the local warehouse server (Srv. L) as well as higher

in the hierarchy. The local warehouse server stores

and processes the main databases about the contents

of the warehouse sectors. The lower, user layer

contains the sets of sensors (S) associated with the

warehouse machinery, the employee-users of the PC

(U) as sources of tasks, and the interpreters (Intp) of

the commands they enter into the PC. In addition,

since there are RFID-tagged cargoes within the

warehouse complex, the layer contains the tags of

this cargo (RFt). Note also that the position of the

cargo tag is periodically fixed by remote RF

communication with the scanner, in the range of

which such a tag.

So, having presented the hierarchy of the main

means of the distributed infrastructure of the

warehouse complex, it makes sense to complement

the level of data representation. Next, let us describe

the infrastructure elements that are located within

the warehouse complex, but are not directly related

to this structural unit, but are part of another

structural unit - the TLC security service (Figure 3,

Appendix).

Figure 3 (Appendix) shows that the edge layer of

the architecture contains the RFID scanners of the

pass system (PRF), the camera electronics (VSC),

and the firefighting and alarm system (FEW),

physically connected to the security servers via the

network via hubs or routers. The user layer contains

the camera sensors and the public address and fire

suppression systems, as well as the radio frequency

zone passes (RFp) carried by employees and

visitors.

The order of interaction between the cloud, fog,

and upper part of the edge layer of the TLC

warehouse complex architecture is shown in Figure

4 (Appendix).

As shown in Figure 4 (Appendix), the local switch

of the warehouse complex (Sw. L) is the link to the

main warehouse server (Srv. WH) for the above-

described automated and electronic warehouse

equipment. The main warehouse server is located in

the fog layer of the architecture. It stores data on the

contents of the warehouse, past movements, and the

location of the cargo in the warehouse and

distributes them to the warehouse sectors. In

addition, preliminary calculations of routes for

automated warehouse equipment are performed on

the warehouse server. At the same time, this switch

makes it possible to establish a connection with the

servers of other TLC departments to transfer some

of the warehouse data corresponding to their

content. For example, the server of the customs and

logistics department (Srv. CLD) receives data on

customs documents issued for the cargo, and the

server of the economic department (Srv. ED)

receives data on financial operations related to the

cargo in the warehouse.

Servers in this layer have sufficient performance

to cope with the tasks of cargo information storage

and routing. In addition, communication with a

large cloud server (Srv. Cloud) TLC is provided

through the backbone network equipment (Sw.D) to

perform more complex calculation operations and

backup data storage. Backing up local data with its

duplication in several storages is necessary in case

of failure of server equipment or network equipment

along the data route. Data storages are the most

unstable components of computer and server

systems because they are subjected to constant high

load and work in servers continuously for long

periods, [21]. The same reasoning holds for server

hardware along the data path.

As the main solution for the implementation of

storage, processing, and routing of data streams it is

proposed to use servers, storage, and network

equipment of the Open Compute Project standard,

[22]. We believe that the use of this standard will

allow us to avoid the risks associated with changes

in corporate policy regarding the distribution of

licensed products. In particular, the manifestation of

this risk is the inaccessibility of direct delivery of

hardware from European and American vendors to

the Russian Federation due to the complicated

geopolitical situation.

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

247

Volume 11, 2023

As a basic solution for implementing the storage,

processing, and routing of data streams, it is

proposed to use servers, storage, and networking

equipment of the Open Compute Project standard

due to the unavailability of direct shipping to the

Russian Federation products of European and

American vendors due to the difficult geopolitical

situation, [23].

Thanks to the openness of the specifications and

the availability of full technical documentation for

the devices, such equipment is already being

produced domestically from local and Asian

electronic components available in Russia to meet

the growing demand for them from companies and

organizations, [24].

In this way, the proposed variant of mapping

provides an opportunity to construct the

configuration of devices at all levels of the four-

layer structure of the network architecture based on

the results of the operation with the map. The

mapping tool allows decomposing a set of devices

of different functional purposes, located on the

territory of one structural unit.

The study provides an example of the

decomposition of security and warehouse task

devices functioning together on a common territory

of the warehouse department. The used mapping

approach demonstrates the flexibility property stated

as the main requirement for the developed solution.

This property can be useful in terms of unplanned

changes in the technology stack and allows for

enhanced technological autonomy.

The proposed mapping option increases the

validity of network architecture design decisions

and accelerates and simplifies the process of

visualizing device configuration changes across

network architecture layers. And these very benefits

set the proposed results apart from other solutions

that do not have such a deep level of detail, and

therefore are quite complex in practical application.

4 Conclusion

The following results have been obtained as part of

this study. The task of visualizing the structure of a

transport and logistics center by mapping the

infrastructure elements and the connections between

them was set and justified at the beginning of the

study. As part of this justification, the aim was to

reduce entropy in decision-making processes in the

construction of the architecture of the TLC, taking

the design approach as a basis. The objectives were

the need to ensure the implementation of a set of

transport and logistics services and the need to

define scalability limits for such an architecture

within the departments and the complex as a whole,

with physical parameter limits and the specific

purpose of the devices in the different layers of the

infrastructure of the center as constraints.

In the course of the mapping, the main structural

units of the system and the relationships between

them were first identified and then, based on one of

these structural units, a system of notations was

described within a cloud-fog-edge-user model and a

map of interaction between technical devices and

automated solutions in their communication with

each other through network and switching devices,

and the information processes occurring in the

system were described.

Mapping a set of network architecture tools can

be applied in emulation mode on various device-

and-network cloud, fog, and edge infrastructure

simulators such as Simgrid, Yet Another Fog

Simulator (YAFS), iFogSim 2, etc., [12]. This will

reduce the number of approaches to the simulator to

diagnose the deployment environment and build

scenarios for device and application integration.

References:

[1] E. Del-Pozo-Puñal, F. García-Carballeira,

and D. Camarmas-Alonso, “A scalable

simulator for cloud, fog and edge computing

platforms with mobility support,” Futur.

Gener. Comput. Syst., vol. 144, pp. 117–130,

Jul. 2023, doi:

10.1016/J.FUTURE.2023.02.010.

[2] S. Bolgov, V. Haitbaev, and M. Kurnikova,

“Methods to Assess the Locations of

Transport and Logistics Centers in the

Backbone Network,” Transp. Res. Procedia,

vol. 68, pp. 771–777, Jan. 2023, doi:

10.1016/J.TRPRO.2023.02.107.

[3] T. Cui and S. Li, “System movement space

and system mapping theory for reliability of

IoT,” Futur. Gener. Comput. Syst., vol. 107,

pp. 70–81, 2020, doi:

https://doi.org/10.1016/j.future.2020.01.040.

[4] R. Mahmud, R. Kotagiri, and R. Buyya,

“Fog Computing: A Taxonomy, Survey and

Future Directions BT - Internet of

Everything: Algorithms, Methodologies,

Technologies and Perspectives,” B. Di

Martino, K.-C. Li, L. T. Yang, and A.

Esposito, Eds. Singapore: Springer

Singapore, 2018, pp. 103–130.

[5] S. P. Ahuja and N. Deval, “From Cloud

Computing to Fog Computing: Platforms for

the Internet of Things (IoT),” Int. J. Fog

Comput., vol. 1, no. 1, pp. 1–14, 2018, doi:

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

248

Volume 11, 2023

10.4018/IJFC.2018010101.

[6] N. Zhang, X. Zhao, and X. He,

“Understanding the relationships between

information architectures and business

models: An empirical study on the success

configurations of smart communities,” Gov.

Inf. Q., vol. 37, no. 2, p. 101439, Apr. 2020,

doi: 10.1016/J.GIQ.2019.101439.

[7] A. Dolgui and D. Ivanov, “Manufacturing

modelling, management and control: IFAC

TC 5.2 past, present and future,” Annu. Rev.

Control, vol. 49, pp. 258–263, Jan. 2020,

doi: 10.1016/J.ARCONTROL.2020.04.003.

[8] F. Sgarbossa, E. H. Grosse, W. P. Neumann,

D. Battini, and C. H. Glock, “Human factors

in production and logistics systems of the

future,” Annu. Rev. Control, vol. 49, pp.

295–305, Jan. 2020, doi:

10.1016/J.ARCONTROL.2020.04.007.

[9] L. S. Iyer, “AI enabled applications towards

intelligent transportation,” Transp. Eng., vol.

5, p. 100083, 2021, doi:

https://doi.org/10.1016/j.treng.2021.100083.

[10] B. Bermejo and C. Juiz, “Improving

cloud/edge sustainability through artificial

intelligence: A systematic review,” J.

Parallel Distrib. Comput., vol. 176, pp. 41–

54, 2023, doi:

https://doi.org/10.1016/j.jpdc.2023.02.006.

[11] A. Markus and A. Kertesz, “A survey and

taxonomy of simulation environments

modelling fog computing,” Simul. Model.

Pract. Theory, vol. 101, p. 102042, May

2020, doi: 10.1016/J.SIMPAT.2019.102042.

[12] M. Gill and D. Singh, “A Comprehensive

Study of Simulation Frameworks and

Research Directions in Fog Computing,”

Comput. Sci. Rev., vol. 40, no. C, 2021, doi:

10.1016/j.cosrev.2021.100391.

[13] A. P. Plageras and K. E. Psannis, “Digital

Twins and Multi-Access Edge Computing

for IIoT,” Virtual Real. Intell. Hardw., vol.

4, no. 6, pp. 521–534, 2022, doi:

https://doi.org/10.1016/j.vrih.2022.07.005.

[14] İ. Önden, F. Eldemir, A. Z. Acar, and M.

Çancı, “A spatial multi-criteria decision-

making model for planning new logistic

centers in metropolitan areas,” Supply Chain

Anal., vol. 1, p. 100002, 2023, doi:

https://doi.org/10.1016/j.sca.2023.100002.

[15] S. Nayak, R. Patgiri, L. Waikhom, and A.

Ahmed, “A review on edge analytics: Issues,

challenges, opportunities, promises, future

directions, and applications,” Digit.

Commun. Networks, 2022, doi:

https://doi.org/10.1016/j.dcan.2022.10.016.

[16] P. Williams, I. K. Dutta, H. Daoud, and M.

Bayoumi, “A survey on security in internet

of things with a focus on the impact of

emerging technologies,” Internet of Things,

vol. 19, p. 100564, 2022, doi:

https://doi.org/10.1016/j.iot.2022.100564.

[17] W. Qin, S. Chen, and M. Peng, “Recent

advances in Industrial Internet: insights and

challenges,” Digit. Commun. Networks, vol.

6, no. 1, pp. 1–13, 2020, doi:

https://doi.org/10.1016/j.dcan.2019.07.001.

[18] N. S. Shagov, N. A. Mamedova, and A. I.

Urintsov, “The Construction of the Graph

Model and Objective Function for the Cloud-

fog-edge-user [CFEU] Hybrid System,” in

2021 IEEE Conference of Russian Young

Researchers in Electrical and Electronic

Engineering (ElConRus), 2021, pp. 1946–

1950, doi:

10.1109/ElConRus51938.2021.9396442.

[19] N. Krishnaraj, A. Daniel, K. Saini, and K.

Bellam, “Chapter Fifteen - EDGE/FOG

computing paradigm: Concept, platforms and

toolchains,” in Edge/Fog Computing

Paradigm: The Concept Platforms and

Applications, vol. 127, P. Raj, K. Saini, and

C. B. T.-A. in C. Surianarayanan, Eds.

Elsevier, 2022, pp. 413–436.

[20] M. García-Valls, A. Dubey, and V. Botti,

“Introducing the new paradigm of Social

Dispersed Computing: Applications,

Technologies and Challenges,” J. Syst.

Archit., vol. 91, pp. 83–102, 2018, doi:

https://doi.org/10.1016/j.sysarc.2018.05.007.

[21] L. Hu, L. Han, Z. Xu, T. Jiang, and H. Qi,

“A disk failure prediction method based on

LSTM network due to its individual

specificity,” Procedia Comput. Sci., vol. 176,

pp. 791–799, 2020, doi:

https://doi.org/10.1016/j.procs.2020.09.074.

[22] About Open Compute Project. Open

Compute Project.

https://www.opencompute.org/about.

[23] F. Register, “Addition of Entities to the

Entity List.” federalregister.gov/d/2023-

10684.

[24] “How we used an open standard to create a

Russian server,” [Kak my ispol'zovali

otkrytyj standart dlja sozdanija rossijskogo

servera] Tribune at vc.ru.

https://vc.ru/tribuna/552036-kak-my-

ispolzovali-otkrytyy-standart-dlya-

sozdaniya-rossiyskogo-servera.

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

249

Volume 11, 2023

Appendix

Fig. 1: Scheme of transport and information flows of the transport and logistics complex.

Fig. 2: Map of the information infrastructure of the lower levels of the warehouse complex on the

CFEU model.

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

250

Volume 11, 2023

Fig. 3: Map of the added information infrastructure of the security service at the lower levels of the warehouse

complex on the CFEU model.

Fig. 4: Map of the information infrastructure of the upper levels of the warehouse complex on the CFEU model.

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

251

Volume 11, 2023

Contribution of Individual Authors to the

Creation of a Scientific Article (Ghostwriting

Policy)

Nikita Shagov performed formal analysis and

investigation.

Natalia Mamedova conducted data curation and

formed a methodology.

Arkadiy Urintsov was responsible for acquiring

funding, administering the project.

Sources of Funding for Research Presented in a

Scientific Article or Scientific Article Itself

This study was financed by a grant from the

Plekhanov Russian University of Economics

Conflict of Interest

The authors have no conflict of interest to declare.

Creative Commons Attribution License 4.0

(Attribution 4.0 International, CC BY 4.0)

This article is published under the terms of the

Creative Commons Attribution License 4.0

https://creativecommons.org/licenses/by/4.0/deed.en

_US

WSEAS TRANSACTIONS on COMPUTER RESEARCH

DOI: 10.37394/232018.2023.11.22

Nikita Shagov, Natalia Mamedova, Arkadiy Urintsov

E-ISSN: 2415-1521

252

Volume 11, 2023