[image] [image] Ressource protégée - Inria - Institut national de recherche en sciences et technologies du numérique [Accéder directement au contenu](#)

[image] [image]

* [Documentation](#)

* FR
  Français (FR)

* Anglais (EN)
  Se connecter

* [Portail HAL Inria](#)

* Recherche
  Loading...

## Recherche avancée

Information de documents

Titres

○ Titres

○ Sous-titre

○ Titre de l'ouvrage

○ Titre du volume (Série)

○ Champ de recherche par défaut (multicritères) + texte intégral des PDF

○ Résumé

○ Texte intégral indexé des documents PDF

○ Mots-clés

○ Type de document

○ Sous-type de document

○ Tous les identifiants du document

○ Identifiant HAL du dépôt

○ Langue du document (texte)

○ Pays (Texte)

○ Ville

○ À paraître (true ou false)

Ajouter
<figure><img src="image_1.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
## Auteur

### Auteur (multicritères)

○ Auteur (multicritères)

○ Auteur : Nom complet

○ Auteur : Nom de famille

○ Auteur : Prénom

○ Auteur : Complément de nom, deuxième prénom

○ Auteur : Organisme payeur

○ Auteur : IdHal (chaîne de caractères)

○ Auteur : Fonction

○ Auteur : personID (entier)

○ Auteur : Identifiant de l'organisme payeur

○ Auteur : Identifiant de la structure

○ Directeur de thèse

○ Éditeur

○ Éditeur scientifique

○ Éditeur de la série

## Ajouter

### Structure

### Structure (multicritères)

○ Structure (multicritères)

○ Structure : Acronyme

○ Structure : Nom

○ Structure : Code

○ Structure : Pays

○ Structure : Type

○ Structure : État dans le référentiel

○ Structure : Identifiant HAL de la structure

○ Structure/équipe de recherche : Pays

○ Structure/regroupement d'équipes : Pays

○ Structure/laboratoire : Pays

○ Structure/regroupement de laboratoires : Pays

○ Structure/institution : Pays

○ Structure/regroupement d'institutions : Pays

## Ajouter
Tool and Method for Obtaining End-to-End
Reliability Parameters of Wireless Industrial
Networks

Christian Alan Krötz¹, Max Feldman¹, Gustavo Pedroso Cainelli¹, Gustavo Künzel², Carlos Eduardo Pereira¹, and Ivan Müller¹

¹ Federal University of Rio Grande do Sul (UFRGS), Porto Alegre, RS, Brazil
christianalank@gmail.com, maxfeldman@outlook.com,
gustavo.cainelli@gmail.com, cpereira@ece.ufrgs.br, ivan.muller@ufrgs.br

² Federal Institute of Education, Science and Tecnology of Rio Grande do Sul
(IFRS), Farroupilha, RS, Brazil
gustavo.kunzel@farroupilha.ifrs.edu.br

**Abstract.** Wireless communication systems have been increasingly employed in the industry. In this context, the WirelessHART and ISA 100.11a protocols are being used due today due to the pioneering and high robustness. This work has as general objective to study the end-to-end latency of communications in wireless industrial networks. For this purpose, a tool for communication with the network gateway, with ability to extract information from the field devices and the gateway itself, is developed and used in case studies. The case studies contemplate methods to evaluate the quality of service of the network, by observing the end-to-end latency, in diverse failure situations. The faults are injected into the network and monitored by the developed tool itself. Using WirelessHART as a case study, aiming the evaluation of the applicability of these networks in the industrial processes control. The results show that the tool is capable of analyzing and obtaining the latency data of the network in a concrete manner, and its use is adequate for the most diverse studies on wireless industrial network communication.

**Keywords:** WirelessHART · Reliability · Robustness · Latency · Wireless networks · Industrial networks.

# 1 Introduction

Industrial Wireless Sensor Networks (IWSNs) are gaining boost in relation to the wired technologies, as they offer benefits such as low operating cost, ease of installation, self-configuration and flexibility, which make them desirable for industrial applications [6]. As a consequence of its enormous potential, in the last decade, efforts have been made to make IWSNs technology reliable, robust, interoperable, and ready to replace traditional technologies [8]. Over time, IWSNs have been standardized and protocols such as IEEE802.15.4e, OpenWSN, WirelessHART (WH), Zigbee PRO, ISA100.11a and WIA-PA have been developed.
Autres

Champ de recherche par défaut (multicritères)

○ <u>Champ de recherche par défaut (multicritères)</u>

○

○ <u>Revues (multicritères)</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Titre abrégé</u>

○ <u>Revue : Titre</u>

○ <u>Revue : Identifiant interne</u>

○ <u>Revue : Date de début de publication</u>

○ <u>Revue : ISSN électronique</u>

○ <u>Revue : ISSN</u>

○ <u>Revue : Éditeur</u>

○ <u>Revue : Couleur dans SHERPA/RoMEO</u>

○ <u>Revue : État dans le référentiel</u>

○

○ <u>Colloque (multicritères)</u>

○ <u>Colloque : Titre</u>

○ <u>Colloque : Organisateur</u>

○ <u>Colloque : date de début (Année)</u>

○ <u>Colloque : date de fin (Année)</u>

○ <u>Conférence invitée (oui/non)</u>

○

○ <u>Projets ANR (multicritères)</u>

○ <u>Projet ANR : Acronyme</u>

○ <u>Projet ANR : Acronyme du programme</u>

○ <u>Projet ANR : Code décision (référence)</u>

○ <u>Projet ANR : Nom</u>

○ <u>Projet ANR : Identifiant interne</u>

○ <u>Projet ANR : État dans le référentiel</u>

○

○ <u>Projets européens (multicritères)</u>

○ <u>Projet européen : Acronyme</u>

○ <u>Projet européen : Identifiant de l'appel à projet</u>

○ <u>Projet européen : Référence</u>

○ <u>Projet européen : Nom</u>

○ <u>Projet européen : Date de fin</u>

○ <u>Projet européen : Financement</u>

○ <u>Projet européen : Date de début</u>
Despite the many advantages offered by IWSNs, there are also weaknesses, mainly related to reliability and latency, which may not be suitable for use in closed loop systems, as evidenced in several studies. Different types of failures can occur in IWSNs such as, network links failure, network congestion and corrupted or lost packets [7]. End-to-end latency control is critical to many applications and services based on Networked Control Systems (NCS), which has found application in multiple areas. For example, applications that include industrial automation, mobile sensor networks, remote surgery, automated road systems and unmanned aerial vehicles [4]. Although performance measurement of wired networks has been extensively studied, measuring and quantifying wireless network performance faces new challenges and requires different approaches and techniques [2]. Regarding the NCS study, it is argued that, since performance metrics, such as latency, can be measured accurately in the lower layers of the protocol, performance evaluation is facilitated in the upper layers of the protocol. This fact motivates the creation of a method to evaluate the quality of service the network, by obtaining latencies of end-to-end communications, in several faults situations.

This work presents methods to obtain End-to-End reliability parameters from IWSNs. A tool was developed to test the proposed methods where it is possible to evaluate the temporal behavior of the network in normal operation and under fault conditions. For convenience and scope of use, WH networks are used, but the method is extensible to other protocols.

The methods and tool developed serve two fundamental purposes: first, to evaluate IWSN employability in NCS, and second, to use as a site survey system. The first one refers to obtaining the latencies, which are the main problems related to the stability of the control system, and the second refers to a tool capable of obtaining previous data the evaluation of a possible installation of this type of network, where it is possible to know if a given space/time will meet the requirements. In this sense, the tool is able to emulate typical failures, such as locks, interferences, hardware failures, among others.

The presentation of this work is organized as follows: in Section 2, the basic concepts used throughout the work are presented. A study on the state of the art is presented in Section 3, presenting the works previously performed. The implementation of the tool is described in Section 4. The case studies for the validation of the proposal and the presentation of the results obtained are presented in Section 5. The work is finalized with the conclusions on the results obtained in the Section 6.

## 2 Theoretical Foundation

The IWSNs project depends significantly on the requirements of the particular application, since different applications may have different requirements and purposes [15]. The use of IWSNs has received high attention because of its advantages over wired networks. Typical IWSNs require little infrastructure,
○ Projet européen : État dans le référentiel

○ Projet européen : Identifiant interne

○

○ Date de production : année

○ Date de mise en ligne : année

○ Date de publication : année

○ Date d'écriture : année

○ Date de modification du dépôt : année

○ Date de dépôt : année

○ Date de publication électronique : année

○

○ Collection HAL (multicritères)

○ Collection HAL : catégorie

○ Collection HAL : Code

○ Collection HAL : Nom

○ Collection HAL : Identifiant interne

○

○ Identifiant interne du contributeur/déposant

○ Nom complet du contributeur/déposant

○

○ Domaines

○ Domaine primaire

○ Domaine racine

○ Sous-domaine niveau 1

○ Sous-domaine niveau 2

○ Sous-domaine niveau 3

○

○ Statut du document

○ Version du document

○ Type de dépôt

○ Type de document

○ ISBN

○ Numéro - référence

○ Identifiant DOI

○

○ Classification

○ Audience

○ Vulgarisation

○ Comité de lecture - texte (oui ou non)

○ Actes de colloque
help to improve product quality, increase production and flexibility, it is easy to install, and consequently reduce costs [6].

The WH protocol was developed with the goal of establishing a wireless communication standard for use in industrial applications. The WH is an extension of the HART [3] cabling protocol and enables full compatibility with legacy systems. Because it is a secure, time-synchronized, low-power protocol, it is suitable for industrial process control. Compatibility is defined primarily by the device description language (DDL) command structure previously developed by the HART organization [14].

The temporal evaluation refers specifically to obtaining the end-to-end latency, relevant parameter in wireless networks with multiple communications hops. The times in flows from bottom to top (uplink) and from top to bottom (downlink) are evaluated, where the largest value is the gateway (where external access to network) and the smallest value is the field device, connected directly to the plant.

The communications in the WH occur in time slots of 10 ms each [6]. The slots can be allocated through deterministic medium access mechanisms (TDMA), or shared between several nodes of the network, disputed through the mechanism CSMA-CA (Carrier sense multiple access with collision avoidance). WH adopts graph routing to deal with transmission failures through retransmissions and route diversity, and latencies are related to the scheduling and routing techniques employed. The maximum latency values are established by the scheduling of the communication so that the packets reach their destinations in known time, considering the maximum number of hops in the network and possible retransmissions. The connections between the nodes of the network are made through slots that are organized inside superframes that are repeated periodically to provide communication traffic in the network. According to the OSI (Open System Interconnection) seven-layer model, the WH contains the physical, link, network, transport layers, although the functionality of some of the layers is somewhat different from the original model.

Reliability and robustness are critical parameters in choosing a wireless communication protocol for use in industry [16]. Control and monitoring of processes in industrial environments have been changing in recent years, due to the growing advancement of research related to wireless industrial networks [5].

However, in spite of considerable efforts to provide mechanisms that increase network availability, reliability, security and maintainability, IWSNs maintain the propensity characteristic to fail due to phenomena of electromagnetic wave propagation [8].

According to [13], there are two types of failures that can occur in an IWSNs: transient failures, which generally affect communication links between network devices, and are typically caused by interference, coexistence or blocking, and permanent failures, which affect network devices, usually coming from the hardware. As an example of permanent failure, shutdown due to power failure, hardware failure or inadvertent removal of a network node can be considered, resulting in loss of communication between two pairs [9]. In this way, IWSNs must be
○ Référence interne

○ Financement

○ Collaborations

Ajouter

Lancer la recherche

Recherche experte (SolR)

Recherche experte (SolR)

Lancer la recherche
Vers la recherche avancée

• Déposer

Portail INRIA.HAL.SCIENCE
Les publications, logiciels... des scientifiques Inria

• Accueil

• Publications Inria

○ Consulter les derniers dépôts

○ Par équipe de recherche

○ Par auteur

○ Rapports de recherche et techniques

○ Livres blancs

○ Rapports d'activité des équipes

○ Statistiques

• Boite à Outils

○ X2Hal : importer par lot

○ Logiciels : créer le Codemeta.json

○ Créer mon IDHal

○ Créer mon CVHal

○ Haltools : créer ma page de publications

○ Haltools : extraire des données (réservé Inria)

○ Les bonnes pratiques

■ Comment bien s'affilier ?
reliable and function properly so that data can be reliably and securely delivered to their destination and with maximum latency met [1]. Some examples of typical failures of IWSNs are link failures, congestion and corrupted or lost packets due to blockages, change of communication routes or problems related to the coexistence of networks. Therefore, these failures were implemented, emulated, analyzed and will be discussed later.

## 3 State of the Art Analysis

In order to perform the study of the end-to-end communications latency in WH networks, and in order to evaluate and apply these networks in the control of industrial processes, a review of related articles was made.

The work develop by [16] and [17] developed a tool for obtaining end-to-end communication latency and insert failures in network. The former developed software allows to identify relevant questions for the verification and maintenance of WH networks, presenting as a contribution the ability to customize the tests, allowing user to evaluate data of greater interest for a specific purpose. In the case studies presented, it was possible to identify the most used routes of the network that lead to the identification of "bottlenecks", that is, network locations where latency can be increased due to routing overloads or places where the network is more susceptible to widespread failures due to local failures (blocks or hardware problems).

In order to insert network faults to carry out the case studies, [12] proposes a simulation model using Stochastic Petri Nets, in the Mobius tool, in order to evaluate WH networks in the presence of transient faults, assuming that these failures result from noisy environments that disrupt communication between devices. Later on [13], they perform the reliability assessment of the best practices indicated by the HART Communication Foundation (HCF), when the network devices are subject to permanent failures. The results presented by the authors show that best practices have different impact on the network.

The study developed by [11] approaches the problem of the analysis of assets in wireless industrial networks for the WH standard, implementing a monitoring system that allows to realize the most diverse management activities, regardless of manufacturer. Subsequently [10] presents an evaluation of the behavior of a WH network in a water level control process in a coupled tank system, using network latency and reliability as evaluation metrics, generating the results through tests real.

## 4 Methods and Materials

For the validation of the tool and method of analysis of the end-to-end reliability of wireless industrial networks, the following equipment was used.

Using a WH network, the tool developed uses the HART-over-IP protocol to communicate with the gateway. The gateway, in turn, communicates with the devices on the network through the WH access point. The application developed
* Quelle version puis-je déposer ?

* Choisir le bon « type de document »

* Mettre en valeur ses publications

○ Les tutos IES Inria

* Lier les notices dans HAL

* Umbrhal Inria pour l'accessibilité

* Personnaliser son CVHAL

* Créer et Personnaliser sa collection

• Documentation

○ Aide en ligne HAL

○ Aide en ligne Haltools

○ Aide en ligne X2hal

○ Tutoriels video HAL

○ Documentation API HAL

○ Ajouter des vignettes

○ Identifiant auteur IdHAL et CV

○ Compléter son dossier ORCID avec ses dépôts HAL

○ Inria et la Science Ouverte

X

X

X

Loading...

X

Le document que vous demandez est en access restreint
jusqu'au 2026-01-01 !

Revenir a la notice

Retourner à l'accueil

Contact

•

Ressources
use HART commands, implemented to obtain the desired data for analysis of
the network and the devices. The HART commands are encapsulated and sent
to the gateway, which responds to the request, sending the requested data.

The tool interface is divided into tabs, each with a different functionality. Among these functions, it is possible to send HART commands implemented according to the WH standard: 780 (Report Neighbor Health List), 782 (Read Session List), 783 (Read Superframe List), 784 (Read Link List), 787 (Report Neighbor Signal Levels), 800 (Read Service List), 802 (Read Route List), and 840 (Read Network Device's Statistics). It also consists of the implementation of commands that calculate the latency of end-to-end communications. Use of commands to insert network failures, implemented to reflect real situations in the use of IWSNs. The tool is capable of generating a graphical topology of the network, as well as presenting a table with some network data.

## 4.1 Latency Analysis Strategy

To calculate the latency of the end-to-end communications of the network two special commands were implemented, one writing (command 130) and one reading (command 131) of the process variables, making use of the variable ASN Snippet, the two bytes less of the Absolute Slot Number (ASN), variable that is part of the Network Protocol Data Unit (NPDU). However, because it is a restricted variable in network segments (without user access), it was decided to make changes in the firmware of the devices for the purpose of extracting the ASN.

When the tool communicates with the gateway, which in turn communicates with a device through the access point, an ASN that is in the NPDU header is created. With the firmware change made in the device, the packet received by the device passes through the physical and link layers, arriving at the network layer, where the ASN present in the received packet is obtained. The ASN of the moment the device received the packet is also stored, and, once the timeslot has a fixed time of 10 ms, the difference between the ASNs values is calculated, obtaining a direct relation with the latency end-to-end communication between devices. These variables are forwarded to the gateway, as a process variable, through another modification in the firmware (change of process variables). The tool, by having access to these variables, can calculate the latency of the network end-to-end communications, as shown in Figure 1.

As case studies for the validation of this work, the possible scenarios, from real WH networks, are the monitoring of a device by periodically surveying the topology and latency of the network. Once the monitoring is performed, a fault in the network is inserted through the developed tool, for example, interrupting a route through which the device communicated normally, evaluating the new topology of the network, together with the impact on the latency caused by the failure and the time to the network normalize.

With this, the tool provides relevant data for the verification of the applicability of the network in NCS, for example, providing the worst value of latency. Otherwise, the tool can be used as a site survey system for prior evaluation of
• Documentation

• FAQ

• API

• OAI-PMH

• AuréHAL

## Informations

• À propos

• Données personnelles

• Mentions légales

• Accessibilité

• Conformité RGAA

## Questions juridiques

• Je publie, quels sont mes droits ?

• Loi pour une République numérique

• Stratégie de non-cession des droits

• SHERPA/RoMEO

## Portails

• Portails institutionnels

• HAL

• HAL SHS

• HAL Thèses

• MédiHAL

## CCSD

• CCSD

• Episciences

• Sciencesconf
<figure><img src="image_2.png" /><figcaption>Fig. 1. Method for determining latency.</figcaption></figure>

a network to be installed in a plant, revealing maximum latency, "bottlenecks", qualities of the links, all obtained automatically. Events such as hardware failures and locks are emulated and reveal what can be expected from a definitive installation. Several decisions are made in advance, in order to produce a map of the location of definitive devices, taking into account the location of repeaters. Once the definitive place of use has been evaluated, the test network is removed and replaced by commercial devices of high economic value.

# 5 Case studies

For the validation of the proposal of this work, two case studies were performed that simulate real failures that occur in wireless industrial network environments, in which all the studies follow a standard for their realization. For the accomplishment of the case studies, the Wi-Analys sniffer was used for the data collection and later comparison with the data obtained by the tool. Data collection of end-to-end communications between the devices is performed for approximately two hours, starting the test until insertion of the fault and one more hour after insertion of the fault. The latency data are collected once every minute, thus producing approximately 120 samples in each case study.

The network topology is set up so that at least one device is not within reach of direct communication with the gateway, forcing the creation of a topology having at least one intermediate repeater device in communications with the target device. The latency data is always obtained in function of the device that does not have direct communication with the gateway, and the fault is inserted in an intermediate device, so that the end-to-end communications of the device can be analyzed.

## 5.1 Case Study 1: disconnecting a device from the network

For case study 1, the command 960 (Disconnect Device). This case study emulates a device failure, where it disconnects from the network. In a real situation, this kind of fault can occur due to, which can occur due to a hardware problem, battery drained or bad contact. In this case study, the end-to-end latency
between Tag 1 and Tag 1019 devices was evaluated. The Figure 2 presents the network topology highlighting the communication routes with the target device and being the gateway represented by the Tag 1.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Network topology of case study 1 before fault insertion.</figcaption></figure>

The special commands 130 and 131 are sent periodically to obtain the end-to-end latency of the communication with the tag device 1019. After period of approximately one hour there is an average of 55 communications with the device.

A fault is inserted in the network, referring to disconnection of Tag 1015 device (command 960). The Figure 3 presents the time diagram of the case study, denoting the period elapsed between normal operation and failure insertion.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Complete case study timeline 1.</figcaption></figure>
Again, after approximately one more hour, a further 64 communications were
collected, of which the Tag 1019 device only returned to respond after approxi-
mately 14 minutes.

With the disconnection of the device, a change in the topology of the network
is observed (Figure 4), changing the communication route with the Tag 1019
device.

<figure><img src="image_5.png" /><figcaption>Fig. 4. Topology of the case study network 1 after failure insertion.</figcaption></figure>

After data collection, a total of 119 communications were obtained, with a
variation of the average latency of 12.7 seconds of the communications. With the
data collected by the tool and checked with the sniffer data, it was possible to
verify that in case study 1 the Tag 1019 device took approximately 14 minutes
to find a new route and to respond to the requests again. After reestablishing
the communications with the Tag 1019 device, it was observed that there was
an improvement in the latency of the end-to-end communications between the
devices, with the change in the network topology. It is possible to observe that
not necessarily the topology of the network is formed aiming at a lower latency
in the communications between the devices.

## 5.2 Case Study 2: deleting communications links from a device

In case study 2, the command 968 (Delete Link) was used. In this case study,
links between devices are chosen to be deleted by the tool, to simulate signal
block. In large industrial plants such as refineries, water treatment plants or
chemical plants, blockages can occur when vehicles such as trucks, for example,
position themselves in front of a field device. The links can be deleted and later
reestablished, so that communication latency can be evaluated as well as changes
in the mesh network topology.
Given the network topology in Figure 5, sent the special commands to obtain the end-to-end latency of the communication with the tag device 1019, and sent the command 784 to obtain the communication links of the Tag device 1015.

<figure><img src="image_6.png" /><figcaption>**Fig. 5.** Topology of the case study network 2 before failure insertion.</figcaption></figure>

After one hour, there is an average of 75 communications with the device before insertion of the network failure.

The command 968 is sent to delete the communication links of the Tag device 1015 with the Tag device 1019, thereby inserting a network failure. The figure 6 presents the time diagram of the case study, denoting the complete period of the case study.

<figure><img src="image_7.png" /><figcaption>**Fig. 6.** Complete case study timeline 2.</figcaption></figure>

As a consequence of the failure, the manager generated a new communication route with the tag device 1019 as can be seen in Figure 7. After approximately
another hour, the study was paused and 62 more communications were obtained
with the Tag 1019 device.

<figure><img src="image_8.png" /><figcaption>Fig. 7. Network topology of case study 2 after fault insertion.</figcaption></figure>

After collecting the data, a total of 137 communications were obtained, hav-
ing a mean latency variation of 9.19 seconds between the communications. Again,
the data of the tool were collected, and these, checked with the data of the sniffer.

In this case study it is possible to verify that the change of the communica-
tion route was almost imperceptible, with a change also in the topology of the
network. Being possible to emphasize that the insertion of the fault caused the
sending of both downlink and uplink messages along the same path, which led
to an improvement in the latency of end-to-end communication with the device.

6 Conclusions

This work explored a method for the latency analysis of the devices in the net-
work, along with injections of failures caused by the developed tool, failures
related to disconnection of network devices, loss of communication between de-
vices and problems in the output power amplifier of a WH field device.

The tool allows analyzing and checking the characteristics of a WH network,
obtaining the state of the devices on the network, communication signal qual-
ity, device nickname, device address, and graphical visualization of the network
topology and presentation of statistics such as the amount and percentage of the
types of links. However, the main function of the tool is to obtain end-to-end
communications latency, which helps network analysis both in normal operation
and in case of failure. These failures are inserted in the network by the tool,
and it is possible to analyze the behavior of the network, which can provide
improvements to the industrial wireless communication protocols.
The case studies presented here show the applicability of the tool in the most diverse situations that occur in the daily use of industrial wireless communication systems. First, the method to obtain the end-to-end communication latency between the devices was validated through the Wi-Analys sniffer and used for the analysis of the case studies. The case studies addressed two distinct situations of failures that may occur in the industry.

The first case study emulates a failure that can occur due to a device hardware problem causing a permanent network failure, forcing the device to disconnect from the device. In this case study it was possible to verify that the device under analysis took about 14 minutes to find a new route and to respond to requests again.

In the second case study the problem was addressed in the communication between two devices whose consequence is the inability to exchange information through signal block, which may happen due to some obstacle to prevent communication between the devices. Having as a result an almost unnoticeable change of communication route compared to the first case study.

Through the case studies performed using the tool to communicate with the network gateway, extracting information from the field devices and the gateway itself, it was possible to verify that in the case studies there was an improvement in the latency of the communications between the devices, even after insertion of the fault. This does not mean that the topology of the network is formed aiming at a lower latency in the communications between the devices, since there are several types of routing and scheduling algorithms that can use the same input parameters, but with different objective functions (latency, energy consumption, number of hops), specifications that are unknown, as well as the algorithms. Therefore, the main route of a communication is not necessarily based on lower latency but on other unknown criteria, such as network robustness.

## References

1. Belkneni, M., Bennani, M.T., Ahmed, S.B., Kalakech, A.: Congestion control dependability assessment. In: 2018 14th International Wireless Communications Mobile Computing Conference (IWCMC). pp. 969–974 (June 2018). https://doi.org/10.1109/IWCMC.2018.8450347

2. Galloway, B., Hancke, G.P.: Introduction to industrial control networks. IEEE Communications Surveys Tutorials **15**(2), 860–880 (Second 2013). https://doi.org/10.1109/SURV.2012.071812.00124

3. HART, C.F.: Wirelesshart tdma data link layer specification, hcf spec-075 revision 1.1 (2008), parte Norma

4. Hespanha, J.P., Naghshtabrizi, P., Xu, Y.: A survey of recent results in networked control systems. Proceedings of the IEEE **95**(1), 138–162 (Jan 2007). https://doi.org/10.1109/JPROC.2006.887288

5. Machado, T., Muller, I., Winter, J., Dickow, V., Pereira, C.E., Netto, J.C.: Wirelesshart network analyzer with coexistence detection. In: 12th IEEE International Conference on Industrial Informatics (INDIN). pp. 696–701 (July 2014). https://doi.org/10.1109/INDIN.2014.6945598
6. Muller, I., Pereira, C.E.: Gerenciamento Descentralizado de Redes Sem Fio Industriais Segundo o Padrão WirelessHART. Tese de doutorado, Universidade Federal do Rio Grande do Sul, Porto Alegre (2012)

7. Paradis, L., Han, Q.: A survey of fault management in wireless sensor networks. Journal of Network and Systems Management 15(2), 171–190 (Jun 2007). https://doi.org/10.1007/s10922-007-9062-0, https://doi.org/10.1007/s10922-007-9062-0

8. Raposo, D., Rodrigues, A., Silva, J.S., Boavida, F., Oliveira, J., Herrera, C., Egas, C.: An autonomous diagnostic tool for the wirelesshart industrial standard. In: IEEE 17th International Symposium on A World of Wireless, Mobile and Multimedia Networks (WoWMoM). pp. 1–3 (June 2017). https://doi.org/10.1109/WoWMoM.2016.7523536

9. Saifullah, A., Xu, Y., Lu, C., Chen, Y.: Distributed channel allocation protocols for wireless sensor networks. IEEE Transactions on Parallel and Distributed Systems 25(9), 2264–2274 (Sep 2014). https://doi.org/10.1109/TPDS.2013.185

10. Santos, A., Lopes, D., Csar, J., Luciano, L., Neto, A., Guedes, L.A., Silva, I.: Assessment of wirelesshart networks in closed-loop control system. In: IEEE International Conference on Industrial Technology (ICIT). pp. 2172–2177 (March 2015). https://doi.org/10.1109/ICIT.2015.7125417

11. dos Santos, A.C.S., Silva, I.M.D.: Ferramenta para Análise de Ativos em Redes Industriais WirelessHART. Dissertação de mestrado, Universidade Federal do Rio Grande do Norte (2015)

12. Silva, I., Guedes, L.A., Portugal, P., Vasques, F.: Preliminary results on the assessment of wirelesshart networks in transient fault scenarios. In: ETFA2011. pp. 1–4 (Sep 2011). https://doi.org/10.1109/ETFA.2011.6059165

13. Silva, I., Guedes, L.A., Portugal, P., Vasques, F.: Dependability evaluation of wirelesshart best practices. In: Proceedings of 2012 IEEE 17th International Conference on Emerging Technologies Factory Automation (ETFA 2012). pp. 1–9 (Sep 2012). https://doi.org/10.1109/ETFA.2012.6489649

14. smar: Wirelesshart - características, tecnologia e tendências (2018), http://www.smar.com/brasil/artigo-tecnico/wirelesshart-caracteristicas-tecnologia-e-tendencias, [Online; acessado 10-Outubro-2018]

15. Wang, Q., Jiang, J.: Comparative examination on architecture and protocol of industrial wireless sensor network standards. IEEE Communications Surveys Tutorials 18(3), 2197–2219 (thirdquarter 2016). https://doi.org/10.1109/COMST.2016.2548360

16. Winter, J.M., Lima, C., Muller, I., Pereira, C.E., Netto, J.C.: Wirelesshart routing analysis software. In: Brazilian Symposium on Computing System Engineering. pp. 96–98 (Nov 2011). https://doi.org/10.1109/SBESC.2011.21

17. Winter, J.M., Pereira, C.E.: Software de análise de roteamento de dispositivos WirelessHART. Trabalho de conclusão de graduação, Universidade Federal do Rio Grande do Sul (2010)