Towards a Methodological Approach for the Deﬁnition of a Blockchain

Network for Industry 4.0

Charles Tim Batista Garrocho

1,2

, Karine Nogueira Oliveira

Carlos Frederico Marcelo da Cunha Cavalcanti

and Ricardo Augusto Rabelo Oliveira

Minas Gerais Federal Institute of Education, Science and Technology, Ouro Branco, Minas Gerais, Brazil

Computing Department, Federal University of Ouro Preto, Ouro Preto, Minas Gerais, Brazil

Vale Company, Parauapebas, Para, Brazil

Keywords:

Methodology, Deﬁnition, Deploying, Blockchain, Smart Contract, DApp, IIoT, M2M, Industry 4.0.

Abstract:

The Industrial Internet of Things is expected to attract signiﬁcant investments for Industry 4.0. In this new

environment, blockchain has immediate potential in industrial applications, providing immutable, traceable

and auditable communication. Blockchain gained prominence in the academy, being developed and evaluated

in several application areas. However, no study has presented methodologies to deﬁnition blockchain networks

in the industrial environment. To ﬁll this gap, we present a methodology that presents paths to follow and

important aspects to be analyzed for the deﬁnition and deployment of a blockchain network architecture. This

methodology can help in the appropriate choice of platforms and parameters of blockchain networks, resulting

in a reduction of costs for the factory and safety in meeting deadlines for industrial processes.

1 INTRODUCTION

Today, at the start of the fourth industrial revolution,

the role of industrial networks is becoming increas-

ingly crucial, as they are expected to meet new and

more demanding requirements in any new operational

context (Vitturi et al., 2019). A notable example in

this regard is the widespread adoption of Industrial

Internet of Things (IIoT), which requires a fast and re-

liable connection to all industrial systems and equip-

ment, especially real-time systems. This scenario re-

quires connectivity security even for the most remote

ﬁeld devices through adequate communication sys-

tems and interfaces.

Communication networks applied in an indus-

trial environment are used to monitor conditions,

manufacturing processes, predictive maintenance and

decision-making. These networks have typical con-

ﬁgurations, trafﬁc and performance requirements that

make them different from traditional communication

systems generally adopted by applications in homes.

Thus, industrial networks are designed to meet the re-

quirements derived from their various ﬁelds of appli-

cation, as well as the new scenarios generated by IIoT.

The most critical requirements are: time, reliability

and ﬂexibility (Felser, 2005).

Unlike many network protocols and information

systems already widely adopted in homes and busi-

nesses, Machine-to-Machine (M2M) communication

protocols and Industrial Process Automation Systems

(IPAS) are designed for speciﬁc industrial environ-

ments. IPAS are usually based on a ﬁve-level hierar-

chy, widely known in the automation ﬁeld as the IPAS

pyramid (Sharma, 2016). These systems are generally

adopted for continuous industrial processes, such as

oil and gas distribution, power generation and man-

agement, chemical processing and treatment of glass

and minerals.

The vertical and horizontal integration of IPAS

causes the traditional view of the IPAS pyramid to dis-

appear. Systems, such as business management, and

manufacturing, will change dramatically, while others

will be replaced by applications that quickly emerge

within the scope of IIoT platforms (P

erez-Lara et al.,

2018). When integration is automated, all informa-

tion can be collected and sent automatically from the

various systems implanted in a factory to any of the

parties involved. In this context, blockchain can de-

centralize or support decision-making in internal pro-

cesses of a factory and external processes in a supply

chain. This approach can make industrial automation

systems fully decentralized and automated.

138

Garrocho, C., Oliveira, K., Cavalcanti, C. and Oliveira, R.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0.

DOI: 10.5220/0010525701380147

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 1, pages 138-147

ISBN: 978-989-758-509-8

Blockchain-based M2M communication can ben-

eﬁt the horizontal and vertical integration of IPAS,

creating an immutable IIoT data ﬂow from the con-

trol and production level to the decision-making lev-

els (Wang et al., 2020). In addition, the inherent char-

acteristics of blockchain in integration can ensure that

industrial processes are auditable, generating greater

conﬁdence in decision-making. However, the incor-

poration of the entire blockchain network infrastruc-

ture to control processes in the industrial environment

without careful analysis, can lead to a loss of time and

resources, and even compromise time-sensitive indus-

trial processes.

Given this research problem, this work aims to

discuss several aspects related to the industrial en-

vironment in relation to blockchain. In view of this

discussion, a methodology for the proper deﬁnition

of blockchain networks in an industrial environment

is presented. This methodology presents aspects of

applicability, analysis, and parameters of blockchain

networks according to speciﬁc contexts of the in-

dustry. This approach facilitates the deployment of

blockchain networks, avoiding waste of resources or

that the deadlines of industrial processes are compro-

mised by the performance of the blockchain network.

The remainder of this article is organized as fol-

lows. Section 2 presents the background for under-

standing this work. Section 3 presents the related

work. Section 4 presents blockchain issues and chal-

lenges in the industrial context. Section 5 presents the

proposed methodology. Section 6 presents an appli-

cation of the methodology in an industrial proof of

concept. Finally, Section 7 presents conclusions.

2 BACKGROUND

Industry 4.0 refers to the revolution that transforms

manufacturing systems into cyber-physical systems,

introducing emerging information and communica-

tion paradigms.

2.1 Integration of Industry

One of the concepts of industry 4.0 is to have greater

integration between processes and sectors in factories

exchanging information in a faster and more efﬁcient

way for faster decision-making in order to increase

productivity, decrease losses, optimize resources and

lead to digital transformation. Therefore, integration

is one of the pillars of industry 4.0 and aims to con-

nect different areas, in order to extract information

that will be used to make continuous improvements

throughout the production process (Xu et al., 2018).

Each process of the factory dynamics generates

and is supplied with data. In an environment with-

out integration, there is the work of capturing all the

information generated by one stage of the manufac-

turing process and supplying the next, this is often

done manually, inefﬁciently and analogically. The

lack of integrated systems also means that manage-

ment levels have a much greater work of analyzing

whether what is being manufactured really matches

the demand received and whether suppliers and dis-

tributors are aligned with this production (P

erez-Lara

et al., 2018).

As the processes are diverse and involve different

agents in a factory, the concept of integration aligned

to industry 4.0 was divided into horizontal and verti-

cal integration. As shown in Figure 1, horizontal in-

tegration concerns the entire production chain, while

vertical integration integrates the functions developed

in the factory. To achieve the best results, there must

still be an interaction between vertical and horizontal

integrations to unite processes and optimize produc-

tion as a whole.

For the factory, horizontal integration represents

synchrony, loss reduction, and a saving of resources

as the demand of suppliers is adjusted to the demand

of customers. Besides, the higher quality of the prod-

ucts increases the consumer conﬁdence index towards

the factory, which generates customer loyalty. Also,

with delivery control and distribution monitoring, it is

possible to be sure that deadlines are met and also to

generate data to predict more accurate deliveries.

Vertical integration creates a ﬂow of data between

all IPAS levels more quickly and efﬁciently, reducing

the time for decision-making and improving the in-

dustrial management process. Therefore, vertical in-

tegration is in place when the employees, computers,

manufacturing machines are linked with each other,

communicate automatically with each other, and their

interaction exists not only in the real world but also in

virtual reality, in the model of the entire system.

Figure 1: Horizontal and vertical integration of industry.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0

139

2.2 IPAS Hierarchy

IPAS comprises many devices, logically positioned

at various hierarchical levels (see Figure 2) and dis-

tributed over large geographic areas (Sharma, 2016).

The ﬁeld device level contains sensors and ac-

tuators. The process control level consists of Pro-

grammable Logic Controllers (PLC) and Distributed

Control Systems (DCS) that provide an interface for

Internet Protocol (IP)-based network communication.

At the supervision level, the processes are moni-

tored and executed by factory workers through sys-

tems such as Supervisory Control and Data Acquisi-

tion (SCADA). Finally, corporate and factory man-

agement levels make decisions based on production

level data through the Manufacturing Execution Sys-

tem (MES) and Enterprise Resource Planning (ERP).

At the top of the IPAS pyramid, the systems are

asynchronous, while at the bottom of the pyramid the

processes are mainly synchronous and critical in real

time. At the bottom of the pyramid, control systems

have evolved into a state where they are distributed

and controlled by M2M communication. Blockchain

can guarantee decentralized and reliable M2M com-

munications, in which network nodes do not need a

reliable intermediary to exchange messages.

2.3 Blockchain and Smart Contracts

The blockchain network is a decentralized P2P net-

work, without failure points, whose transactions can-

not be deleted or altered. Blockchain is highly scal-

able, and all transactions are encrypted, making them

secure and auditable. As illustrated in Figure 3, at

the heart of this technology, there are consensus al-

gorithms, which are protocols designed to achieve

reliability in a network of multiple untrusted nodes

(Banerjee et al., 2018). Currently, there are two types

of consensus algorithms:

• Crash Fault Tolerance (CFT): regular fault-

tolerant algorithms, when it occurs to system mal-

functions in network, disk or server crash down,

they can still reach agreement on a proposal. Clas-

sic CFT algorithms include Paxos and Raft which

has better performance and efﬁciency and tolerate

less than a half of malfunction nodes;

• Byzantine Fault Tolerance (BFT): Byzantine

fault-tolerant algorithms, besides regular mal-

functions happen during consensus, it can toler-

ate Byzantine fault like node cheating (faking ex-

ecution result of transaction, etc.). Classic BFT

algorithm includes Practical Byzantine Fault Tol-

erance (PBFT), which has lower performance and

tolerates less than one third of malfunction nodes.

Figure 2: IPAS hierarchy levels.

Blockchain can be permissionless or permissioned

ust and Gervais, 2018). In the permissionless net-

work, transactions are validated by public nodes. In

a permissioned network, transactions are validated by

a group of nodes approved by the blockchain owner,

providing a more scalable and faster approach, but it

is more centralized. Permissionless systems are open

for all nodes to participate and thus provide a more

decentralized approach where the trade-off is speed

and scalability. Generally, permissionless network, to

increase network security and stability, consensus al-

gorithms apply a mining process that requires effort

from participants. For a permissioned network, where

all nodes are known and conﬁgured individually, there

is no inherent need to incentive miners.

A smart contract is a computer protocol intended

to digitally facilitate, verify, or enforce the negoti-

ation or performance of a contract. Ethereum, Hy-

perledger (Fabric, Sawtooth), and Corda are popular

smart contract platforms that are contributing signiﬁ-

cantly to the generation of Decentralized Applications

(DApps) (Voulgaris et al., 2019). As illustrated in Fig-

ure 3, DApp query the blockchain network through a

network node that executes the smart contract for the

ledger access. A decentralized oracle network (DON)

is used to establish a reliable connection with the ex-

ternal blockchain. External communication follows

the rules of a protocol that encourages all nodes to

tell the truth and punishes them for lying.

Figure 3: Blockchain-based smart contracts operation.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

140

3 RELATED WORK

Blockchain can increase the automation and security

of industrial processes. In this sense, following the

protocol of (Kitchenham, 2004), a research was car-

ried out to identify methodological solutions for the

integration of blockchain in the industrial context.

The results of this review showed that several arti-

cles propose methods to facilitate the blockchain de-

velopment process. Through research and situational

method engineering, the work (Fridgen et al., 2018)

proposes a method for the development of blockchain

use cases. The work (Wessling et al., 2018) pro-

poses an approach to decide which elements of a sys-

tem can beneﬁt from the use of blockchain. In the

work (Jurgelaitis et al., 2019), a method based on

Model Driven Architecture is proposed, which can be

used to deﬁne and specify the structure and behav-

ior of the blockchain. Finally, the work (Bett

ın-D

ıaz

et al., 2018) presents a methodology for integrating

blockchain into the food industry supply chain, in or-

der to understand the product life cycle.

As can be seen in recent related work, the main

objectives are to understand how to relate the prod-

uct process to the functioning of the blockchain and

to analyze the beneﬁts of this integration. Thus, de-

spite a great theoretical context presented by the re-

lated works and the discussion of some aspects related

to blockchain structure and technologies, it is not pre-

sented in depth how to deﬁne, develop, conﬁgure and

deploy blockchain architectures and networks in prac-

tice. Another important aspect is the metrics and sce-

narios for evaluating such approaches. As seen in re-

cent studies (Fan et al., 2020), performance evalua-

tions are often based on metrics like transactions per

second on the blockchain network. However, these

metrics do not take into account delays generated by

encrypting data and creating transactions on IIoT de-

vices that can have a greater inﬂuence on performance

and affect the timelines of time-sensitive processes.

It is understood, therefore, that the problems

presented may make it difﬁcult or even impossi-

ble to deploy a blockchain network in an industrial

plant. In this context, this work seeks to ﬁll this re-

search gap, presenting a methodology for implement-

ing blockchain networks in the industrial environ-

ment. Unlike related works, this proposed method-

ology presents paths to follow and important aspects

to be analyzed during the study for the deﬁnition of

a blockchain network. In addition, the methodology

presents important parameters and technologies to as-

sess the performance of the blockchain network in

order to identify the feasibility of implementing this

technology in time-sensitive industrial scenarios.

4 BLOCKCHAIN ISSUES AND

CHALLENGES IN INDUSTRY

Despite the advantages that blockchain can offer, its

adoption is a challenge mainly for traditional indus-

tries due to the difﬁculty in accepting changes and

also the high costs. The ﬁnal cost of deploying a

blockchain includes not only the costs related to the

software and hardware, but also the cost of the time

required to understand the underlying business pro-

cesses and to deﬁne precise smart contracts. In this

new context, the general agreement in the blockchain-

based IIoT ecosystem requires that all stakeholders

commit to investing and using this new technology.

In addition to the problem of investment in in-

frastructure, there is another problem of investment

in staff qualiﬁcation. Automation engineers and tech-

nicians are familiar with the use of ladder logic and

do not understand the scripting language, so they feel

comfortable working with today’s easy-to-use, reli-

able, proven functional and necessary industrial pro-

cess control systems. Therefore, while new technolo-

gies allow for higher levels of scalability, traceability,

integration, manufacturing capacity and autonomous

collaboration with other systems, the lack of skills and

understanding to explore IIoT and blockchain will

bring challenges.

According to (Khan et al., 2017), industrial au-

tomation is becoming complex gradually, and the data

generated in manufacturing alters to big data. Robots,

sensors, actuators, switches, industrial devices, and

M2M communication are the ore of big data in In-

dustry 4.0. Heavy usage of IIoT brought an immense

commute in the era of industries. Industry 4.0 is a

blend of modern smart technology and systems which

creates a deluge of data, which is quite challenging

to handle with classical tools and algorithms. There-

fore, in addition to the problems of investment in in-

frastructure and qualiﬁcation of the professional team,

there is a signiﬁcant challenge in the transfer and stor-

age of large amounts of IIoT data between the various

systems of the IPAS hierarchy.

Recently, big data analysis tools have been pro-

posed for Industry 4.0, which aim to facilitate the

cleaning, formatting, and transformation of industrial

data generated by systems by different levels of IPAS

hierarchy (Rehman et al., 2019). However, localiza-

tion and data processing becomes a signiﬁcant chal-

lenge, as the centralized communication architectures

used have high network trafﬁc and high latency, due to

the large volume of IIoT data. For decentralized com-

munication architectures, the impact on network traf-

ﬁc and latency is greater due to the consensus among

nodes of a blockchain network.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0

141

In the vast majority of recent approaches to cyber-

physical systems, the blockchain network is deployed

from the level of process control devices in the IPAS

hierarchy, allowing integration between synchronous

and asynchronous systems. However, in this new con-

text, synchronous IIoT applications acquire new fea-

tures (data encryption, transaction creation, genera-

tion and storage of public and private keys) that can

negatively inﬂuence the energy consumption of IIoT

ﬁeld devices that are deployed for long periods of time

(Barki et al., 2016). Thus, new encryption schemes

and techniques or new lightweight, efﬁcient and ro-

bust encryption algorithms must be designed with the

aim of reducing energy consumption in IIoT devices.

Some recent work, through the results of exper-

imental evaluations, points out that there are prob-

lems related to the high and variable blocking time

when changing a state in the blockchain network,

from the request (made by a requesting client device)

to a blockchain node to the commit of the transac-

tion which is the conﬁrmation among all blockchain

nodes that the state has been inserted or changed in

the ledger (Pongnumkul et al., 2017). These results

show that the problem is due to the standard opera-

tion of the blockchain and its consensus algorithms.

Thus, deﬁning fast and reliable consensus algorithms

is the key to enabling critical, real-time process con-

trols for IIoT devices. However, seeking the low la-

tency and reliability of a consensus algorithm at the

same time is a challenging task. The problem is fur-

ther compounded by slower and less reliable wireless

connectivity compared to wired connections assumed

in traditional consensus algorithms.

The communication delay is very sensitive in the

lower layers of IPAS, and can mainly inﬂuence the

monitoring and control of processes. Monitoring, car-

ried out at the supervisory level by shop ﬂoor op-

erators, is less sensitive, however, deadlines from

data collection to visualization by HMI cannot be

changed, with risks of compromising the entire prod-

uct process. At the process control level, the control

performed by PLC is highly sensitive, with low la-

tency and strict deadlines, here a single deadline break

can compromise the entire production process chain.

Blockchain-based solutions that guarantee execution,

control, monitoring and decision-making without in-

ﬂuencing the real-time systems deadlines, can provide

a breakthrough in industry 4.0 (Garrocho et al., 2020).

In order not to affect the time and strict dead-

lines of industrial process control systems, some ap-

proaches store IIoT data outside the blockchain net-

work and reduce latency with new paradigms. Re-

cent works in the literature apply concepts of fog and

edge computing in M2M communication approaches,

in which gateways are used close to ﬁeld devices as

a communication bridge for IIoT data collection and

IIoT data hashing only for storage on the blockchain

network (Wang et al., 2020). However, gateways can

increase the delay in delivering sensor and actuator

data to higher levels of IPAS, compromising decision-

making.

In addition to the problems of high and variable

block time, other evaluations have shown that some

blockchain platforms such as Ethereum do not allow

parallel operations (Sch

affer et al., 2019). However,

serial execution seems to be necessary: smart con-

tract sharing state and smart contract programming

languages have serial semantics in the current oper-

ation of the Ethereum system and its four testnets.

Although several works in the literature present new

ways to enable miners and validators to execute smart

contracts in parallel, this is still an open problem in

this area of research.

Finally, with IIoT devices in constant motion,

communication with the blockchain network will face

high dynamism and, consequently, large amounts of

connectivity failures (Lucas-Esta

n et al., 2018). This

scenario will contribute to the reduction of communi-

cation opportunities with the blockchain network, in-

creasing the communication delay between IIoT de-

vices and blockchain network. Also, if the process

control is in the blockchain network or higher layers,

production may be compromised.

5 METHODOLOGICAL

APPROACH

The problems become challenges for the deﬁnition of

a blockchain network in the industrial environment.

Therefore, this work presents a methodological ap-

proach (see Figure 4) divided into three layers: the

ﬁrst layer has to do with applicability and parts in-

volved; in the second layer, the analysis of aspects

involving the industrial process is presented; ﬁnally,

the third layer presents the steps for the development,

testing, deployment and monitoring of the blockchain

network. Each layer step is presented below:

0. Has the Team Knowledge of Blockchain Tech-

nologies Involved? As simple as it may seem,

this is a baseline and It is important that profes-

sionals involved in deﬁning the blockchain net-

work have a thorough understanding of the tech-

nologies involved. Unlike cloud architectures and

others, blockchain needs more attention due to

its distributed characteristics, which can lead to

a waste of time and resources;

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

142

1. Are Blockchain Technologies Suitable?

Blockchain characteristics are not be applied in

some cases. An applicability survey will ensure

that blockchain technologies will attend and pre-

serve all functional and temporal requirements.

Example: blockchain databases are based on

key/value for shorter response times; the data

replication between blockchain nodes makes data

with large volumes unsuitable for storage; smart

contracts do not generate external calls;

2. Has Agreement with Horizontal Parts, Part-

ners and Stakeholders? If the blockchain is to

be used for horizontal integration, all parties in-

volved must comply with the inherent character-

istics that the blockchain will apply in its inter-

nal processes. All horizontal elements will have

to invest in this new approach. Thus, contracts

establishing partnerships are essential to prevent

one of the elements of the supply chain don’t ac-

cept such changes after the implementation of the

blockchain network;

3. What Are the Real-time Requirements that

Must Be Met and How Critical Are They? In-

dustrial processes are time sensitive and may re-

quire tight deadlines of 100 ms for communica-

tion. In this case, fewer interactions with the

blockchain network are desirable. More important

process information can be chosen for on-demand

storage, while less relevant information can be left

out of the blockchain network. Another alterna-

tive is to deploy a device that monitors other de-

vices that are time sensitive, retrieving informa-

tion and reporting to the blockchain network;

4. Where Blockchain Will Be? The positioning of

blockchain network nodes can inﬂuence commu-

nication latency. In this context, edge comput-

ing approaches can be applied: depending on the

case, the blockchain network can be placed as a

new communication layer and the devices are just

DApps; in other cases, the blockchain network

can replace existing communication, making each

device a blockchain node. Turning a device into

a blockchain network node may represent greater

investment, but it also represents less latency as

element will be removed from communication;

5. Is the Fault Model and Blockchain Compati-

ble? Failure model analyses is critical step es-

pecially if the process is time sensitive. In some

industrial processes the mobility is small, while

in other processes the mobility can be extreme.

The main problem may be the loss of connection,

either due to characteristics of the industrial envi-

ronment, or due to limitations of wireless commu-

nication technology. In this context, it is impor-

tant that there is a failure model so that the system

tolerates the lack of connectivity to the blockchain

network and continues to function normally;

6. Which Type: Permissionless or Permissioned?

For horizontal integration, both suppliers and

customers can participate in the communication,

signiﬁcantly increasing the number of elements

in the network. In this case, permissionless

blockchain networks like Ethereum are the best

choices, but time-sensitive processes will not be

able to use this type of network because of the

poor performance they provide. As for vertical

integration, communication is internal and there-

fore all elements are known and reliable. In this

case, permissioned blockchain networks like Hy-

perledger Sawtooth or Fabric are the best choices,

providing times and latency closer to real-time

systems;

Figure 4: Blockchain network deﬁnition methodology for the industrial environment.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0

143

7. Which Consensus Method/Approach? The

choice of the type of blockchain network can di-

rectly affect the choice of the type of consensus

algorithm. For the permissionless blockchain net-

work, the most appropriate distributed consensus

is based on effort. Examples of such algorithms

are the BFTs. In permissioned blockchain net-

works, where nodes are identiﬁed, the use of a

vote-based consensus algorithm is relevant, as the

nodes involved trust each other, thus being able to

reach an agreement through a voting process. Ex-

amples of such voting algorithms are the CFTs;

8. Which Parameters Must Be Conﬁgured? The

conﬁguration of the blockchain platform is related

to the desirable parameters: deﬁne whether the

platform will perform the serial or parallel pro-

cessing of the blocks; deﬁne timeouts for DApps

and blockchain network; set manual or automatic

key sharing; deﬁne the number of nodes in the

blockchain network; deﬁne the types of metrics

to be evaluated, which allow analyzing the perfor-

mance of the blockchain network;

9. Which Blockchain Apps Must be Developed?

The development of smart contracts and DApps

are based on analysis of industrial process charac-

teristics. The smart contract can be used as: com-

munication intermediary; registration of informa-

tion; etc. DApp is the means of relating directly to

the industrial process, however, many devices are

like black boxes (in which the code is closed). In

this case, the ideal is to monitor data from these

devices, or to design new embedded devices;

10. The Blockchain is Tested? Deploy It! During

development, the blockchain network must be de-

ployed in test mode. This means that a consen-

sus simulation is performed in order to facilitate

development and testing. Thus, an alternation is

made between testing and development. The in-

jection of data simulating the industrial process

over long periods of time is necessary to assess

the long-term performance of the blockchain net-

work. After the tests, the production mode is de-

ployed, in which the chosen consensus algorithm

comes into action in all blockchain nodes;

11. Are the Blockchain and All System Perform-

ing? With the blockchain network in production

mode, monitoring the status of each blockchain

node should be performed in order to assess the

performance of: processing, memory, network la-

tency, consensus latency, etc. All nodes must

have similar performance, otherwise, a hardware

or software problem must be identiﬁed and cor-

rected. Corrected the problem, the blockchain

node re-incorporates the blockchain network and

updates its database with the newly inserted

blocks.

6 PROOF OF CONCEPT

The Dynamic Railway Scale (DRS) is one of the most

used resources in iron ore plants, in which wagons

are weighed in motion. Generally the PLC of a DRS

are closed boxes and the cost of maintenance is ex-

pensive. Developing of an open source PLC for DRS

would bring hardware and software openness, cost re-

duction and ﬂexibility. However, the ease of making

changes to the control logic becomes a point of atten-

tion with regard to the integrity of the data measured

by the DRS and, consequently, the measurement re-

sult may not be reliable due to the changes made.

To solve this problem, it is proposed to apply the

blockchain to the immutable record of any change in

the control logic or change in the calibration coef-

ﬁcients in the DRS, making the system transparent

and auditable. Thus, through this DRS system, the

methodology proposed in this work will be demon-

strated. Table 1 shows the DRS case study using our

methodology and Figure 5 illustrates the organization

of PLC devices in the DRS system.

Figure 5: DRS system environment and equipment.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

144

Table 1: Deﬁnition of the blockchain network for the DRS system through the methodological approach.

0. Has the Team Knowledge of Blockchain Technologies Involved? Yes. In this case, the iron ore miner main-

tains academic and professional agreements with a prestigious university and its graduate program in computing

and engineering. Its employees are trained in engineering and computing subjects. Blockchain is one of research

lines of this program, where this proof of concept is one of the prototypes under development.

1. Are Blockchain Technologies Suitable? Yes. The main objective will be to monitor operations (for example,

changes to control logic, calibration parameters, and weighing) performed by PLC of the DRS ensuring log records

on the blockchain. Using an IIoT device (in our case, Raspberry Pi 4 board) the monitored data is recorded on

the blockchain network through an intelligent contract. Data sent to the blockchain network does not take up much

storage space (about 0.5 kB each transaction). Thus, the blockchain network is used as an immutable storage system

for DRS operations.

2. Has Agreement with Horizontal Parts, Partners and Stakeholders? Yes. As the company only needs to

record all the control information of the DRS system in order to guarantee traceability and greater reliability in its

wagon measurements, the integration is only vertical between the levels of process control and supervision of the

IPAS pyramid. The agreement is done in level of system permissions that was done with success.

3. What Are the Real-time Requirements that Must Be Met and How Critical Are They? Industrial processes

are usually time sensitive. In this speciﬁc case, all logics (represented by structured text or ladder diagram) for

controlling the industrial process that are sensitive to time, continues to be executed directly by the PLC and not

by a smart contract on the blockchain network. Therefore, the strict time requirements of the DRS system are not

compromised. Then, all real-time requirements are in conformity.

4. Where Blockchain Will Be? Due to the constraints of external connectivity to the DRS environment, all

blockchain components are deployed directly to each DRS device avoiding conﬂicts between legacy PLC and

blockchain network. The aim is to reduce communication latency by applying concepts of edge computing. There-

fore, DApps communicate directly with the Rest API of the blockchain deployed on the IIoT device, with no

communication network delay. The reduced number of devices and the low cost of hardware that is supporting

blockchain system make the investment low by the company.

5. Is the Fault Model and Blockchain Compatible? Yes. As shown in Figure 5, the control devices of the DRS

system are installed close to the rails and protected from rain and sun. Therefore, there is no mobility on the devices

or on blockchain nodes that are deployed on the devices. In addition, a communication failure model is deﬁned,

in which Rest APIs are deployed in all blockchain nodes, ensuring continuity of operation in case one of the Rest

APIs stops working.

6. Which Type: Permissionless or Permissioned? Permissioned. The integration is vertical between the levels

of process control and process supervision of the DRS, and all devices are known and reliable. Therefore, the best

choice is a blockchain network with permission. The Hyperledger Sawtooth has fewer internal components and

better performance compared to other platforms.

7. Which Consensus Method/Approach? CFT type algorithm. Considering that the platform chosen was Hyper-

ledger Sawtooth and the type of network is permissioned, consequently the choice of the consensus algorithm will

be a CFT type algorithm. In this case, the Raft algorithm is deﬁned for consensus.

8. Which Parameters Must Be Conﬁgured? Looking for less delay in block processing, a parallel processing

parameter is deﬁned; due to the characteristics of the embedded systems, key sharing is performed manually on each

node; three blockchain nodes are deﬁned: two for the monitoring of the PLC of the DRS; and one for a workstation

that represents a blockchain network HMI device. Each node in the Sawtooth network is conﬁgured to generate

metrics and send them to the workstation that has Inﬂuxdb (https://www.inﬂuxdata.com/products/inﬂuxdb/) and

Grafana (https://grafana.com/).

9. Which Blockchain Apps Must be Developed? DApps for monitoring and Smart contracts for receiving transac-

tions and secure access. DRS DApps are designed to monitor PLC operations and submit this data to the blockchain

network. HMI DApps are designed to monitor changes in the blockchain network and provide visualization to a

shop ﬂoor operator. Smart contracts are developed to receive transactions from DApps, validate access to the de-

vice using keys and store this new state (with control logic, parameters and execution information) on the Sawtooth

blockchain network.

10. The Blockchain is Tested? Deploy It! As DApps and smart contracts are developed, the Hyperledger Sawtooth

platform’s non-consensus development mode is used. Block simulations with transactions that represent control

information are submitted to Sawtooth nodes and their behavior is evaluated by the HMI workstation using Grafana.

After performance testing and analysis, the consensus is changed to Raft, and each hardware receives its respective

actors.

11. Are the Blockchain and All System Performing? Yes. With the Sawtooth network and all other systems

in place, the performance monitoring of each device is performed through Grafana on the HMI workstation. Any

problem, a blockchain node can be interrupted and, after correcting the problem, the node can be deployed again

and communication with the Sawtooth network is restored with all blocks being recovered.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0

145

6.1 Scenarios and Metrics

Two DRSs are separated by a distance of 200 meters.

Each DRS has a PLC that is monitored by a Raspberry

Pi 4 (Quad core Cortex-A72 1.5 GHz, 4 GB of RAM).

A third device is a workstation (Intel Core i5-4200

2.60 GHz, 8 GB of RAM) for monitoring. Thirty ex-

ecutions were carried out in each scenario:

• Tranquility: sending to the blockchain network of

changes in control logic or calibration parameters

in the PLC of the DRS is considered. Thus, delays

involving only one transaction from each device

to the blockchain network were assessed;

• Stress: sending to the blockchain network of all

executions and measurements performed by the

PLC of the DRS is considered. Thus, delays were

assessed by sending 1000 transactions from each

device to the blockchain network.

An Ethernet/IP network with a rate of 100 Mbps is

used for communication between the three devices.

The following metrics were measured:

• Submit : total IIoT board delay for preparation

(hash generation, payload encoding) and transfer

of the transaction to the blockchain network;

• Latency: total delay from Rest API until conﬁr-

mation that the transaction has been conﬁrmed by

all blockchain nodes;

• Query: total delay in querying a transaction to

blockchain network and decoding the payload.

6.2 Results

The operations delays (submit, latency, and query)

found in the DRS blockchain system successfully es-

tablished from the methodology are illustrated in Fig-

ure 6. There is a slight increase in the time of the

stress scenario compared to the tranquility scenario.

This increase is related to a greater number of trans-

actions submitted to the blockchain network, which

generates a longer processing time to create the trans-

action, send data in the communication network and

process the transaction between the blockchain nodes.

Figure 6: Total time of blockchain operations.

In addition to the total time of each scenario, Fig-

ure 7 show the time and standard deviation of each

operation, which represents the variability of the data.

Considering the behavior of the latency operation in

the stress scenario, it is possible to observe an in-

crease in time in this scenario. The 1000 transac-

tion load has a greater effect because the operations

are replicated between the 3 nodes of the blockchain

network, generating a delay related to processing and

consensus time between the validator nodes.

The standard deviation for submit operation is

quite small, because this variation is only related to in-

terruptions caused by the board’s processor and mes-

sage forwarding over the network. The high variation

in latency operation is related to consensus and load

replication between nodes on the blockchain network.

Finally, the average variation of the query operation

is related to message forwarding and receiving over

the network, query processing on the blockchain net-

work, and decoding the message on the IIoT board.

Therefore, although the latency operation has a

short execution time, in the industrial scenario, the

standard deviation of this operation can make the sys-

tem unsafe. The variability of the data makes the

system unstable, especially in the scenario of stress.

Each time an operation is performed, it will result in

a high degree of unpredictability for its conclusion.

This variation in time in the stress scenario can affect

the fulﬁllment of the deadlines by which tasks must be

completed. In industrial systems, this time is not suit-

able for processes where it can delay decision-making

and compromise system time constraints.

So, for the tranquility scenario, the average exe-

cution time and the standard deviation of blockchain

operations can guarantee a time of around 100 ms.

However, in the stress scenario, data variability makes

communication inaccurate. Therefore, the applica-

tion of blockchain for M2M communication in time-

sensitive IIoT applications, has its operation affected

by the amount of interactions to be carried out on the

blockchain network. However, this problem does not

affect the DRS system, as the blockchain network is

used only for monitoring, and the process control that

is time sensitive remains on the PLC of the DRS.

Figure 7: Time of operations with standard deviation.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

146

7 CONCLUSION

Blockchain has the ability to revolutionize the indus-

try. In this context, we present a methodology for

deﬁning blockchain networks for the industrial envi-

ronment. This step-by-step methodology is easy to

follow and to be applied in the industry as well as

outside the industrial environment. In this approach,

aspects related to the strict and speciﬁc requirements

of industrial processes were addressed. As a future

work, we intend to extend the studies and discussion

of the methodological approach, incorporating new

distributed ledger technologies such as Tangle and

Hashgraph.

ACKNOWLEDGMENT

This study was ﬁnanced in part by the Coordenac¸

de Aperfeic¸oamento de Pessoal de N

ıvel Superior

- Brasil (CAPES) - Finance Code 001, the Con-

selho Nacional de Desenvolvimento Cient

ıﬁco e Tec-

nol

ogico (CNPQ), the Instituto Tecnol

ogico Vale

(ITV), Instituto Federal de Minas Gerais (IFMG), and

the Universidade Federal de Ouro Preto (UFOP).

REFERENCES

Banerjee, M., Lee, J., and Choo, K.-K. R. (2018). A

blockchain future for internet of things security: A po-

sition paper. Digital Communications and Networks,

4(3):149–160.

Barki, A., Bouabdallah, A., Gharout, S., and Traore,

J. (2016). M2m security: Challenges and solu-

tions. IEEE Communications Surveys & Tutorials,

18(2):1241–1254.

Bett

ın-D

ıaz, R., Rojas, A. E., and Mej

ıa-Moncayo, C.

(2018). Methodological approach to the deﬁnition of a

blockchain system for the food industry supply chain

traceability. In International Conference on Compu-

tational Science and Its Applications, pages 19–33.

Springer.

Fan, C., Ghaemi, S., Khazaei, H., and Musilek, P. (2020).

Performance evaluation of blockchain systems: A sys-

tematic survey. IEEE Access, 8:126927–126950.

Felser, M. (2005). Real-time ethernet–industry prospective.

Proceedings of the IEEE, 93(6):1118–1129.

Fridgen, G., Lockl, J., Radszuwill, S., Rieger, A.,

Schweizer, A., and Urbach, N. (2018). A solution in

search of a problem: A method for the development

of blockchain use cases. In AMCIS, page 11.

Garrocho, C. T. B., Silva, M. C., Ferreira, C. M. S.,

da Cunha Cavalcanti, C. F. M., and Oliveira, R.

A. R. (2020). Real-time systems implications in the

blockchain-based vertical integration of industry 4.0.

Computer, 53(9):46–55.

Jurgelaitis, M., Butkien

e, R., Vai

ciukynas, E., Drungilas,

V., and

Ceponien

e, L. (2019). Modelling principles

for blockchain-based implementation of business or

scientiﬁc processes. In CEUR Workshop Proceed-

ings: International Conference on Information Tech-

nologies, volume 2470, pages 43–47.

Khan, M., Wu, X., Xu, X., and Dou, W. (2017). Big data

challenges and opportunities in the hype of industry

4.0. In International Conference on Communications,

pages 1–6. IEEE.

Kitchenham, B. (2004). Procedures for performing sys-

tematic reviews. Keele, UK, Keele University,

33(2004):1–26.

Lucas-Esta

n, M. C., Sepulcre, M., Raptis, T. P., Passarella,

A., and Conti, M. (2018). Emerging trends in hybrid

wireless communication and data management for the

industry 4.0. Electronics, 7(12):400.

erez-Lara, M., Saucedo-Mart

ınez, J. A., Marmolejo-

Saucedo, J. A., Salais-Fierro, T. E., and Vasant, P.

(2018). Vertical and horizontal integration systems in

industry 4.0. Wireless Networks, pages 1–9.

Pongnumkul, S., Siripanpornchana, C., and Tha-

jchayapong, S. (2017). Performance analysis of

private blockchain platforms in varying work-

loads. In International Conference on Computer

Communication and Networks, pages 1–6. IEEE.

Rehman, M. H. U., Yaqoob, I., Salah, K., Imran, M., Ja-

yaraman, P. P., and Perera, C. (2019). The role of big

data analytics in industrial internet of things. Future

Generation Computer Systems, 99:247–259.

Sch

affer, M., Di Angelo, M., and Salzer, G. (2019).

Performance and scalability of private ethereum

blockchains. In International Conference on Business

Process Management, pages 103–118. Springer.

Sharma, K. (2016). Overview of industrial process automa-

tion. Elsevier.

Vitturi, S., Zunino, C., and Sauter, T. (2019). Industrial

communication systems and their future challenges:

Next-generation ethernet, iiot, and 5g. Proceedings of

the IEEE, 107(6):944–961.

Voulgaris, S., Fotiou, N., Siris, V. A., Polyzos, G. C., Jaati-

nen, M., and Oikonomidis, Y. (2019). Blockchain

technology for intelligent environments. Future In-

ternet, 11(10):213.

Wang, Q., Zhu, X., Ni, Y., Gu, L., and Zhu, H. (2020).

Blockchain for the iot and industrial iot: A review.

Internet of Things, 10:100081.

Wessling, F., Ehmke, C., Hesenius, M., and Gruhn, V.

(2018). How much blockchain do you need? towards

a concept for building hybrid dapp architectures. In

International Workshop on Emerging Trends in Soft-

ware Engineering for Blockchain, pages 44–47. IEEE.

ust, K. and Gervais, A. (2018). Do you need a

blockchain? In Crypto Valley Conference on

Blockchain Technology, pages 45–54. IEEE.

Xu, L. D., Xu, E. L., and Li, L. (2018). Industry 4.0: state

of the art and future trends. International Journal of

Production Research, 56(8):2941–2962.

Towards a Methodological Approach for the Deﬁnition of a Blockchain Network for Industry 4.0

147