Propostaarcaboucotolerancia-MeloNeto-2021

Prévia do material em texto

Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Doutorado Acadêmico em Ciência da Computação
Uma Proposta de Arcabouço para Tolerância a
Falhas Multicamadas em Sistemas IoT
Mário Andrade Vieira de Melo Neto
Natal-RN
Dezembro de 2021
Melo Neto, Mário Andrade Vieira de.
 Uma proposta de arcabouço para tolerância a falhas
multicamadas em sistemas IoT / Mário Andrade Vieira de Melo
Neto. - 2021.
 126f.: il.
 Tese (Doutorado) - Universidade Federal do Rio Grande do
Norte, Centro de Ciências Exatas e da Terra, Departamento de
Informática e Matemática Aplicada, Programa de Pós-Graduação em
Sistemas e Computação. Natal, 2021.
 Orientador: Prof. Dr. Gibeon Soares de Aquino Júnior.
 1. Engenharia de software - Tese. 2. IoT- Tese. 3.
Dependabilidade - Tese. 4. Tolerância a falhas - Tese. 5.
Detecção de erros - Tese. 6. Recuperação de erros - Tese. 7.
Confiabilidade - Tese. 8. Disponibilidade - Tese. I. Aquino
Júnior, Gibeon Soares de. II. Título.
RN/UF/CCET CDU 004.41
Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Elaborado por Joseneide Ferreira Dantas - CRB-15/324
Mário Andrade Vieira de Melo Neto
Uma Proposta de Arcabouço para Tolerância a Falhas
Multicamadas em Sistemas IoT
Tese de doutorado apresentada ao Programa
de Pós-Graduação em Sistemas e Computa-
ção do Departamento de Informática e Mate-
mática Aplicada da Universidade Federal do
Rio Grande do Norte como requisito parcial
para a obtenção do grau de Doutor em Ciên-
cia da Computação.
Linha de pesquisa:
Engenharia de Software
Orientador
Prof. Dr. Gibeon Soares de Aquino Jr.
PPgSC – Programa de Pós-Graduação em Sistemas e Computação
DIMAp – Departamento de Informática e Matemática Aplicada
CCET – Centro de Ciências Exatas e da Terra
UFRN – Universidade Federal do Rio Grande do Norte
Natal-RN
Dezembro de 2021
Tese de Doutorado sob o título Uma Proposta de Arcabouço para Tolerância a Falhas
Multicamadas em Sistemas IoT apresentada por Mário Andrade Vieira de Melo Neto e
aceita pelo Programa de Pós-Graduação em Sistemas e Computação do Departamento
de Informática e Matemática Aplicada da Universidade Federal do Rio Grande do Norte,
sendo aprovada por todos os membros da banca examinadora abaixo especificada:
Prof. Dr. Gibeon Soares de Aquino Júnior
Presidente
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
Prof. Dr. Everton Ranielly de Sousa Cavalcante
Examinador
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
Prof. Dr. Nélio Alessandro Azevedo Cacho
Examinador
DIMAp – Departamento de Informática e Matemática Aplicada
UFRN – Universidade Federal do Rio Grande do Norte
Profa. Dra. Rossana Maria de Castro Andrade
Examinador
DC – Departamento de Computação
UFC – Universidade Federal do Ceará
Prof. Dr. Vinícius Cardoso Garcia
Examinador
CIn – Centro de Informática
UFPE – Universidade Federal de Pernambuco
Natal-RN, 16 de Dezembro de 2021.
Dedico este trabalho com muito amor, a minha esposa Noelly, minha filha Sofia e meu
filho Artur, que são meu porto seguro, inspiração e motivação.
Agradecimentos
Agradeço a DEUS, pois a ele tudo devo.
Agradeço a minha família, Noelly, Sofia e Artur pela paciência, ajuda, força, apoio e
pelos momentos em que precisei ficar ausente.
Agradeço aos meus pais, Mauro e Emília, e irmãs, Camila e Marcela pelo incentivo e
amor.
Agradeço a Gibeon, por ser muito mais que um professor/orientador, um amigo.
Enfim, agradeço a todos que direta ou indiretamente, contribuíram para a realização
deste trabalho.
Você não pode mudar o vento, mas pode ajustar as velas do barco para chegar onde
quer.
Confúcio
Uma Proposta de Arcabouço para Tolerância a Falhas
Multicamadas em Sistemas IoT
Autor: Mário Andrade Vieira de Melo Neto
Orientador(a): Prof. Dr. Gibeon Soares de Aquino Jr.
Resumo
A tolerância a falhas em sistemas IoT é um desafio a ser superado devido à sua com-
plexidade, dinamicidade e heterogeneidade. Os sistemas IoT são normalmente projetados
e construídos em camadas, em que cada uma delas possui seus próprios requisitos e es-
tratégias de tolerância a falhas. No entanto, erros em uma camada podem propagar-se e
causar efeitos em outras. Portanto, é impraticável considerar uma abordagem de tolerân-
cia a falhas centralizada para todo um sistema. Consequentemente, é vital considerar a
colaboração entre várias camadas de maneira a permitir a troca de informações para lidar
com as falhas. O objetivo deste estudo é propor uma abordagem que auxilie a tolerância a
falhas multicamadas, possibilitando a interconexão entre as camadas de um sistema IoT,
fornecendo formas para prover a troca de informações e colaboração com o objetivo de
melhorar a propriedade da dependabilidade nesses sistemas. Para atingir esse objetivo, é
estabelecida a patologia de falhas que auxilia na compreensão das falhas e seus comporta-
mentos servindo de base para a definição de um arcabouço orientado a eventos chamada
FaTEMa (Fault Tolerance Event Manager). Este arcabouço cria um canal de comunica-
ção dedicado para propagar eventos relacionados a falhas através dos níveis do sistema,
auxiliando na detecção de erros e continuação dos serviços. Além disso, o arcabouço pro-
posto oferece pontos de extensão para suportar protocolos de comunicação heterogêneos
e permitir o desenvolvimento de novos recursos. Os resultados da avaliação empírica de-
monstraram que a introdução do FaTEMa estabeleceu melhorias nos tempos de detecção
e resolução de erros, consequentemente melhorando a disponibilidade do sistema. Além
disso, o uso do FaTEMa proporcionou uma melhoria na confiabilidade através da redução
do número de falhas produzidas.
Palavras-chave: IoT, dependabilidade, tolerância a falhas, detecção de erros, recuperação
de erros, confiabilidade, disponibilidade
A Framework Proposal for Multi-Layer Fault Tolerance
in IoT Systems
Author: Mário Andrade Vieira de Melo Neto
Supervisor: Prof. Dr. Gibeon Soares de Aquino Jr.
Abstract
Fault tolerance in IoT systems is challenging to overcome due to its complexity, dy-
namicity, and heterogeneity. IoT systems are typically designed and constructed in layers.
Every layer has its requirements and fault tolerance strategies. However, errors in one
layer can propagate and cause effects on others. Thus, it is impractical to consider a cen-
tralized fault tolerance approach for an entire system. Consequently, it is vital to consider
multiple layers in order to enable collaboration and information exchange when addres-
sing fault tolerance. The purpose of this study is to propose a multi-layer fault tolerance
approach, granting interconnection among IoT system layers, allowing information ex-
change and collaboration in order to attain the property of dependability. In order to
attain this purpose, the pathology of failures is established, which aids in understanding
the faults and their behavior, serving as a basis for defining an event-oriented framework
called FaTEMa (Fault Tolerance Event Manager). This framework creates a dedicated
communication channel to propagate fault-related events through system levels, assisting
in error detection and service continuation. Additionally, it offers extension points to sup-
port heterogeneous communication protocols and evolve new capabilities. The empirical
evaluation results show that introducing FaTEMa provided improvements to the error de-
tection and error resolution time, consequently improving system availability. In addition,
the use of Fatema provided a reliability improvement and a reduction in the number of
failures produced.
Keywords: IoT; dependability; fault tolerance; error detection; error recovery; reliability;
availability.
Lista de figuras
1 Passos da Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2 Árvore da Dependabilidade definida por Avizienis et al. (AVIZIENIS et al.,
2004) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3 Cadeia de Ameaças adaptada de Avizienis et al. (AVIZIENIS et al., 2004) p. 30
4 Cadeia de Ameaças em Sistemas IoT Associada a Suas Patologias . . . p. 35
5 Procedimento de Snowballing . . . . . . . . . . . . . . . . . . . . . . . p. 38
6 Processo de seleção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
7 Taxonomia de Falhas em Sistemas IoT . . . . . . . . . . . . . . . . . . p. 46
8 Modelo Causa-Efeito e ameaças em um Sistema IoT . . . . . . . . . . . p. 52
9 Modelo de Propagação de Defeitos em Sistemas IoT . . . . . . . . . . . p. 53
10 Ilustração da aplicação do modelo de propagação de falhas em sistemas
IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55
11 Arquitetura do FaTEMa . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
12 Visão de módulos da Arquitetura . . . . . . . . . . . . . . . . . . . . . p. 69
13 Visão Arquitetural de Componentes e Conectores . . . . . . . . . . . . p. 70
14 Processo de Extensibilidade dos Módulos do Arcabouço . . . . . . . . . p. 72
15 Funcionamento do FaTEMa em um sistema IoT baseado em camadas . p. 73
16 Exemplo de um Cenário de um Sistema IoT para Monitoramento e Atu-
ação em um Prédio Inteligente usando o FaTEMa . . . . . . . . . . . . p. 75
17 Fluxo de eventos em um sistema IoT para um prédio inteligentes fazendo
uso do FaTEMa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77
18 Diagrama de Classes Base do Arcabouço . . . . . . . . . . . . . . . . . p. 78
19 Diagrama de Classes genérico para um Componente Principal . . . . . p. 79
20 Diagrama de Classes genérico para um Componente Extensor . . . . . p. 80
21 Arquitetura do sistema para a avaliação experimental. (a) Arquitetura
sem a presença do FaTEMa. (b) Arquitetura com a presença do FaTEMa. p. 85
22 Comparação das respostas às requisições ao longo do tempo para cada ce-
nário experimental. (a) S#1—Respostas ao Longo do Tempo. (b) S#2—
Respostas ao Longo do Tempo. . . . . . . . . . . . . . . . . . . . . . . p. 93
23 Comparação do Overhead de CPU ao Longo do Tempo em Cada Cenário
Experimental. (a) S#1—Overhead de CPU ao Longo do Tempo. (b)
S#2—Overhead de CPU ao Longo do Tempo. . . . . . . . . . . . . . . p. 95
24 Comparação do Overhead de Largura de Banda ao Longo do Tempo em
Cada Cenário experimental. (a) S#1—Overhead de Largura de Banda
ao longo do tempo. (b) S#2—Overhead de Largura de Banda ao longo
do tempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 96
Lista de tabelas
1 Principais Bases de conhecimento indexadas pelo Scopus . . . . . . . . p. 36
2 Estudos selecionados e lidos cuidadosamente . . . . . . . . . . . . . . . p. 40
3 Classificação dos trabalhos que relatam a origem de falhas em cada uma
das camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
4 A classificação dos tipos de falhas em sistemas IoT endereçadas por cada
trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
5 Métricas utilizadas para avaliar o benefício do uso de FaTEMa . . . . . p. 83
6 Cenários experimentais e os mecanismos de tolerância a falhas utilizados. p. 86
7 Medições do tempo para a detecção dos erros. . . . . . . . . . . . . . . p. 88
8 Medições do tempo de resolução dos erros. . . . . . . . . . . . . . . . . p. 89
9 Valores das métricas relativas a disponibilidade do sistema. . . . . . . . p. 90
10 Métricas de Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
11 Desafios endereçados pelos trabalhos relacionados. (D1 – Heterogenei-
dade, D2 – Adaptabilidade e Evolução, D3 – Mecanismo de Decisão Dis-
tribuída e D4 – Redundância de informação) . . . . . . . . . . . . . . . p. 99
Lista de abreviaturas e siglas
IoT – Internet das Coisas
WSN - Redes de Sensores Sensores Sem Fio
RFID – Radio-Frequency IDentification
SFI – Software Fault Injection
QP – Questão de Pesquisa
ITU-T – International Telecommunications Union - Telecommunication Standardization
Sector
CEP – Processador de Eventos Complexos
SAN – Rede de área de armazenamento
FaTEMa – Fault Tolerance Event Manager
UML – Linguagem de Modelagem Unificada
CoAP – Constrained Application Protocol
MQTT – Message Queuing Telemetry Transport
FCM – Mapas Cognitivos Fuzzy
PHD – Dispositivos Pessoais de Saúde
RFID – Identificação por radiofrequência
NFC – Comunicação por campo de proximidade
LFT – Tolerância a falhas local
Sumário
1 Introdução p. 17
1.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 17
1.2 Problematização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
1.4 Questões de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
1.5 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
1.6 Sumário de Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
1.7 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . p. 24
2 Referencial Teórico p. 25
2.1 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.2 Tolerância a Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
2.2.1 Dependabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.2.1.1 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
2.2.1.2 Ameaças . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
2.2.1.3 Meios . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
2.2.2 Etapas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
2.2.3 Injeção de Falhas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
2.3 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
3 A Patologia de Falhas em Sistemas IoT p. 34
3.1 Revisão do Estado da Arte . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.1.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
3.1.1.1 Objetivo e Questões de Pesquisa . . . . . . . . . . . . p. 36
3.1.1.2 Processo de Busca e Seleção . . . . . . . . . . . . . . . p. 36
3.1.2 Critérios de inclusão e exclusão . . . . . . . . . . . . . . . . . . p. 37
3.1.3 Definição do conjunto inicial e Processo de iteração . . . . . . . p. 37
3.1.4 Coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.1.5 Validade do processo . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.1.6 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.2 Respostas às questões de pesquisa . . . . . . . . . . . . . . . . . . . . . p. 40
3.2.1 QP1: Quais são as origens de falhas em sistemas IoT? . . . . . p. 40
3.2.1.1 Camada de Percepção . . . . . . . . . . . . . . . . . . p. 41
3.2.1.2 Camada de Comunicação . . . . . . . . . . . . . . . . p. 43
3.2.1.3 Camada de Serviço . . . . . . . . . . . . . . . . . . . . p. 44
3.2.1.4 Camada de Aplicação . . . . . . . . . . . . . . . . . . p. 45
3.2.2 QP2: Como são caracterizadas as falhas em sistemas IoT? . . . p. 45
3.2.2.1 Duração . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
3.2.2.2 Localização . . . . . . . . . . . . . . . . . . . . . . . . p. 47
3.2.2.3 Semântica . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
3.2.2.4 Comportamento . . . . . . . . . . . . . . . . . . . . . p. 49
3.2.2.5 Dimensão . . . . . . . . . . . . . . . . . . . . . . . . . p. 50
3.3 Modelo de Propagação de Defeitos em Sistemas IoT . . . . . . . . . . p. 50
3.3.1 Exemplo de Aplicabilidade:Cenário de casas inteligentes . . . . p. 54
3.4 conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
4 Arcabouço para Tolerância a Falhas Multicamadas p. 57
4.1 Principais Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
4.1.1 D1 – Heterogeneidade . . . . . . . . . . . . . . . . . . . . . . . p. 58
4.1.2 D2 – Adaptabilidade e Evolução . . . . . . . . . . . . . . . . . . p. 58
4.1.3 D3 – Mecanismo de Decisão Distribuída . . . . . . . . . . . . . p. 59
4.1.4 D4 – Redundância de informação . . . . . . . . . . . . . . . . . p. 59
4.2 Decisões de Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
4.2.1 Canal de comunicação multicamadas . . . . . . . . . . . . . . . p. 60
4.2.2 Comunicação interoperável . . . . . . . . . . . . . . . . . . . . . p. 61
4.2.3 Arquitetura Orientada a Eventos . . . . . . . . . . . . . . . . . p. 61
4.2.4 Detecção e recuperação de erros colaborativa . . . . . . . . . . . p. 62
4.3 Arcabouço FaTEMa . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
4.3.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65
4.3.1.1 Event Input Channel . . . . . . . . . . . . . . . . . . . p. 66
4.3.1.2 Event Processing . . . . . . . . . . . . . . . . . . . . . p. 67
4.3.1.3 Event Storage . . . . . . . . . . . . . . . . . . . . . . . p. 67
4.3.1.4 Event Output Channel . . . . . . . . . . . . . . . . . . p. 67
4.3.1.5 Event Bus . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
4.3.2 Descrição da Arquitetura . . . . . . . . . . . . . . . . . . . . . . p. 68
4.3.2.1 Visão de Módulos . . . . . . . . . . . . . . . . . . . . . p. 68
4.3.2.2 Visão de Componentes e Conectores . . . . . . . . . . p. 69
4.3.3 Processo de Extensibilidade . . . . . . . . . . . . . . . . . . . . p. 71
4.3.4 Funcionamento do FaTEMa . . . . . . . . . . . . . . . . . . . . p. 72
4.3.5 Exemplo de uso do FaTEMa . . . . . . . . . . . . . . . . . . . . p. 74
4.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76
4.4.1 Componentes Principais . . . . . . . . . . . . . . . . . . . . . . p. 76
4.4.2 Componentes Extensores . . . . . . . . . . . . . . . . . . . . . . p. 80
4.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
5 Avaliação Experimental do FaTEMa p. 82
5.1 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 82
5.1.1 Design do Experimento . . . . . . . . . . . . . . . . . . . . . . p. 83
5.1.2 Execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 87
5.1.3 Resultados e análises . . . . . . . . . . . . . . . . . . . . . . . . p. 87
5.2 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 91
5.2.1 Ameaças à Validade . . . . . . . . . . . . . . . . . . . . . . . . p. 97
5.3 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 98
6 Trabalhos Relacionados p. 99
6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 105
7 Considerações finais p. 107
7.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 107
7.2 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . p. 109
7.3 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 110
7.4 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 111
Referências p. 112
Apêndice A -- Coleta e análise de dados do Capítulo 3 p. 123
Apêndice B -- Implementação do FaTEMa e dados experimento apre-
sentado no Capítulo 5 p. 124
17
1 Introdução
Este capítulo tem a finalidade de situar o tema abordado no trabalho. Assim, descreve-
se a contextualização do mesmo na Seção 1.1. Na Seção 1.2 são descritos o problema e
a hipótese tratados neste estudo. Por sua vez, a Seção 1.3 descreve o objetivo geral da
pesquisa e enumera os objetivos específicos dela. Em seguida, na Seção 1.5 é explicada a
metodologia aplicada ao trabalho. Por conseguinte, a Seção 1.6 resume as contribuições
deste trabalho. Por fim, a Seção 1.7 apresenta a forma como o mesmo está organizado.
1.1 Contextualização
Internet das Coisas (IoT, do inglês Internet of Things) tem como objetivo projetar
a visão de uma rede global de objetos físicos conectados a qualquer tempo, em qual-
quer lugar e por qualquer um (KUBLER; FRÄMLING; BUDA, 2015; KOSMATOS; TSELIKAS;
BOUCOUVALAS, 2011; MADAKAM; RAMASWAMY; TRIPATHI, 2015). IoT denota um fenô-
meno em que um grande número de dispositivos embutidos, em diversos locais, aplicam
padrões de comunicação disponibilizados pelos protocolos da internet. Esses dispositivos
ou, como são chamados nesse contexto, “coisas”, geralmente não são diretamente opera-
dos por pessoas, mas estão presentes, na forma de componentes, em casas inteligentes,
prédios, veículos, sistemas de saúde ou espalhados pelos ambientes (TSCHOFENIG et al.,
2015). Assim, a ideia básica deste conceito é a presença pervasiva através do uso de uma
variedade de coisas ou objetos (dispositivos), através de esquemas de identificação única,
permitindo uma interação uns com os outros e com seus vizinhos para atingir um objetivo
em comum (ATZORI; IERA; MORABITO, 2010).
O domínio IoT tem emergido rapidamente em um ecossistema necessário em que
dados, processos, pessoas, coisas e a internet estão associados. Estima-se que em 2030,
500 bilhões de dispositivos IoT estarão instalados e conectados, gerando mais de 180 ZB
de informações em diversas áreas (IHS, 2019; CISCO, 2018; GARCIA-MORCHON; KUMAR;
SETHI, 2019). As previsões indicam que o paradigma IoT continua se expandindo e até
18
2023, 50% das conexões da internet se darão a partir de dispositivos IoT (CISCO, 2020;
AMAN et al., 2020). Os sistemas baseados em IoT, estão modificando o estilo de vida das
pessoas e em um futuro próximo, ela estará, cada vez mais, ubiquamente embutida em
diversos aspectos do cotidiano (Miraz et al., 2015).
O potencial da mudança na qualidade de vida promovida pelos sistemas IoT é in-
questionável. Assim, IoT é um paradigma que causou mudanças profundas na forma de
relacionar pessoas e tecnologia, modificando sistemas e sociedades (WEYRICH; EBERT,
2015). As aplicações IoT estão fortemente conectadas ao mundo físico através de diversos
tipos de dispositivos (sensores, atuadores, tags, gateways, entre outros), produzindo um
certo grau de desconfiança e incerteza introduzido pelas “coisas” conectadas a essas apli-
cações (DAR; TAHERKORDI; ELIASSEN, 2016). Esse crescimento no uso de soluções IoT,
requerem, em muitos casos, uma quantidade enorme de dispositivos implantados em diver-
sos domínios como saúde, indústria, transportes, agricultura, energia e casas inteligentes
(AMAN et al., 2020; Asghar; Negi; Mohammadzadeh, 2015; LEE; LEE, 2015). Essa escala massiva
na implantação de dispositivos IoT, altamente distribuídos, tornam a propriedade da de-
pendabilidade uma preocupação devido a causas externas (ambientes altamente inóspitos)
ou causas internas (falhas de energia, componentes de baixa qualidade). Isso acaba resul-
tando em uma baixa qualidade da experiência do usuário ou de informações questionáveis
(DISTEFANO, 2013; SILVA et al., 2013).
Assim, embora promissora estabelecer a visão de IoT necessita endereçar diversos de-
safios relacionados aos atributos de disponibilidade, confiabilidade, desempenho, escalabi-
lidade, interoperabilidade e segurança (WHITMORE; AGARWAL; XU, 2015; AL-FUQAHA et
al., 2015; PASTÓRIO; RODRIGUES; CAMARGO, 2020). Entre todos esses desafios destacam-
se a confiabilidade e disponibilidade que estão diretamente ligadas a um sistema prover
um serviço de maneira correta. Assim, caso o sistema falhe, isso pode colocar a vida de
pessoas em risco, resultar em perdas financeiras ou causar danos aos ambientes (SILVA et
al., 2013; AL-FUQAHA et al., 2015). Associado a isso, os sistemas IoT estão expostos a cená-
rios de incertezase de alta complexidade necessitando de avanços no desenvolvimento de
mecanismos que possibilitem endereçar adequadamente os atributos disponibilidade e con-
fiabilidade que são atributos que se referem a confiança no funcionamento do sistema ou
dependabilidade (CICCOZZI et al., 2017; HAMMOUDI; ALIOUAT; HAROUS, 2018; AVIZIENIS
et al., 2004). Além disso, o paradigma IoT também é caracterizado por sua heterogeneidade
e multidisciplinaridade que integra diversas áreas de pesquisa como Sistemas Distribuídos,
Redes de Sensores Sem Fio (WSN, do inglês Wireless Sensor Network) , Computação em
Nuvem, Computação Pervasiva e Engenharia de Software (GUBBI et al., 2013). Portanto,
19
heterogeneidade e interoperabilidade emergem como barreiras a serem superadas pelos
sistemas IoT no objetivo de endereçar a propriedade da dependabilidade.
1.2 Problematização
Toda essa evolução tecnológica alavancada pela IoT vem com um preço: falhas podem
causar acidentes fatais, perda de grandes quantidades de dinheiro, entre outras situações,
podendo gerar diminuição da confiança aos olhos da opinião pública, incluindo na dos
próprios usuários (RATASICH et al., 2019). Por esta razão, a dependabilidade em aplica-
ções e infraestruturas IoT tem se tornado crucial em vários contextos, particularmente
em domínios críticos como saúde, sistemas em tempo real, militar, entre outros (ŞTEFAN;
OTTO; ALEXANDRINA, 2017; CICCOZZI et al., 2017). Para garantir essa propriedade nos
sistemas, é necessário endereçar, principalmente, os atributos de confiabilidade, disponi-
bilidade e manutenabilidade. Tratando-se de serviços, a disponibilidade deve possibilitar
que o serviço fornecido por um sistema IoT (ou parte dele) não seja afetado por falhas
em sua própria estrutura e/ou em elementos subjacentes, como componentes, subsistemas
ou sistemas inteiros (KNIGHT, 2012; LAPRIE, 2008). Quanto à confiabilidade, possibilita
o contínuo fornecimento do serviço corretamente durante um determinado período de
tempo (KNIGHT, 2012; LAPRIE, 2008). A manutenabilidade está relacionada à habilidade
de permitir a modificação e correção de serviços (AVIZIENIS; LAPRIE; RANDELL, 2001).
No contexto IoT, com sua larga escala, heterogeneidade, alta distribuição interde-
pendência, às falhas são, praticamente, inevitáveis, ou seja, os projetistas desses sistemas
devem partir dessa premissa para a construção das soluções (ASIM; MOKHTAR; MERABTI,
2010; SOUZA; VOGT; BEIGL, 2007; ALHO; MATTILA, 2015). Algumas pesquisas reportam
que a implantação de sistemas IoT em larga escala para aplicações reais não é uma ativi-
dade trivial e pode levar a incontáveis falhas (SANCHEZ et al., 2014; SHIH et al., 2016; SU et
al., 2014; ZHOU et al., 2015; BARRENETXEA et al., 2008; TATESON et al., 2005; MARTINEZ et
al., 2005; WERNER-ALLEN et al., 2006). Uma possível solução para reduzir a ocorrência de
falhas nesses sistemas é proporcionar melhorias na qualidade dos hardwares e softwares
utilizados. No entanto, esta estratégia sozinha não garante, totalmente, a não ocorrência
de falhas, e irá, em contrapartida, aumentar significativamente o custo desses sistemas.
A tolerância a falhas desempenha um papel essencial na manutenção do funciona-
mento regular de um sistema, mesmo na presença de falhas (HUANGSHUI; GUIHE, 2011).
No entanto, a aplicação de técnicas de tolerância a falhas em sistemas IoT é uma tarefa
20
complexa, apresentando inúmeros desafios. Primeiramente, esses sistemas, normalmente,
são estruturados com várias “coisas” heterogêneas para oferecer o suporte a aplicações
com múltiplos propósitos (SHIH et al., 2016; HEIDEMANN; GOVINDAN, 2005; KOUSHAN-
FAR; POTKONJAK; SANGIOVANNI-VINCENTELL, 2002). Além disso, frequentemente, estes
sistemas possuem requisitos particulares e específicos em relação a esquemas e restrições
de tolerância a falhas, incluindo características específicas de falhas (LI; JI; LI, 2013; KA-
RACA; SOKULLU, 2012). Além desses, os sistemas IoT são inerentemente complexos em
virtude da sua aplicação em grande escala, heterogeneidade e interação com mundo fí-
sico (OJIE; PEREIRA, 2017; RATASICH et al., 2019; OJIE, 2020). Além desses, o paradigma
IoT está em constante evolução, o que requer suporte a novas tecnologias, protocolos e
funcionalidades (DENKER et al., 2012; LITTLEWOOD; STRIGINI, 2000; ZHOU et al., 2019).
As implementações atuais de mecanismos de tolerância a falhas em IoT estão focadas
em problemas específicos: (1) eles são projetados para arquiteturas e aplicações específicas
(GIA et al., 2015; WOO; LEE; PARK, 2018); (2) eles não escalam além de pequenas soluções
descentralizadas (ARDEKANI et al., 2017; MARRA et al., 2017) e centralizadas (GIA et al.,
2015); e (3) eles fornecem soluções para falhas específicas, como falhas de link (KARTHI-
KEYA; VIJETH; MURTHY, 2016) e falhas de dispositivo (KHAN; HAMEED, 2018), e muitas
vezes focam em apenas uma das camadas de abstração do sistema, sem considerar uma
visão global (XING, 2020; GENSH; ROMANOVSKY; YAKOVLEV, 2015). Além disso, normal-
mente, camadas e dispositivos de sistemas, atuam de maneira cooperativa e coordenada
disseminando informações de vários formatos e para diferentes aplicações (AKPAKWU et
al., 2017). Essa dependência de funcionamento, em muitos casos, produz a distribuição
dos dados e informações gerados em uma camada para outras camadas com o propósito
de realizar uma posterior transmissão ou processamento e tratamento dessas informações
(SINGH, 2018; GUIMARAES et al., 2019). Portanto, os erros em uma camada podem se pro-
pagar, causando falhas em camadas subjacentes, fazendo com que o sistema seja suscetível
a falhar como um todo. Além disso, uma decisão aplicada ao se tolerar uma determinada
falha em uma camada pode impactar o funcionamento de outras camadas ou serviços.
Assim, devido aos desafios atuais em IoT, é difícil adotar um mecanismo de tolerância a
falhas unificado e eficaz para contemplar todas as camadas do sistema (LI; JI; LI, 2013;
ZHOU et al., 2015; SAHOO; VEERAVALLI; KUMAR, 2016). Além disso, é improvável, garantir
que todas as camadas irão possuir mecanismos que consigam lidar com todos os tipos de
erros e falhas. Portanto, é vital proporcionar o compartilhamento de informações relativas
às falhas entre de modo a viabilizar a adoção de estratégias de tolerância a falhas que
possam tomar decisões baseadas em uma visão holística do sistema. E, portanto, auxiliar
21
no processo de melhoria do atributo de confiabilidade nos sistemas.
Nesse contexto, emerge a necessidade de definir um mecanismo que possibilite a co-
laboração entre as estratégias de tolerância a falhas presentes nas camadas dos sistemas
IoT proporcionando o compartilhamento de informações relevantes relacionadas a falhas.
Assim, será possível realizar a tomada de decisão descentralizada a respeito da tolerância
a falhas considerando o contexto e especificidades das camadas e do restante do sistema.
Consequentemente, cada camada poderá realizar o processo de tolerância a falhas aten-
dendo seus requisitos e restrições atuando de maneira interoperável objetivando evitar a
propagação de erros, melhorando a confiabilidade e disponibilidade do sistema (GENSH,
2018; DEHON; CARTER; QUINN, 2011). Por conseguinte, este trabalho endereça este pro-
blema através de uma abordagem que auxilia a realização da tolerância a falhas multica-
madas facilitando o processo de comunicação e interoperabilidade entre as estratégias de
tolerância a falhas.
No entanto, a tolerância a falhas é composta de várias etapas como detecção, confi-
namento e avaliação, recuperação, e tratamento e continuação de serviço. As etapas de
confinamento e avaliação necessitam, além de conhecer o estado do sistema, atuar para
modificar ou isolá-lo. Portanto, dependem exclusivamente do conhecimento a respeito do
estado interno ao qual se está tolerando, bem como possuir disponibilidade de atuação.
No entanto, as etapas de detecção, e tratamento e continuaçãode serviço, não dependem
inteiramente da necessidade de estar próximo ou poder atuar sobre o estado do serviço
ou aplicação para identificar um estado errôneo ou recuperado. Essa informação pode ser
obtida através do compartilhamento de informações dos estados dos serviços e aplicações.
Assim, o mecanismo proposto neste trabalho foca em apoiar a disseminação da informação
do estado das aplicações e serviços, especificamente para auxiliar na detecção dos errros,
bem como no tratamento e continuação de serviços.
1.3 Objetivos
Este trabalho tem como objetivo geral compreender a ocorrência de falhas em sistemas
IoT, estabelecendo um arcabouço multicamadas para suporte à tolerância delas, especi-
almente nas etapas de detecção de erros e continuação de serviço. Desse modo, baseado
neste objetivo enumera-se os seguintes objetivos específicos:
• Compreender os aspectos relacionados à falhas em sistemas IoT, tais como, a origem,
tipos e formas de propagação.
22
• Projetar a arquitetura do arcabouço superando os desafios relatados e possibilitando
o compartilhamento de informações entre camadas e estratégias de tolerância a
falhas.
• Implementar a arquitetura do arcabouço provendo um canal de comunicação dedi-
cado e transversal que estabeleça o compartilhamento de informações relativas às
falhas e suas implicações entre as camadas.
• Estabelecer um formato de comunicação flexível e que permita adaptações para
suportar a heterogeneidade e evolução das tecnologias e protocolos.
1.4 Questões de Pesquisa
Com base nos objetivos definidos, este trabalho é guiado por duas questões de pes-
quisa:
Questão 01 Quais as características e o comportamento das falhas em sistemas IoT?
O propósito dessa questão é compreender como ocorre o estabelecimento da cadeia de
ameaças, para tal, foi necessário identificar a origem da ocorrência de falhas, quais os tipos
de erros e como ocorre a propagação dos defeitos. Esse conjunto de etapas se relaciona
através do estabelecimento de uma relação causal e da interdependência materializando a
patologia das falhas. Como no domínio IoT estão envolvidas diversas tecnologias, aplica-
ções e interações, o uso de estratégias que suportem a heterogeneidade e adaptabilidade
de mecanismos para realizar gerenciamento de falhas tornam-se promissoras. Além disso,
em virtude, dessas características e da interação dos componentes dos sistemas entre si,
com outros sistemas e com o ambiente, emerge-se a necessidade de possibilitar a inter-
comunicação entre os diferentes mecanismos objetivando um tratamento distribuído das
falhas.
Questão 02 A adoção da abordagem para auxiliar a tolerância a falhas multicamadas
em sistemas IoT, especialmente nas etapas de detecção de erros e continuação de serviços,
introduz benefícios na dependabilidade, particularmente os atributos de confiabilidade e
disponibilidade?
Esta questão tem como objetivo avaliar o benefício em termos de confiabilidade e
disponibilidade, alcançados em virtude da utilização da abordagem para auxílio a tole-
23
rância a falhas multicamada. Para tal, foi estabelecido uma avaliação experimental que
realiza a comparação da utilização do arcabouço combinado com técnicas de tolerância
a falhas presentes na literatura. Na avaliação, coletou-se o tempo necessário para detec-
tar e recuperar-se de um erro, o tempo em que o sistema esteve disponível, bem como a
quantidade de erros e defeitos produzidos.
1.5 Metodologia
Com o intuito de alcançar o objetivo estabelecido nesta pesquisa, foi seguida a meto-
dologia apresentada na Figura 1, a qual é composta por cinco passos: revisão da literatura,
projeto da arquitetura, implementação do arcabouço, avaliação e trabalhos relacionados.
Figura 1: Passos da Metodologia
Fonte: Autor
No passo de revisão da literatura almejou-se entender o estado atual da área de IoT
em relação às falhas e suas implicações. Para isso, foi realizada uma revisão do estado
da arte identificando e classificando a origem e tipos de falhas comumente presentes em
sistemas IoT. Além disso, com base nos resultados da revisão foi possível estabelecer a
patologia das falhas em sistemas IoT. Essa patologia, organiza o conhecimento a respeito
das falhas em sistemas IoT indicando sua origem, tipos e formas de propagação.
Em seguida, projetou-se o arcabouço FaTEMa, acrônimo de Fault Tolerance Event
Manager, para atuar como intermediador da comunicação entre camadas facilitando o
compartilhamento de informações relacionadas à falhas em sistemas IoT. Para tal, fo-
ram listados os desafios a serem superados pelas estratégias de tolerância a falhas em
sistemas IoT, as decisões de projeto que superam esses desafios, bem como a descrição e
documentação da arquitetura projetada. Posteriormente, realizou-se a implementação da
arquitetura do FaTEMa atendendo as decisões de projeto.
Por conseguinte, foi realizada uma avaliação da utilização do arcabouço através da
realização de um experimento computacional que tem por objetivo avaliar os benefícios da
sua utilização nos atributos de disponibilidade e confiabilidade. Para tal, foi desenvolvido
24
um sistema de casas inteligentes em que se avaliou as consequências trazidas pelo uso do
FaTEMa. Por fim, foram discutidos os resultados obtidos.
Finalmente, realizou-se o levantamento dos trabalhos relacionados ao desenvolvido
nesta tese. Nesse passo, esses estudos foram descritos e comparados ao trabalho desenvol-
vido nesta pesquisa.
1.6 Sumário de Contribuições
A principal contribuição científica deste trabalho é a proposta de uma abordagem para
tolerância a falhas multicamadas em sistemas IoT através de um arcabouço que auxilia na
intercomunicação entre as camadas do sistema estabelecendo uma integração entre elas
com o objetivo de facilitar o compartilhamento de informações relacionadas às falhas.
Essa abordagem teve seus resultados preliminares relatados e publicados em MELO;
AQUINO (2021b). Além disso, uma versão completa e estendida da abordagem proposta,
bem como o relato do experimento foi publicado em MELO; AQUINO (2021a).
Uma contribuição secundária desta tese é o estabelecimento da patologia das falhas
em sistemas IoT, a qual classifica a origem e tipos de falhas, bem como estabelece um
modelo de propagação de defeitos nesses sistemas tendo sido publicada em MELO; AQUINO
(2021c).
1.7 Organização do trabalho
O restante deste trabalho é organizado da seguinte maneira. No Capítulo 2 apresenta a
fundamentação teórica contendo os conceitos e terminologias necessários ao entendimento
deste estudo. O Capítulo 3 apresenta a revisão da literatura realizada neste trabalho. Essa
revisão foi feita com o intuito de posicionar o pesquisador em relação a patologia das falhas
em sistemas IoT. O Capítulo 4 descreve o arcabouço proposto, bem como a abordagem
de tolerância a falhas multicamadas. Para avaliar o arcabouço proposto, é realizada uma
avaliação experimental envolvendo um sistema IoT de casas inteligentes no Capítulo 5. O
Capítulo 6 apresenta os trabalhos relacionados a esta tese. Por fim, o Capítulo 7 expõe
as considerações finais deste trabalho, destacando as principais conclusões, contribuições,
limitações e trabalhos futuros.
25
2 Referencial Teórico
Neste capítulo são apresentados os conceitos essenciais ao entendimento desta tese.
Na Seção 2.1, é apresentada uma visão geral do domínio IoT, bem como sua definição. A
Seção 2.2 apresenta conceitos e definições relacionados à área de tolerância a falhas. Por
fim, a Seção 2.3 aborda as considerações finais deste capítulo.
2.1 Internet das Coisas
A Internet das Coisas (do inglês Internet of Things - IoT ) é um termo que foi citado
pela primeira vez em 1999 (ASHTON et al., 2009). Inicialmente, a aplicabilidade de IoT
era compreender o ambiente e a rotina ao redor das pessoas, a partir da coleta de dados
provenientes de Radio-Frequency IDentification (RFID) tags utilizando a internet como
meio de comunicação (ASHTON et al., 2009). Hoje, quaseduas décadas depois, sua aplica-
ção tem se espalhado cada vez mais e para uma grande variedade de domínios. Assim, IoT
representa o presente e o futuro da computação e da comunicação, integrando diversas
inovações técnicas em áreas vitais, desde redes de comunicação até a nanotecnologia (WU
et al., 2010). Este paradigma tem como premissa atuar como uma tecnologia que permite
a interação ubíqua e pervasiva através de objetos e coisas, como RFID tags, sensores,
atuadores, dispositivos móveis com pessoas e sistemas (ATZORI; IERA; MORABITO, 2010).
Assim, partindo da junção das palavras “Internet” e “Coisas” é introduzida a visão que faz
uso de um meio comunicação (Normalmente, sem fio) através dos quais os objetos intera-
gem entre si formando uma rede cooperativa de dispositivos (ATZORI; IERA; MORABITO,
2010).
Esta abordagem tecnológica permite a criação de ambientes digitais, virtuais e em
tempo real possibilitando a interconexão entre as “coisas” a qualquer tempo e em qual-
quer lugar, com qualquer coisa ou alguém (TAN; WANG, 2010). A intercomunicação e
interação entre dispositivos e ambientes cria uma série de oportunidades e contribuições
valorosas para a vida das pessoas e organizações (ATZORI; IERA; MORABITO, 2010). A
26
aplicabilidade do paradigma IoT pode se dar nos mais diversos domínios como(ATZORI;
IERA; MORABITO, 2010; ANDRADE et al., 2017):
• Transporte: aplicações que auxiliam no controle do tráfego, sugerem as melhores
rotas para os veículos, monitoramento de frotas.
• Saúde: Fazer uso de equipamentos de monitoramento (relógios inteligentes, câmeras,
sensores de presença, monitores cardíacos e outros) de idosos ou pessoas enfermas
em casas ou hospitais enviando as informações para os médicos, possibilitando o
controle da informação e tratamento.
• Pessoal: aplicações voltadas à melhoria na qualidade de vida das pessoas através do
monitoramento de casas inteligentes, controle de equipamentos, manter e construir
relacionamentos.
• Agricultura: controlar o crescimento de plantações, monitorando a umidade, tem-
peratura, insolação, clima e etc.
Estes sistemas podem ser vistos como uma composição de “coisas” altamente distri-
buída e dinâmica em que cada um possui uma quantidade substancial de objetos pro-
duzindo e consumindo informação (KRIEBEL et al., 2018; TAVČAR; HORVATH, 2018). A
habilidade de interagir com a realidade física é atingida pela presença de dispositivos
capazes de sentir fenômenos físicos e os traduzir para informações digitais a serem pro-
cessadas, assim como, produzir efeitos sobre o ambiente em que se está inserido, gerando
novas atuações.
Os sistemas IoT são, normalmente, distribuídos entre diferentes domínios de apli-
cação e localização geográfica, o que cria uma série de dependências entre dispositivos,
domínios, plataformas e serviços (UVIASE; KOTONYA, 2018). Além disso, as característi-
cas pervasivas, heterogêneas e complexas presentes em tais sistemas, levarão a mudanças
e evolução ao longo do tempo. Essas características emergem preocupações relativas à
dependabilidade pois falhas em alguns domínios não são aceitáveis pois podem colocar a
vida de pessoas em risco (ZHOU et al., 2015). Assim, para prover a dependabilidade nesses
sistemas, é necessário garantir dois importantes fatores: identificar a origem das falhas e
possuir mecanismos para tolerar e mitigar essas ocorrências (RATASICH et al., 2019).
27
2.2 Tolerância a Falhas
Para obter a dependabilidade em sistemas computacionais é necessário considerar
que a falta de confiança em um sistema é consequência de uma sequência de falhas. Além
disso, esses sistemas são por natureza complexos, contendo normalmente subsistemas e
componentes que interagem através de relações complexas. Consequentemente, falhas são
inevitáveis, e elas podem acontecer de várias formas (LEE; ANDERSON, 1990). Então,
a tolerância a falhas é o meio utilizado para atingir a dependabilidade considerando a
entrega do serviço correto e evitando os defeitos mesmo na presença de falhas (AVIZIENIS
et al., 2004; LAPRIE, 1992). O seu objetivo é mitigar os efeitos provocados pela existência
de falhas após o desenvolvimento dos sistemas empregando técnicas e abordagens para
mascarar e manter o sistema em execução mesmo na presença de falhas (PULLUM, 2001).
2.2.1 Dependabilidade
O conceito de dependabilidade é definido por Avizienis et al. (AVIZIENIS et al., 2004;
AVIZIENIS; LAPRIE, 1986; AVIZIENIS; LAPRIE; RANDELL, 2001) como “a capacidade de
fornecer serviços que podem ser, justificadamente, confiáveis” e alternativamente como
“a capacidade de evitar falhas em serviços que são mais frequentes e mais graves do
que o aceitável”. William Carter (CARTER, 1982) em seu trabalho define dependabilidade
como “a confiabilidade de um sistema de computador, de modo que a confiança possa
ser justificadamente depositada no serviço que ele fornece”. B. Parhami (PARHAMI, 1988)
define a dependabilidade como “a confiança garantida de que o sistema executará as ações
especificadas ou fornecerá resultados especificados de maneira confiável em tempo hábil”.
Dessa forma, é possível perceber que o atributo da dependabilidade está diretamente
ligado ao conceito de confiança, em que um sistema entrega um serviço a um usuário
(humano ou outro sistema) e esse deve ter a sua confiança garantida. No entanto, essa
definição básica é simplista, dada a vasta quantidade de sistemas de computação e co-
municação existentes. Com o objetivo de expandir esse conceito, focando a sua definição
em partes relevantes nos sistemas baseados em computador, Avizienis et al. (AVIZIENIS et
al., 2004) define uma árvore de dependabilidade (Figura 2) contendo os principais concei-
tos que envolvem essa propriedade considerando seus atributos, ameaças e os meios para
atingi-la.
Apesar de existirem outros modelos e conceitos relacionados a dependabilidade e
confiabilidade, que definem atributos e meios, como o modelo de qualidade de Software
28
Figura 2: Árvore da Dependabilidade definida por Avizienis et al. (AVIZIENIS et al., 2004)
Fonte: O Autor
ISO/IEC 25010:2011 – SQuaRE (ISO/IEC, 2011), neste trabalho serão utilizadas as de-
finições conceituadas e estabelecidas na área de tolerância a falhas (AVIZIENIS, 1967;
AVIZIENIS et al., 2004; LAPRIE et al., 1990; LEE; ANDERSON, 1990).
2.2.1.1 Atributos
Dependabilidade é um conceito global integrado que incorpora um conjunto de atribu-
tos que são utilizados para medir e habilitar o entendimento a partir de várias perspectivas.
Assim, os atributos que compõem a dependabilidade são (AVIZIENIS et al., 2004; LAPRIE
et al., 1990):
• Disponibilidade: Prover corretamente o serviço. É o grau com o qual um sistema
ou componente está operacional e acessível quando tem seu uso solicitado (ISO/I-
EC/IEEE, 2017).
• Confiabilidade: É a habilidade do sistema ou componente em disponibilizar o
serviço de acordo com as condições estabelecidas durante um determinado período
de tempo (ISO/IEC/IEEE, 2017).
• Segurança (safety): Ausência de consequências catastróficas para os usuários e o
ambiente.
29
• Integridade: Ausência de alterações impróprias no sistema.
• Manutenabilidade: Capacidade de sofrer modificações e reparos.
• Confidencialidade: Ausência de divulgação não autorizada das informações do
sistema.
A aplicabilidade e importância desses atributos irá variar dependendo das necessi-
dades das aplicações, assim diferentes ênfases podem ser aplicadas a diferentes facetas
da dependabilidade. Apesar de conter vários atributos, a dependabilidade é geralmente
quantificada a termo de disponibilidade e confiabilidade. Esses dois atributos são as chaves
para avaliar a melhoria ao se fazer uso de meios para lidar com as falhas, ou seja, quanto
mais um sistema for capaz de lidar com as falhas, mais disponível e confiável é esperado
que ele seja (NELSON, 1990; JHAWAR; PIURI; SANTAMBROGIO, 2012).
2.2.1.2 Ameaças
Qualquer definição de dependabilidade deve envolver adistinção entre os compor-
tamentos aceitáveis ou não por um sistema. Dessa forma, quando o funcionamento do
sistema desvia dos comportamentos aceitáveis definidos em sua especificação, ocorre um
defeito (failure) (AVIZIENIS et al., 2004). Para um sistema, definida a sua especificação e
comportamentos esperados, a análise a respeito da origem das ameaças deve-se levar em
consideração apenas a operação interna do sistema. Assim, dois conceitos discutem essen-
cialmente a origem das falhas e estes são conhecidos por transições errôneas (erroneous
transition) e estado errôneo (erroneous state). Uma transição errônea é a transição do
estado interno do sistema para um estado errôneo, o que leva a um subsequente defeito
(LEE; ANDERSON, 1990).
Um erro (error) é uma parte do estado errôneo que constitui a diferença para um
estado válido. Assim, um erro é causa de um provável defeito quando atinge o estado
externo do sistema. No entanto, nem todos os erros conseguirão atingir esse estado. Um
erro é detectado se sua presença é indicada por uma mensagem de erro ou sinal, esse
processo é definido como ativação do erro. Quando o erro não é detectado é chamado de
erro latente (AVIZIENIS et al., 2004). A causa de um erro é uma falha (fault). Um erro é
uma falha que foi ativada, quando não é dito que a falha está dormente (AVIZIENIS et al.,
2004; PULLUM, 2001). Uma falha é um estado do sistema que pode causar a redução ou a
falta de capacidade do sistema de prover corretamente uma determinada funcionalidade
(LEE; ANDERSON, 1990; ISERMANN, 2006).
30
Não há uma relação de unicidade entre uma falha e um erro: uma falha pode gerar
vários erros e estes erros podem ter sido ocasionados por uma única falha, em termos
de manifestação e detecção em um sistema. Um erro quando presente em um sistema,
pode sistematicamente transformar-se em outros erros até atingir as fronteiras do sistema,
causando um defeito. Essa cadeia é conhecida como cadeia de ameaças e está representada
na Figura 3. Quanto maior é a propagação de erro através de um sistema, maior é a
dificuldade dessa falha ser tolerada (RASHID; PATTABIRAMAN; GOPALAKRISHNAN, 2014).
Portanto, a detecção e identificação eficaz e rápida dos erros traz melhorias ao processo
de tolerância a falhas (MITRA; BRELSFORD; SANDA, 2010).
Figura 3: Cadeia de Ameaças adaptada de Avizienis et al. (AVIZIENIS et al., 2004)
Fonte: O Autor
2.2.1.3 Meios
Além da tolerância a falhas, existem outros três meios de se obter a dependabilidade
(AVIZIENIS et al., 2004):
• Prevenção de falhas: refere-se à aplicação de princípios de design e operação que
previnam a ocorrência de falhas.
• Remoção de falhas: refere-se à aplicação de técnicas que visam reduzir a quantidade
e a severidade das falhas.
• Previsão de falhas: refere-se a utilização de técnicas de previsão e o endereçamento
das falhas atuais e que estão por acontecer, além de suas consequências.
Esses meios são agrupados de acordo com as ações tomadas pelas abordagens em
relação às falhas para se atingir a dependabilidade. A ação mais óbvia e direta é garantir
que o sistema esteja livre de falhas. Para tal é necessário que as potenciais falhas sejam
evitadas, assim qualquer falha deve ser eliminada antes do sistema entrar em operação ou
prever novas falhas quando o sistema estiver operando. Esse agrupamento de abordagens
31
é definido como prevenção de falhas (LEE; ANDERSON, 1990; PULLUM, 2001). O segundo
agrupamento de abordagens aceita que o sistema construído não é perfeito e requer esforço
para manter o sistema em funcionamento mesmo na presença de falhas, que é definido
como tolerância a falhas (LEE; ANDERSON, 1990; PULLUM, 2001).
A tolerância a falhas é baseada no princípio de que os outros meios não serão to-
talmente efetivos e por esta razão, é necessário implementar mecanismos para prover a
tolerância a falhas, prevenindo danos (AVIZIENIS et al., 2004). A prevenção, remoção e
previsão de falhas, apesar de importantes para a área de tolerância a falhas, não se pode
garantir que se conseguirão prever e evitar todos os cenários de falhas nos sistemas (STRI-
GINI, 2012). Portanto, a utilização de estratégias de tolerância a falhas é essencial para se
atingir a dependabilidade em sistemas computacionais.
2.2.2 Etapas
O processo de tolerar falhas refere-se à habilidade de entregar corretamente um serviço
mesmo na presença de falhas no sistema (AVIZIENIS, 1967). Esse processo é normalmente
realizado através de etapas não sequenciais, porém que atuam em conjunto para habilitar
a mitigação das falhas. As etapas para a realização da tolerância a falhas são (PASIN;
RIVEILL; WEBER, 2001; LEE; ANDERSON, 1990):
• Detecção de Erros: A detecção de erros é o primeiro passo para possibilitar a
tolerância a falhas em um sistema. Nesta etapa a estratégia de tolerância a falhas
tenta detectar estados errôneos do sistema. Esta detecção pode ocorrer durante a
execução normal dos serviços, sendo chamada de detecção concorrente ou de maneira
preemptiva que ocorre durante a suspensão da execução do serviço para a checagem
de falhas dormentes. Todos os sistemas tolerantes a falhas devem possuir formas de
identificar erros.
• Confinamento e avaliação: Quando um erro é identificado, este precisa ser isolado
para prevenir a propagação, bem como fazer a avaliação dos danos. Assim, devido
ao provável atraso entre a manifestação das falhas e ocorrência do erro é necessário
avaliar o dano causado e quais serão as medidas adotadas para tolerar essa falha.
Assim, essa avaliação é baseada em informações contextuais (Ex.: componentes er-
rôneos, tempo de ocorrência e outras informações relacionadas) ajuda a identificar o
melhor procedimento de recuperação a ser executado sobre aquela falha hipotética.
O confinamento serve para garantir que o comportamento errôneo seja colocado em
32
quarentena e seu erro seja isolado impedindo a propagação de informações inválidas
antes da aplicação do procedimento de recuperação.
• Recuperação: Uma vez que o erro foi detectado e analisado, entra em ação a
etapa de recuperação que serve para transformar o estado errôneo corrente de um
sistema em um estado livre de erros para que a operação regular volte a acontecer.
Outra denominação a esta etapa é a mitigação dos erros em que a recuperação é
realizada substituindo o estado errôneo por um estado livre de erros ou mitigando
o erro, fazendo a transição para um novo estado (HANMER, 2013). Um exemplo de
mitigação é o tratamento empregado para realizar a correção de dados. Uma das
formas de recuperar ou mitigar os erros é através da utilização de redundância. Para
tal, é necessário utilizar componentes auxiliares que realizam a mesma função ou
funções similares de outros elementos com o objetivo de prevenir ou recuperar-se
dos defeitos (ISO/IEC/IEEE, 2017).
• Tratamento e continuação de serviço: É a última etapa do processo de to-
lerância a falhas, e as técnicas de tratamento atuam para que o sistema continue
provendo o serviço demandado de maneira correta, garantindo que os efeitos da falha
que foi recuperada não ocorram novamente. Esta etapa é dividida em dois estágios:
localização das falhas que visa garantir que a falha não seja ativada novamente,
portanto sendo necessário identificar sua localização; e reparação do sistema que
normalmente necessita reconfigurar ou atualização o sistema que o estado errôneo
seja removido (HANMER, 2013). Uma vez que o erro foi localizado e reparado é o
momento de retornar o sistema para a sua operação normal. Uma maneira simples
de executar essa operação é realizando o reinício do sistema.
2.2.3 Injeção de Falhas
Para avaliar o funcionamento de um sistema na presença de falhas, bem como os
mecanismos de tolerância empregados, utiliza-se a estratégia de injeção de falhas para
avaliar e monitorar experimentalmente o comportamento do sistema. A injeção de falhas
pode ser realizada através do nível de hardware ou software, e é um meio utilizado paraantecipar os cenários em que os erros são ocasionados (NATELLA; COTRONEO; MADEIRA,
2016).
Uma forma de se fazer isso é utilizando o mecanismo de Software Fault Injection
(SFI). Este mecanismo consiste em um procedimento automatizado para geração de falhas,
33
injeção, monitoramento e coleta de informações a respeito das falhas e do sistema alvo
(HSUEH; TSAI; IYER, 1997). Uma alternativa ao uso do SFI é realizar a inserção de falhas
de maneira manual. Isso envolve operações diversas como, por exemplo, desabilitar a placa
de rede de um dos nós para provocar uma falha de comunicação, remover um sensor da
rede ou até mesmo provocar um efeito em um ambiente causando uma mudança nos dados
gerados, entre outras.
2.3 Conclusões
Este capítulo apresentou os conceitos essenciais relacionados a esta tese, como Internet
das Coisas e Tolerância a Falhas. Na seção de Internet das Coisas, foram apresentados os
conceitos fundamentais, características e a necessidade de garantir que aplicações sejam
confiáveis. Na seção de Tolerância a Falhas, foram apresentados os conceitos fundamentais
de dependabilidade. Além disso, foi apresentada a árvore de dependabilidade e detalhada
toda sua taxonomia de atributos, ameaças e meios. Ademais, identificamos as etapas cons-
tituintes da implementação das estratégias de tolerância a falhas: Detecção, Confinamento
e avaliação, Recuperação, e Tratamento e continuação de serviço. Finalmente, apresen-
tamos o conceito de injeção de falhas, técnica utilizada para avaliar experimentalmente
sistemas na presença de falhas.
34
3 A Patologia de Falhas em Sistemas
IoT
Geralmente, os sistemas IoT estão inseridos em um ecossistema composto por vários
sistemas independentes e elementos computacionais heterogêneos que colaboram para
atender objetivos em comum. Esta colaboração entre sistemas (no mundo físico e ciber-
nético) introduz uma interdependência complexa entre sistemas e elementos IoT. Devido
a essas características, em sistemas IoT, as falhas são quase inevitáveis (ASIM; MOKHTAR;
MERABTI, 2010; SOUZA; VOGT; BEIGL, 2007; ALHO; MATTILA, 2015). Associado a isso, se
nenhuma ação for tomada, uma falha ocorrida em um sistema pode ser significativamente
ampliada devido a essas relações complexas e interdependentes, levando vários sistemas
a falharem comprometendo a dependabilidade dos serviços (BEREZIN et al., 2015; BULDY-
REV et al., 2010). Assim, neste trabalho realizamos uma investigação do estado da arte
com o objetivo de entender o comportamento das falhas em sistemas IoT e identificar
problemas em aberto.
Em qualquer sistema, existe uma relação causal entre falhas, erros e defeitos. Esta
relação dos mecanismos de criação e manifestação de ameaças são materializados quando
a cadeia de falha-defeito é ativada. Uma interpretação genérica é que o erro só ocorre
quando uma falha é ativada, e por propagação, pode gerar vários erros antes de um defeito
ocorrer. Assim, esta propagação e instanciação da cadeia podem ocorrer via interação
entre componentes, elementos e sistemas. Essas manifestações e relações entre ameaças
da dependabilidade são chamadas de patologia de falha. Este conceito foi estabelecido por
Avizienis et al. (AVIZIENIS et al., 2004).
Dessa maneira, para entender e classificar o comportamento das falhas em um sistema
IoT é necessário estabelecer a relação de causalidade e interdependência entre essa cadeia
de ameaças. Portanto, este estudo tem como objetivo estabelecer a patologia das falhas
em um sistema IoT, identificando e classificando a origem, tipos e comportamentos das
falhas em sistemas IoT. A Figura 4 apresenta o estabelecimento da patologia de falhas
35
relacionando-a com a cadeia de ameaças.
Para estabelecer a patologia, foi executada uma revisão da literatura relatada na
Seção 3.1. Essa revisão teve como objetivo identificar a origem das falhas, estabelecendo
as principais fontes de ameaças e a ocorrência de erros. Além disso, foi investigado e
classificado quais os tipos de falhas são os mais comuns de ocorrerem em sistemas IoT.
Assim, foi proposta uma taxonomia da classificação dos tipos de falhas e erros. Na Seção
3.3 foi realizada uma análise do processo de ocorrência e propagação de falhas em sistemas
IoT considerando sua forma e características estabelecendo um modelo de propagação de
defeitos.
Figura 4: Cadeia de Ameaças em Sistemas IoT Associada a Suas Patologias
O Autor
3.1 Revisão do Estado da Arte
Esta seção descreve o protocolo, bem como os resultados da revisão do estado da
arte a respeito da origem e os tipos de falhas presentes em sistemas IoT, a mesma foi
importante para ajudar os pesquisadores a terem uma compreensão geral da origem e
comportamento das falhas, bem como as estratégias utilizadas para tolerá-las. Desse modo,
os pesquisadores tinham o intuito de entender como ocorrem as falhas e quais são suas
classificações.
3.1.1 Metodologia
Esta revisão do estado da arte foi baseada no método de uma revisão por Snowballing
definido por Wholin (WOHLIN, 2014). Assim, esse estudo tem como objetivo avaliar o
estado da arte e identificar questões em aberto na área de tolerância a falhas e suas
36
implicações em sistemas IoT.
3.1.1.1 Objetivo e Questões de Pesquisa
Além de obter uma visão geral a respeito da área de tolerância a falhas em sistemas
IoT, esta revisão almeja proporcionar uma visão clara sobre a origem e tipos de falhas que
ocorrem nestes sistemas. Assim, pesquisadores e profissionais da área podem beneficiar-se
produzindo soluções mais adequadas para tolerar falhas em seus contextos específicos.
Dessa maneira, este objetivo foi refinado nas seguintes Questões de Pesquisa (QP) :
QP1 – Quais são as origens de falhas em sistemas IoT?
QP2 – Como são caracterizadas as falhas em sistemas IoT?
3.1.1.2 Processo de Busca e Seleção
Assim, a busca inicial foi executada através do engenho de busca automatizado Scopus
1. Esse engenho de busca foi selecionado por indexar as principais bases de conhecimento
da área de Ciência da Computação e Engenharia. A Tabela 1 apresenta exemplos de
algumas bases indexadas pelo Scopus. Esse procedimento mitiga a falta de pesquisa em
outras bases facilitando o processo de extração e sumarização.
Tabela 1: Principais Bases de conhecimento indexadas pelo Scopus
Base Endereço
ACM Digital Library https://dl.acm.org/
Elsevier https://www.elsevier.com/
IEEE Xplore http://ieeexplore.ieee.org/
Springer Link https://link.springer.com/
Fonte: O Autor
A definição da string de Busca considerou termos relacionados à Internet das coisas
e dependabilidade, com o objetivo de obter o maior número de artigos que relacionassem
essas duas áreas. No entanto, sistemas IoT podem estar envolvidos em diferentes de domí-
nios sendo necessário considerar essa multidisciplinariedade de tecnologias e paradigmas
(KRIEBEL et al., 2018; OJIE; PEREIRA, 2017; FRÖHLICH et al., 2018). Assim, a String de
busca definida é detalhada a seguir:
1https://www.scopus.com/
37
(fault or error or failure) AND ( classification OR definition OR class or taxonomy or
source or semantic ) AND ( “Internet of Thing” or IoT OR “wireless sensor network” or
WSN OR “Cyber-Physical Systems” or cps OR pervasive )
3.1.2 Critérios de inclusão e exclusão
Nesta revisão foram considerados e filtrados todos os estudos que estivessem de acordo
com os seguintes critérios:
• Não discutiam ou caracterizavam falhas em sistemas IoT.
• Não estavam em inglês;
• Não estavam disponibilizados por completo;
3.1.3 Definição do conjunto inicial e Processo de iteração
Para obter sucesso na execução de uma revisão da literatura utilizando Snowballing é
necessário identificar um conjunto inicial de trabalhos a serem avaliados. Algumas carac-
terísticas são essenciais para a inclusão desses trabalhos como ponto de partida da revisão,
como: devem ser relevantes e bem citados na área em questão, devem cobrir diferentes
anos, autores e locais de publicação devem ter relação com asquestões de pesquisas defini-
das. Dessa maneira, seguindo essas indicações foram identificados 22 possíveis candidatos
a fazerem parte do conjunto inicial baseado na String busca definida na Seção 3.1.1.2.
No entanto, aplicando os critérios de exclusão, bem como a leitura dos títulos e resumos,
restaram 11 trabalhos para iniciar a execução do processo de revisão.
Uma vez que o conjunto inicial foi definido, é necessário executar o processo de
backward snowballing e forward snowballing. Esses processos são apresentados na Figura 5.
Assim, para cada trabalho do conjunto inicial são executadas as duas etapas. No backward
snowballing, o objetivo é incluir novos trabalhos a partir da lista de referências. Assim,
para cada referência do artigo analisado, são avaliados o título e os critérios de exclusão
caso haja uma indicação para inclusão, então o resumo do trabalho candidato é lido. Caso
seja, decidido que esse trabalho candidato será incluído então ele é selecionado e será
avaliado e analisado na próxima iteração. O forward snowballing refere-se a análise dos
artigos que citam o trabalho analisado. Assim, o trabalho candidato tem sua avaliação do
título e critérios de exclusão avaliados e caso haja uma indicação de inclusão, seu resumo
é lido, conforme ocorre no backward snowballing.
38
Figura 5: Procedimento de Snowballing
Fonte: O Autor
3.1.4 Coleta de dados
Os dados necessários para análise e avaliação extraídos 2 e coletados a partir dos
trabalhos foram: ano de publicação, autores, título, tipo da publicação, repositório de
pesquisa. Adicionalmente, para os trabalhos lidos cuidadosamente também se coletou
os dados necessários para responder às questões de pesquisa, como: objetivo, domínio,
classificação da origem de falhas, tipos de falhas, desafios e oportunidades.
3.1.5 Validade do processo
Os estudos foram analisados durante dois meses por dois pesquisadores para garantir
a validade do processo. No entanto, o principal viés desta revisão é que as conclusões dela
podem refletir a opinião deles, em virtude da subjetividade das tarefas do protocolo de
trabalhos deste tipo.
3.1.6 Resultados
O processo de seleção dos trabalhos analisados nesta revisão do estado da arte é
apresentado na Figura 6. Primeiramente, para estabelecer o conjunto inicial de artigos que
serão avaliados através do procedimento de snowballing, foi executada a String de Busca na
2Os dados coletados estão disponíveis no seguinte endereço: https://bit.ly/2Xg63ow
39
base de dados Scopus, a qual retornou 1374 trabalhos. Em virtude da grande quantidade
de trabalhos obtidos através da pesquisa, foram aplicados os critérios de exclusão e a
relevância do trabalho para a área. Para tal, foram lidos o título e resumo nesta etapa
do processo, resultando na seleção de 22 trabalhos. Então, uma análise mais aprofundada
dos artigos, avaliando o conteúdo do artigo, objetivando identificar se, tratava-se de um
bom candidato a fazer parte da revisão. Após essa etapa, obteve-se como resultado em
um conjunto inicial com 11 trabalhos.
Figura 6: Processo de seleção
Fonte: O Autor
Uma vez que o conjunto inicial de artigos foi selecionado, iniciou-se a execução das
interações do procedimento de snowballing. A primeira iteração, avaliou cada artigo pre-
sente no conjunto inicial, bem como realizou as etapas de backward snowballing e forward
snowballing, conforme apresentado na Figura 5. Inclusive, avaliando se o artigo deveria
fazer parte do conjunto final para leitura completa. Nessa iteração, 10 trabalhos candida-
tos foram incluídos para serem avaliados. E, como resultado da avaliação das referências e
citações, 11 novos trabalhos foram selecionados para serem avaliados na segunda iteração.
Na segunda iteração, 6 dos 11 trabalhos avaliados nessa etapa foram incluídos na revisão.
Além disso, 6 novos trabalhos foram selecionados para fazer parte da terceira iteração. Na
terceira iteração, apenas 3 trabalhos foram incluídos e nenhum novo foi selecionado, fi-
nalizando o procedimento de snowballing. Portanto, 19 trabalhos foram selecionados para
o conjunto final de trabalhos a terem a sua leitura cuidadosa realizada. Esses trabalhos
selecionados podem ser visualizados na Tabela 2.
40
Tabela 2: Estudos selecionados e lidos cuidadosamente
ID Trabalho
T1 (CHETAN; RANGANATHAN; Campbell, 2005)
T2 (RATASICH et al., 2019)
T3 (SOUZA; VOGT; BEIGL, 2007)
T4 (MORIDI et al., 2020)
T5 (POWER; KOTONYA, 2019)
T6 (PARADIS; HAN, 2007)
T7 (MAHAPATRO; KHILAR, 2013)
T8 (CHOUIKHI et al., 2015)
T9 (LIU; NAYAK; STOJMENOVIĆ, 2009)
T10 (SWAIN; KHILAR; BHOI, 2018)
T11 (KHAN; MERABTI; ASKWITH, 2009)
T12 (ZHANG et al., 2018)
T13 (CRISTIAN, 1991)
T14 (ALRAJEI; FU; ZHU, 2014)
T15 (MUHAMMED; SHAIKH, 2017)
T16 (WARRIACH; AIELLO; TEI, 2012)
T17 (ALI; TIXEUIL, 2010)
T18 (JURDAK et al., 2011)
T19 (RAPOSO et al., 2017)
Fonte: O Autor
3.2 Respostas às questões de pesquisa
Nesta seção são respondidas as questões de pesquisa desta revisão do estado da arte.
3.2.1 QP1: Quais são as origens de falhas em sistemas IoT?
Para responder a esta questão foi realizada uma categorização da origem de falhas
considerando a camada do sistema em que a mesma pode acontecer. Assim, utilizamos a
classificação em camadas proposta por Burhan et al. (BURHAN et al., 2018), Xing (XING,
2020) e International Telecommunications Union (ITU–T) (ITU-T, 2012). Assim, as ori-
gens das falhas identificadas na revisão foram classificadas de acordo com a camada em
que ocorreu. As camadas utilizadas nessa classificação foram Percepção, Comunicação,
41
Serviço e Aplicação. Na Tabela 3 sumariza os trabalhos que classificam a origem das
falhas em sistemas IoT.
Tabela 3: Classificação dos trabalhos que relatam a origem de falhas em cada uma das
camadas
Camadas de um sistemas IoT Trabalhos
Percepção T1,T2,T3,T7,T8,T9,T11,T18,T14 e T19
Comunicação T1,T2,T3,T7,T8,T9,T11,T18,T14 e T19
Serviço T1, T2, T3, T6, T7, T8, T9, T18 e T19
Aplicação T1, T2, T8 e T18
Fonte: O Autor
3.2.1.1 Camada de Percepção
Nesta camada, as causas de falhas estão diretamente relacionadas com a obtenção e
extração dos dados associados aos dispositivos físicos. Esses dispositivos são, normalmente,
dispositivos que possuem funções de sensoriamento e atuação nos ambientes. Alguns exem-
plos de tipos de sensores e atuadores são de temperatura, umidade, eletrocardiograma,
válvulas, dispositivos de automação, entre outros. Estes dispositivos estão associados a
nós heterogêneos que necessitam de uma série de capacidade para realizar processamento
e compartilhamento das informações. Esses nós são compostos, de maneira geral, por sen-
sores e atuadores, memórias, baterias, unidades de processamento, interfaces de rede e
software embutidos.
A principal causa das falhas que ocorrem nesta camada está relacionada ao funciona-
mento dos próprios componentes. Muitas vezes, eles são feitos com requisitos e componen-
tes de baixa qualidade, o que contribui para a ocorrência de falhas. Outra causa de falhas
recorrente é o impacto do meio ambiente sobre o funcionamento dos dispositivos físicos,
causando falhas como quebra, intervenção direta e radiação. Além disso, outras causas
de falha estão relacionadas a problemas de bateria, interferência, leitura ou desempenho
incorreto e mau funcionamento do software embutido (aquisição ou funções de desem-
penho, roteamento). Dessa forma, a classificação da origem das falhas nessa camada foi
organizada considerando os principais componentes presentes nos nós sensores. Origem
das falhas dessa camada são classificadas e organizadas, tais como:
• Sensores e Atuadores: Componentes físicos, como sensores, atuadores, dispositivos
42
móveis e componentes mecânicos podem falhar. Alguns exemplos de falhas são es-
tresse físico em componentes, gabinetes inadequados, implantação em ambientes
hostis e baixa quantidade de energia, resultando no mau funcionamento dos dispo-
sitivos físicos. Além disso, os dispositivos colocados em ambienteshostis são vulne-
ráveis a falhas relacionadas à interrupção, intervenção direta ou destruição. Esses
tipos de falhas são geralmente permanentes, requerem intervenção manual e alguns
casos, substituição. Outro tipo de falha enfrentado por objetos físicos é a interfe-
rência eletromagnética. Conforme o número de dispositivos conectados aumenta, a
radiação aumenta. Esta situação pode influenciar as medições, mensagens ou sinais
de controle transmitidos (YAQOOB et al., 2017; RATASICH et al., 2019).
Falhas que causam perda de calibração podem ocorrer durante todo o ciclo de vida
das aplicações, o que diminui a precisão das medições dos sensores. Há três diferentes
tipos de erros de calibração, tais como: falhas de deslocamento (medições do sensor
deslocamento do valor inicial por uma quantidade constante), falhas de ganho (a
taxa de mudança dos dados medidos não corresponde às expectativas ao longo do
tempo), e falhas de drift (o desempenho pode se desviar da calibração original
medições) (MAHAPATRO; KHILAR, 2013).
• Unidade de Processamento: Esta fonte de falhas abrange componentes relacionados
a unidade de processamento dos nós sensores, como memória, bateria e microproces-
sador. Falhas nos componentes de processamento afetam a qualidade e consistência
dos dados armazenados e suas operações. Por exemplo, mudanças de bit de memó-
ria ou registros especiais podem corromper os dados armazenados (CHOUIKHI et al.,
2015). Falha de memória limitada ou erros de memória (vazamento ou violação de
memória) que pode fazer com que um sistema trave ou opere em modo degradado
(ALI; TIXEUIL, 2010). Outro exemplo de falha é o aumento anormal na tempera-
tura do processador, o que pode causar falhas de cálculo incorreto (MAHAPATRO;
KHILAR, 2013).
Outro tipo de falha que pode ocorrer nas unidades de processamento é sobrecarga de
processamento, esse tipo situação pode ser produzida pela baixa capacidade de com-
putação, ou até mesmo, um alto volume de solicitações superando as capacidades
do dispositivo, levando-o a falhar. Em relação a falhas relacionadas ao suprimento
de energia, uma situação que pode gerar eventos inesperados é o acréscimo ele-
vado na temperatura da bateria causando a sua degradação (RAPOSO et al., 2017).
Outra situação que pode originar falhas é a ocorrência de baixa tensão na bate-
ria gerando falhas de dados, corrupção, incompletude ou não envio (MAHAPATRO;
43
KHILAR, 2013). Em alguns cenários práticos é impossível recarregar ou substituir a
bateria faltosa durante a operação do sistema.
• Rede de Comunicação: A forma de comunicação utilizada para conectar dispositivos
pode ser sem fio ou com fio, e cada uma pode sofrer de diferentes tipos de falhas. Por
exemplo, as comunicações sem fio estão geralmente sujeitas a interferência. Alguns
exemplos de falhas são ruído do ambiente, ruído no canal, desvanecimento multipath,
interferência de radiofrequência (JURDAK et al., 2011; MAHAPATRO; KHILAR, 2013).
As comunicações com fio são vulneráveis a quebra de conectores, deterioração de
material e efeitos ambientais sobre os componentes físicos (por exemplo, sujeira)
(RATASICH et al., 2019; PARADIS; HAN, 2007).
• Software Embutido: Nos nós sensores, o software atua no processamento e rotea-
mento das informações coletadas pelos sensores. Assim, as falhas de processamento
de dados podem ocorrer se a aquisição de dados não for realizada de forma adequada
ou se os sensores subjacentes fornecerem leituras incorretas (WARRIACH; AIELLO;
TEI, 2012). Por exemplo, um erro na agregação de dados pode levar a dados errados
para os níveis superiores. Uma abordagem típica de agregação de dados calcula a
média dos valores medidos das variáveis correlacionadas, enviando apenas a infor-
mação consolidada para as camadas superiores. Se esta camada gerar informações
incorretas, os dados resultantes da agregação podem sofrer desvios do valor real.
Bugs de software são amplamente difundidos e alguns deles podem gerar falhas em
cascata. Alguns exemplos comuns são especificações de design incorretas, falhas na
arquitetura do sistema, falhas no projeto do software, algoritmos incorretos (SOUZA;
VOGT; BEIGL, 2007; CHOUIKHI et al., 2015).
3.2.1.2 Camada de Comunicação
Esta camada é responsável por possibilitar a comunicação entre as demais camadas do
sistema e os dispositivos presentes nos ambientes. Assim, ela tem como objetivo transmitir
as informações que foram coletadas e agregadas pela camada de percepção e transmitir
as camadas superiores. As principais causas de falhas nesta camada estão relacionadas
aos aspectos de rede como colisão de mensagens, violação dos protocolos de comunicação,
quebra de dispositivos, interferência, mudanças dinâmicas nas topologias de rede e con-
gestão. Dessa forma, as origem das falhas na camada de comunicação foram classificadas
em nas seguintes categorias:
44
• Link: Os links de comunicação IoT são estabelecidos por meio de comunicação com e
sem fio. Links com fio tem, usualmente, uma taxa constante de mensagens e tendem
a ser mais estáveis. No entanto, há exposição a possíveis interrupções e quebras. Por
outro lado, links sem fio são altamente voláteis e nem sempre garantem a mesma
taxa de entrega de mensagens (LIU; NAYAK; STOJMENOVIĆ, 2009; ZHANG et al., 2018;
ALRAJEI; FU; ZHU, 2014). A instabilidade do link pode levar a falhas nos caminhos
de roteamento (PARADIS; HAN, 2007; RAPOSO et al., 2017). Uma falha comum está
relacionada a interferência nos links de comunicação, apesar de afetar, normalmente,
com mais frequência as comunicações sem fio, porém também pode ocorrer nas
transmissões com fio. Se um link de comunicação estiver operando com tráfego
intenso, isso pode causar indisponibilidade ou colisão de mensagens (SOUZA; VOGT;
BEIGL, 2007; CHOUIKHI et al., 2015). Além disso, os dispositivos podem mover-se para
locais diferentes de maneira que se tornem inacessíveis, resultando em uma completa
perda de dados. Por exemplo, veículos autônomos em movimento ao entrar em
túneis subterrâneos ou locais sem torres de celular. Os links também podem falhar
quando permanentemente ou temporariamente bloqueados por objetos externos ou
condições ambientais desfavoráveis (PARADIS; HAN, 2007).
• Conectividade: Falhas de conectividade podem causar atrasos inaceitáveis, falha ou
erro na entrega de mensagens (KHAN; MERABTI; ASKWITH, 2009; SOUZA; VOGT;
BEIGL, 2007). Problemas nas rotas de transmissão podem causar falhas na entrega
das mensagens aos destinos, afetando vários caminhos do sistema e de outros siste-
mas colaborativos. O roteamento é um dos blocos fundamentais na construção de
sistemas IoT (GIA et al., 2015; MISRA et al., 2012). De maneira similar a interferência,
quanto maior o número de dispositivos comunicando-se maior a possibilidade de fa-
lhas relacionadas a colisões ou sobrecarga da rede. Outra falha de conectividade é a
violação de protocolos devido à mensagens com conteúdo errado ou a utilização de
diferentes versões de um determinado protocolo ou ainda, incompatibilidade entre
versões.
3.2.1.3 Camada de Serviço
A camada de serviço é a responsável por armazenar e processar dados em massa nos
sistemas IoT (SUO et al., 2012). Neste nível estão localizadas as estratégias de computação
em nuvem, processadores de eventos complexos (CEP) e redes de área de armazenamento
(SAN) . Falhas originadas nesta camada estão diretamente ligadas a ameaças de hard-
45
ware e software. Exemplos de falhas em hardware podem ser um disco rígido que degrada
devido a flutuação da temperatura, problemas de conectividade de rede e indisponibili-
dade de serviços (SOUZA; VOGT; BEIGL, 2007). Falhas de software estão relacionadas a
situações contextuais como a coleta de informações errôneas, problemas relacionados ao
contexto como inferência equivocadas ou a perda de eventos. Além disso, as falhas podem
estar relacionadas a restrições de controle do sistema, como erros de entrada, perda de
prazo e efeitos do envelhecimento.