Dissertacao Daniel Maas

Joinville, 2014
Ttulo
Orientador: Prof. Dr. Andr Bittencourt Leal
ANO
2014
DANIEL GUMIERO NORONHA MAAS | DIAGNSTICO DE FALHAS MULTICAMADAS
Nome do Autor
DE SISTEMAS EMBARCADOS MODELADOS POR SEDS
Este trabalho apresenta uma arquitetura de

diagnstico multicamadas para deteco de falhas
em sistemas embarcados, que permite uma melhor
discriminao do tipo e origem da falha,
possibilitando um diagnstico mais preciso e
assertivo. Os diagnosticadores so projetados
conforme a metodologia de diagnstico de falhas
em SEDs modelados por autmatos. Uma vez
concebidos,
os
diagnosticadores
so
implementados em linguagem ANSI C, atravs de
uma ferramenta de gerao automtica de
software, e finalmente incorporados ao software
principal do equipamento onde se pretende
realizar o diagnstico. Esta arquitetura de
diagnstico foi aplicada em um estudo de caso para
um refrigerador Frost Free, para o qual foram
projetados os diagnosticadores, em seguida os
mesmos foram implementados em software e
posteriormente validados a fim de comprovar a
eficcia no somente dos diagnosticadores mas
tambm da arquitetura proposta, alm do
processo de converso dos mesmos em linguagem
de software.
UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC

CENTRO DE CINCIAS TECNOLGICAS CCT
CURSO DE MESTRADO PROFISSIONAL EM ENGENHARIA ELTRICA
DISSERTAO DE MESTRADO
DIAGNSTICO DE FALHAS
MULTICAMADAS DE SISTEMAS
EMBARCADOS MODELADOS POR
SEDS
DANIEL GUMIERO NORONHA MAAS
JOINVILLE, 2014
UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC

CENTRO DE CINCIAS TECNOLGICAS - CCT
MESTRADO EM ENGENHARIA ELTRICA
DIAGNSTICO DE FALHAS MULTICAMADAS DE SISTEMAS

EMBARCADOS MODELADOS POR SEDS
JOINVILLE
2014
UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC

CENTRO DE CINCIAS TECNOLGICAS - CCT
MESTRADO EM ENGENHARIA ELTRICA
DIAGNSTICO DE FALHAS MULTICAMADAS DE SISTEMAS

EMBARCADOS MODELADOS POR SEDS
Dissertao submetida ao Programa

de Ps-Graduao em Engenharia
Eltrica do Centro de Cincias Tecnolgicas da Universidade do Estado de Santa Catarina, para a obteno do grau de Mestre em Engenharia Eltrica.
Orientador:
Prof. Dr. Andr Bittencourt Leal
JOINVILLE
2014
FICHA CATALOGRFICA
M111d
Maas, Daniel Gumiero Noronha

Diagnstico de falhas multicamadas de sistemas embarcados modelados
por SEDs/ Daniel Gumiero Noronha Maas. 2014.
173 p. : il. ; 21 cm
Orientador: Andr Bittencourt Leal
Bibliografia: p. 173-177
Dissertao (mestrado) Universidade do Estado de Santa Catarina, Centro de
Cincias Tecnolgicas, Mestrado em Engenharia Eltrica, Joinville, 2014.
1. Engenharia eltrica. 2. Diagnstico de falhas. 3. Sistemas embarcados. 4. Sistemas a
eventos discretos. I. Leal, Andr Bittencourt. II. Universidade do Estado de Santa
Catarina. Programa de Ps-graduao em Engenharia Eltrica. III. Ttulo.
CDD: 621.3 20.ed.
Este trabalho dedicado aos meus filhos Joo Victor, Pedro Henrique e
Maria Victria, e especialmente minha esposa rika, pelo apoio,
compreenso e imensa pacincia.
AGRADECIMENTOS
Gostaria de agradecer sobre tudo a Deus por ter me dado foras

e sade para vencer mais este desafio.
Agradeo grandemente minha esposa rika Maas Noronha,
por sempre acreditar em mim.
Muito obrigado aos meus pais Elisabete Gumiero Noronha e Jos
Carlos Noronha, que mesmo distantes, sempre me apoiaram e me deram
foras para alcanar esse objetivo.
Muito obrigado aos meus sogros Rolfe Maas e Maria das Graas e Silva Maas, por sempre acreditarem em mim, pelas palavras de
incentivo e suporte nos momentos difceis.
Muito obrigado ao grande amigo Cludio Navarro, sempre presente e disposto a ajudar e compartilhar seus conhecimentos e experincias.
Muito obrigado ao meu orientador Prof. Dr. Andr Bittencourt
Leal, por seu comprometimento, apoio e tambm por ter abdicado de momentos com sua famlia para se dedicar reviso deste trabalho.
Muito obrigado aos professores membros da banca examinadora, professor Dr. Joo Carlos dos Santos Basilio e professor Dr. Ademir
Nied por seu tempo dedicado e suas enriquecedoras contribuies.
Muito obrigado aos colegas de trabalho Valmor Adami Junior,
Alexandre Junkes Pinotti, Carlos Henrique Nacer e Luiz Felipe da Silva
por todas ideias e discusses que geraram diversas contribuies. Em
nome desses meu obrigado Whirlpool por permitir que desenvolvesse
meu trabalho.
A todos meu Muito Obrigado.
Jamais considere seus estudos como uma obrigao, mas como uma
oportunidade invejvel para aprender a conhecer a influncia libertadora
da beleza do reino do esprito, para seu prprio prazer pessoal e para
proveito da comunidade qual seu futuro trabalho pertencer.
(Albert Einstein)
RESUMO
Este trabalho apresenta uma arquitetura de diagnstico multicamadas para deteco de falhas em sistemas embarcados, que
permite uma melhor discriminao do tipo e origem da falha, possibilitando um diagnstico mais preciso e assertivo. Esta arquitetura
contempla as interfaces necessrias para permitir a integrao no
sistema embarcado e tambm considera o tratamento das informaes de diagnstico para fins de aes de recuperao do sistema,
ou simplesmente a externalizao destas informaes. Neste trabalho, consideram-se os diagnosticadores projetados conforme a metodologia de diagnstico de falhas em SEDs modelados por autmatos. Uma vez concebidos, os diagnosticadores so implementados
em linguagem ANSI C, atravs de uma ferramenta de gerao automtica de software, e finalmente incorporados ao software principal
do equipamento onde se pretende realizar o diagnstico. Esta arquitetura de diagnstico foi ento aplicada em um estudo de caso
para um refrigerador Frost Free, para o qual foram projetados os diagnosticadores, em seguida os mesmos foram implementados em
software e posteriormente validados a fim de comprovar a eficcia
no somente dos diagnosticadores mas tambm da arquitetura proposta, alm do processo de converso dos mesmos em linguagem
de software.
Palavras-chaves: diagnstico de falhas, sistemas embarcados, sistemas a eventos discretos.
ABSTRACT
This work presents a multilayer architecture for fault diagnosis in embedded systems that allows a better discrimination of the
type and source of the failure, providing an accurate and assertive diagnosis. This architecture contemplates the necessary interfaces to
allow integration of this diagnostic framework in the embedded system and also considers the treatment of diagnostic information for recovery system actions purposes, or simply allows the externalization
of such information. This work considers the diagnosers designed
according to the methodology of fault diagnosis in DES modeled by
automata. Once designed the diagnosers are implemented in ANSI
C language through an automated software generation tool, and finally incorporated into the main product software where it intends to
perform the diagnosis. This architecture diagnosis was then applied
in a case study for Frost Free refrigerator, for which the diagnosers
were designed then were implemented in software and subsequently
validated in order to confirm the effectiveness of the diagnosers, of
the proposed architecture beyond the C language conversion process.
Key-words: fault diagnosis, embedded systems, discrete event systems.
LISTA DE FIGURAS
Figura 2.1 Exemplo de um Diagrama de Transio de Estados

para um Autmato . . . . . . . . . . . . . . . . . . . . 42
Figura 2.2 Autmato para o Exemplo 2 . . . . . . . . . . . . . . 44
Figura 2.3 (a) Autmato no-determinstico do exemplo 3; (b)Autmato
no-determinstico com transio- do exemplo 4 . . . 49
Figura 2.4 Autmato determinstico para o evento a no observvel 51
Figura 2.5 Exemplo 5: (a) Autmato Parcialmente Observado;
(b) Observador . . . . . . . . . . . . . . . . . . . . . 55
Figura 2.6 Arquitetura Conceitual de um Sistema com um Subsistema de Diagnstico de Falhas . . . . . . . . . . . 60
Figura 2.7 Autmato Rotulador para Construo de Diagnosticadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 2.8 (a) Autmato G para o exemplo 6; (b) G k Al ; (c) Gd =
Obs(G k Al ) . . . . . . . . . . . . . . . . . . . . . . . 62
Figura 2.9 (a) Autmato G para o exemplo 7; (b) G k Al ; (c) Diagnosticador Centralizado de G . . . . . . . . . . . . 67
Figura 2.10 Arquitetura Descentralizada com Coordenao . . . . 69
Figura 3.1 (a) Diagrama de blocos para um dispositivo com sistema de controle embarcado; (b) Diviso de camadas
para um dispositivo com sistema embarcado . . . . . 78
Figura 3.2 Sistema de Diagnstico Multicamadas . . . . . . . . . 80
Figura 3.3 Arquitetura Multicamadas para Diagnstico . . . . . . 82
Figura 4.1 Refrigerador Forst Free . . . . . . . . . . . . . . . . . 88
Figura 4.2 Componentes Bsicos de um Refrigerador . . . . . . 90
Figura 4.3 (a) Detalhe do Evaporador Montado com uma Resistncia de Degelo; (b) Condio do Evaporador com
Formao de Gelo
. . . . . . . . . . . . . . . . . . . 91
Figura 4.4 Forma de Onda da Temperatura Durante os Ciclos

Termostticos . . . . . . . . . . . . . . . . . . . . . . 93
Figura 4.5 Diagrama de Blocos de um Refrigerador
. . . . . . . 95
Figura 4.6 Sistema de Diagnstico Multicamadas para um Refrigerador
. . . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 4.7 Autmato que Modela a Rotina Termosttica, GTC . . 99

Figura 4.8 Autmato Rotulador para Falha na Rotina Termosttica, AlT h . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figura 4.9 Autmato obtido pela composio GTC ||AlT h . . . . . 101
Figura 4.10 Diagnosticador para Rotina Termosttica, GdT h . . . . 102
Figura 4.11 Autmato que Modela a Rotina de Controle do Compressor, GCompRoutine . . . . . . . . . . . . . . . . . . . 104
Figura 4.12 Autmato Rotulador para Falha na Rotina de Controle
do Compressor, AlCompModel
. . . . . . . . . . . . . . 106
Figura 4.13 Autmato resultante de GCompRoutine ||AlCompModel . . . 107

Figura 4.14 Diagnosticador para a Rotina de Controle do Compressor, GdCompRoutine . . . . . . . . . . . . . . . . . . 108
Figura 4.15 Autmato que Modela a Rotina de Degelo, GDe f Model . 110
Figura 4.16 Autmato Rotulador para Falha na Rotina de Degelo,
AlDe f Label . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figura 4.17 Autmato obtido pela composio GDe f Model ||AlDe f Label 112
Figura 4.18 Diagnosticador para a Rotina de Degelo, GdDe f Model . 113
Figura 4.19 Autmato que Modela os Rels, GLoad _x_Relay . . . . . 117
Figura 4.20 Diagnosticador para o Modelo GLoad _x_Relay . . . . . . 118
Figura 4.21 Autmato que Modela os Rels considerando Mapeamento de Sensor, GMap_Load _x_Relay . . . . . . . . . . 119
Figura 4.22 Autmatos Rotuladores para Falhas de Rel, AlRelayClosed
e AlRelayOpen . . . . . . . . . . . . . . . . . . . . . . . 120
Figura 4.23 Autmato obtido pela composio GMap_Load _x_Relay ||
AlRelayClosed || AlRelayOpen
. . . . . . . . . . . . . . . . 121
Figura 4.24 Diagnosticador para os Rels, GdL oad _x_Relay
. . . . . 122
Figura 4.25 Autmato que Modela o Compressor, GComp
. . . . . 123
Figura 4.26 Autmato Rotulador referente a Falha do Compressor, AlCompMotorModel . . . . . . . . . . . . . . . . . . . 123

Figura 4.27 Modelo para o Rel do Compressor, GCompRelay . . . . 124
Figura 4.28 Diagnosticador para o modelo (G(Comp ||GCompRelay ) . . 124
Figura 4.29 Comportamento das Temperaturas do Refrigerador . . 125
Figura 4.30 Autmato que Modela o Comportamento da Porta,
GDoor . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Figura 4.31 Modelo Final para o Compressor, GC
. . . . . . . . . 127
Figura 4.32 Autmato GC _Map resultante de GC ||AlCompMotorModel 128

Figura 4.33 Diagnosticador para o Compressor, GdComp . . . . . . 129
Figura 4.34 Diagnosticador do Compressor Minimizado, GdCompMin 131
Figura 4.35 Diagnosticador do Compressor Minimizado e Simplificado, GdCompMinSimple
. . . . . . . . . . . . . . . . . 131
Figura 4.36 Autmato que modela a Resistncia de Degelo, GHeater 132

Figura 4.37 Autmato que Modela o Rel da Resistncia de Degelo, GHeaterRelay . . . . . . . . . . . . . . . . . . . . . 133
Figura 4.38 Autmato GH obtido pela composio GHeater ||GHeaterRelay
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figura 4.39 Comportamento do Degelo para o Caso de Resistncia Desconectada . . . . . . . . . . . . . . . . . . . . 135
Figura 4.40 Autmato GH _Map que modela a Resistncia de Degelo considerando Mapeamento de Sensor . . . . . . 136
Figura 4.41 Autmato Rotulador para Falha da Resistncia de Degelo, AlHeater . . . . . . . . . . . . . . . . . . . . . . . 137
Figura 4.42 Autmato obtido pela composio GH _Map ||AlHeater . . 138
Figura 4.43 Diagnosticador da Resistncia de Degelo, GdHeater . . 139
Figura 4.44 Diagnosticador Simplificado da Resistncia de Degelo,
GdHeaterSimple
. . . . . . . . . . . . . . . . . . . . . . 139
Figura 5.1 Diagrama de Classe do DAM . . . . . . . . . . . . . . 143

Figura 5.2 Rotina que Manipula os Autmatos Diagnosticadores
144
Figura 5.3 Formato da Lista de Transies Relativa aos Eventos 145

Figura 5.4 Lista de Estados Relativos a cada Autmato . . . . . 146
Figura 5.5 Exemplo de Implementao da Lista de Eventos . . . 147

Figura 5.6 Parte do Software do Mdulo Events Relativo Implementao do Modelo do Heater . . . . . . . . . . . 149
Figura 5.7 Funes que retornam os estado de um dado autmato e resultado do diagnstico . . . . . . . . . . . . 150
Figura 5.8 Ferramenta de Gerao Automtica de Cdigo . . . . 151
Figura 5.9 Sequncia de Projeto e Implementao de Diagnosticadores . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figura 5.10 Arquitetura de Diagnstico Aplicada ao Estudo de Caso154
Figura 5.11 Exemplo de Externao de um Cdigo de Falha . . . 155
Figura 6.1 Ferramenta STVD . . . . . . . . . . . . . . . . . . . . 159
Figura 6.2 Ferramenta Automata Player Monitor . . . . . . . . . 160
Figura 6.3 Insero de Bug na Rotina Termosttica para Validao do Diagnosticador . . . . . . . . . . . . . . . . . 163
Figura 6.4 Insero de Bug na Rotina de Controle do Compressor para Validao do Diagnosticador . . . . . . . . . 164
Figura 6.5 Insero de Bug na Rotina de Degelo para Validao
do Diagnosticador . . . . . . . . . . . . . . . . . . . . 165
LISTA DE TABELAS
Tabela 4.1Tabela de Eventos para o Diagnosticador da Rotina do

Compressor . . . . . . . . . . . . . . . . . . . . . . . . 109
Tabela 4.2Tabela de Eventos para o Diagnosticador da Rotina de
Degelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Tabela 4.3Mapeamento de Sensor para o Modelo dos Rels
. . . 118
Tabela 4.4Mapeamento de Sensor para o Modelo do Compressor
130
Tabela 4.5Mapeamento de Sensor para Resistncia de Degelo . . 135
LISTA DE ABREVIATURAS E SIGLAS
ANSI
American National Standards Institute
API
Application Programming Interface
DAM
Diagnoser Automata Model
GF
Gerenciador de Falhas
IDE
Integrated Development Environment
IDES
Integrated Discrete-Event Systems
LCD
Liquid Crystal Display
LED
Light-Emitting Diode
MIT
Massachusetts Institute of Technology
NTC
Negative Temperature Coefficiente
RC
Refrigerator Compartment
SED
Sistema a Eventos Discretos
SRF
Sistema de Recuperao de Falhas
STVD
ST Visual Develop
LISTA DE SMBOLOS
Conjunto de eventos
Conjunto de eventos observveis, o
uo
Conjunto de eventos no-observveis, uo
f = { f }
Conjunto de eventos de falha, f uo
Fecho de Kleene
Linguagem gerada por um autmato
Prefixo Fechamento de uma sequncia s
kt k
Comprimento de uma sequncia t
L/s
Continuao da linguagem L aps uma sequncia s
( f )
Conjunto de todas as sequncias de L que terminam

com um evento de f
f s
s ( f ) 6= 0/
2A
Conjunto potncia de A
Operador de remoo de eventos de um conjunto
Po
Projeo de elementos de em o
Po1
Projeo inversa de elementos de o em 2
G1 k G2
Composio paralela de G1 e G2
Obs(G,o )
Observador de G em relao a o
Gd
Diagnosticador centralizado para o autmato G
Al
Autmato rotulador de falhas
SUMRIO
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Fundamentos tericos de diagnose de falhas em SEDs . . . 35

2.1
Sistemas a Eventos Discretos . . . . . . . . . . . . . . . . 35
2.2
Linguagens e Autmatos Determinsticos de Estados Finitos 36

2.2.1
Linguagens . . . . . . . . . . . . . . . . . . . . . . 36
2.2.2
Autmatos Determinsticos de Estados Finitos . . . 40
2.2.3
Operaes com Autmatos . . . . . . . . . . . . . 43
2.3
Autmatos No-Determinsticos . . . . . . . . . . . . . . . 47
2.4
SEDs Parcialmente Observados . . . . . . . . . . . . . . . 50
2.5
Observador . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.6
Diagnosticabilidade . . . . . . . . . . . . . . . . . . . . . . 54
2.7
Diagnosticador . . . . . . . . . . . . . . . . . . . . . . . . 58
2.8
Diagnose Centralizada . . . . . . . . . . . . . . . . . . . . 60
2.9
Diagnose Descentralizada com Coordenao . . . . . . . . 66
2.10 Concluses do Captulo . . . . . . . . . . . . . . . . . . . 70

3
Proposta de Arquitetura Multicamadas para o Diagnstico

de Falhas em Sistemas Embarcados . . . . . . . . . . . . . . 71
3.1
Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . 72
3.2
Estrutura de Sistemas Embarcados . . . . . . . . . . . . . 75
3.3
Diagnstico Multicamadas . . . . . . . . . . . . . . . . . . 77
3.4
Arquitetura Multicamadas para Diagnstico de Falhas em

Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . 81
3.5
4
Concluses do Captulo . . . . . . . . . . . . . . . . . . . 84
Estudo de Caso: Refrigerador Domstico Frost Free . . . . . 87

4.1
Descrio do Refrigerador Frost Free . . . . . . . . . . . . 88

4.1.1
Principio de Funcionamento de um Refrigerador . . 88
4.1.2
Tecnologia Frost Free
. . . . . . . . . . . . . . . . 90
4.2
4.1.3
Controle Termosttico . . . . . . . . . . . . . . . . 92
4.1.4
Rotina de Degelo . . . . . . . . . . . . . . . . . . . 92
Aplicao do Diagnstico de Falhas Multicamadas em um

Refrigerador Domstico Frost Free
4.3
. . . . . . . . . . . . . 95
Projeto dos Diagnosticadores da Camada de Software . . . 96

4.3.1
4.3.2
Diagnosticador da Rotina Termosttica . . . . . . . 97

Diagnosticador da Rotina de Controle do Compressor . . . . . . . . . . . . . . . . . . . . . . . . 102
4.3.3
4.4
Projeto dos Diagnosticadores da Camada de Hardware . . 115
4.5
Projeto dos Diagnosticadores da Camada de Cargas
4.4.1
4.6
5
Diagnosticador da Rotina de Degelo . . . . . . . . 108

Diagnosticadores dos Rels . . . . . . . . . . . . . 115
. . . 118
4.5.1
Diagnosticador para o Compressor . . . . . . . . . 120
4.5.2
Diagnosticador da Resistncia de Degelo . . . . . . 130
Metodologia de Implementao do Sistema de Diagnstico

Multicamadas . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.1
Software de Implementao dos Diagnosticadores . . . . . 141
5.2
Ferramenta de Gerao Automtica de Cdigo . . . . . . . 148
5.3
Aplicao da Metodologia no Estudo de Caso . . . . . . . 151
5.4
Validao dos Diagnosticadores

6.1
6.2
. . . . . . . . . . . . . . . . 157
Metodologia de Validao . . . . . . . . . . . . . . . . . . 157

6.1.1
Ferramenta de Depurao . . . . . . . . . . . . . . 158
6.1.2
Ferramenta Automata Player Monitor . . . . . . . . 158
Validao dos Diagnosticadores: Detalhamento
. . . . . . 161
6.2.1
Validao dos Diagnosticadores da Camada de Soft-
6.2.2
Validao dos Diagnosticadores da Camada de Hard-
ware . . . . . . . . . . . . . . . . . . . . . . . . . . 161
ware . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.2.3
Validao dos Diagnosticadores da Camada de Cargas . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.3
7
Concluso e Trabalhos Futuros . . . . . . . . . . . . . . . . . 171
REFERNCIAS BIBLIOGRFICAS . . . . . . . . . . . . . . . . . . 173
29
1 INTRODUO
O constante aumento da complexidade dos sistemas tecnolgicos e a crescente exigncia por desempenho e confiabilidade, tem demandado o desenvolvimento de mtodos cada vez mais sofisticados e
sistemticos para um diagnstico rpido e preciso das falhas que podem
ocorrer no sistema (SAMPATH et al., 1996; CARVALHO, 2011). Perante
esta realidade, o problema de diagnstico de falhas, tem recebido ateno
considervel em diversas reas dentre as quais podemos citar a engenharia de confiabilidade, controle e cincia da computao, e uma variedade de propostas tem surgido, dentre as quais destacam-se os mtodos
utilizando rvores de falhas e as metodologias que usam bases de conhecimento extradas dos operadores do processo e dos dados obtidos
do processo real (ISERMAN, 1997). Nessas metodologias, a deteco de
falhas podem ser feitas por gerao de sintomas analticos, heursticos e
diagnstico de falhas. Na gerao de sintomas analticos, os dados coletados do processo so usados para produzir informao quantificvel e
analisvel. Os sintomas heursticos, que normalmente so representados
por variveis lingustica tais como: pequeno, mdio, grande, quente, frio,
etc., podem ser obtidos dos operadores da planta ou processo, por intermdio de observaes humanas, inspees, valores caractersticos heursticos tais como tipos de rudos, cores, vibraes, etc. J o diagnstico
de falhas consiste em determinar o tipo, tamanho e lugar da falha baseado nos sintomas analticos e heursticos observados (RIVIERA, 2007).
Diferentemente destas metodologias baseadas em bases de conhecimento, mtodos de deteco de falhas baseados em modelos matemticos tambm tm sido desenvolvidos nas ltimas trs dcadas, dentre os quais podemos citar os propostos por Himmelblau (1978), Iserman
(1997), Sampath et al. (1995). Nos trabalhos de Iserman (1997) e Himmelblau (1978) so descritos os principais mtodos de deteco e diagnstico de falhas baseados em modelos, dos quais se destacam:
30
Captulo 1. Introduo
i) Deteco de falhas com estimao de parmetros e observadores

(Filtro de Kalman).
ii) Diagnstico de falhas usando mtodos de classificao e reconhecimento de padres, atravs de classificao geomtrica e estatstica.
iii) Reconhecimento de padres com redes neurais e classificao com
clusterizao fuzzy (HALGAMUGE, 1996).
iv) Diagnstico de falhas usando mtodos de inferncia com aproximaes feitas por anlise de rvores de falha (FTA, fault-tree analysis),
anlises de eventos falha (ETA, event-tree analysis)
v) Inteligncia artificial, redes bayesianas e lgica Fuzzy (TEIXEIRA,
1993; KASZKUREWICZ et al., 1997).
vi) Diagnstico de falhas com abordagem de sistemas hbridos (JIROVEANU et al., 2006).
vii) Diagnstico de falhas usando Sistemas a Eventos Discretos (SAMPATH et al., 1995; LAFORTUNE et al., 2001).
No contexto de Sistemas a Eventos Discretos (SEDs) podemos

destacar os trabalhos de Lin (1994), Sampath et al. (1995), Sampath et al.
(1996), Debouk et al. (2000), Jiang et al. (2001), Lafortune et al. (2001),
Zad et al. (2003), Qiu e Kumar (2005), Wang et al. (2007), Baslio e Lafortune (2009), Baslio et al. (2010), Athanasopoulou et al. (2010), Carvalho et al. (2010), Carvalho et al. (2013) e Lin et al. (2013). O trabalho
apresentado por Lin et al.(1994) trouxe pela primeira vez a temtica de
diagnstico de falhas no contexto de Sistemas a Eventos Discretos, onde
os conceitos sobre capacidade de diagnosticar uma falha no sistema foram introduzidos. Posteriormente nos trabalhos de Sampath et al. (1995)
e Sampath et al. (1996), os autores apresentam uma metodologia para a
modelagem de sistemas fsicos como sistema a eventos discretos, introduzem o conceito de mapeamento de sensores, apresentam a definio
31
de diagnosticabilidade de linguagens geradas por SEDs e um procedimento para a construo de diagnosticadores de falhas e, por fim, do as
condies necessrias e suficientes para diagnosticabilidade (RIVIERA,
2007). O diagnstico de falhas estima a ocorrncia da falha a partir de
sequncias de eventos parcialmente observadas, atravs de observadores modificados denominados diagnosticadores. Ainda nos trabalhos de
Sampath et al. (1995; 1996), para diagnstico de falhas em SEDs o diagnosticador proposto com duas finalidades (MOREIRA et al., 2010):
i) deteco online e isolao de falhas de um sistema e;
ii) verificao offline das propriedades de diagnosticabilidade de um sistema.
Outros trabalhos usando sistemas modelados por autmatos foram feitos por Lunze e Schrder (2004), onde visualizaram o problema
de diagnstico como um problema de observao, por intermdio de uma
abordagem hbrida usando autmatos estocsticos (RIVIERA, 2007). Um
autmato estocstico um autmato ao qual adicionada uma estrutura probabilstica para estimar a probabilidade de ocorrncia de eventos
especficos (BASILIO, CARVALHO e MOREIRA, 2010).
De acordo com Baslio et al. (2010), as metodologias desenvolvidas para o diagnstico de falhas em SEDs podem ser aplicadas no
apenas para sistemas onde o modelo de eventos discretos o mais adequado (como redes de comunicao, sistemas computacionais e sistemas de produo), mas tambm em muitos sistemas dinmicos de variveis contnuas, uma vez que esses sistemas, considerando um nvel
maior de abstrao, tambm podem ser modelados como SEDs, o que
torna essa abordagem ainda mais ampla e relevante.
Uma vez que a ocorrncia da falha no pode ser registada pelos
sensores deve-se consider-la como um evento no observvel no modelo do sistema. O diagnosticador um autmato, onde cada estado
constitudo por um conjunto de estados do sistema que representam uma
32
Captulo 1. Introduo
estimativa do estado atual do sistema baseado apenas na ocorrncia dos

eventos observveis (que podem registrados por sensores) e tm marcaes que indicam se a sequncia de eventos observveis que ocorreram
tem ou no o evento de falha (LIMA, 2010). Assim em um sistema fsico
modelado como SED, se presume que os sensores sempre podero informar a ocorrncia dos eventos associados a eles. Porm, um mau funcionamento dos sensores pode causar a perda da observabilidade desses
eventos, o que prejudicaria o diagnstico de falhas. Rohloff (2005) aborda
o problema de controle tolerante a falha e prope um teste para verificar
a existncia de um controle supervisrio (RAMADGE e WONHAM, 1989)
para o caso de sistemas sujeitos a falhas permanentes de sensores. Lima
et al. (2010a) tambm abordam este problema e propem um diagnosticador robusto perda permanente de sensores e ainda Carvalho et al.
(2010) propem duas estratgias sistemticas para diagnstico de falhas
em sistemas sujeitos a perda intermitente de sensores. Uma vez que o diagnstico de falhas feito considerando apenas os eventos observveis,
seria possvel determinar um conjunto mnimo destes eventos que seriam
realmente relevantes para a realizao do diagnstico? Uma soluo para
esta questo apresentada nos trabalhos de Lima et al. (2010b) e Basilio
et al. (2012), onde em ambos so apresentados os fundamentos tericos
necessrios para o desenvolvimento de um algoritmo de busca capaz de
encontrar todos os subconjuntos do conjunto de eventos observveis (denominada base para diagnstico), que so necessrios para diagnosticar
a ocorrncia da falha.
Esta dissertao fornece uma base terica para o estudo e pesquisa sobre diagnstico de falhas em Sistemas a Eventos Discretos Modelados por autmatos, tanto para o diagnstico centralizado como o diagnstico descentralizado com a coordenao (co-diagnose). A principal
contribuio deste trabalho a proposta de uma arquitetura para diagnstico de falhas em sistemas embarcados modelados a eventos discretos.
Nesta arquitetura considera-se o sistema dividido em camadas, para as
quais os diagnosticadores so especificamente projetados a fim de obter
um diagnstico mais preciso, que possibilite uma ao de recuperao ou
33
isolao da falha mais eficaz, quando necessrio. Para tanto, so consideradas as seguintes camadas:
i) camada de Software: Relacionada s rotinas de software (controle e
sistema)
ii) camada de Hardware: Relacionada aos circuitos e componentes da
placa eletrnica
iii) camada de Cargas: Relacionada s cargas e/ou atuadores externos
A segunda contribuio deste trabalho uma proposta de implementao em software desses diagnosticadores, utilizando a linguagem
C ANSI (KERNIGHAN e RITCHIE, 1988) e tambm o desenvolvimento
de uma ferramenta para a gerao automtica deste software.
Uma terceira contribuio deste trabalho um estudo de caso
para um refrigerador Frost Free, onde diagnosticadores para as trs camadas (software, hardware e cargas) foram modelados, implementados
em software e embarcados no microcontrolador da placa de controle do
refrigerador.
Este trabalho est estruturado da seguinte maneira. O captulo
2 apresenta uma reviso terica dos conceitos relevantes para o estudo
de diagnstico de falhas em SEDs, define os conceitos de diagnosticabilidade, apresenta as condies necessrias e suficientes para o diagnstico, apresenta a metodologia para construo de diagnosticadores tanto
para o caso de diagnose centralizada como descentralizada (com coordenao). O Captulo 3 apresenta a proposta de arquitetura de diagnstico
para sistemas embarcados onde os diagnosticadores projetados segundo
a teoria apresentada no captulo anterior podem ser empregados. O captulo 4 mostra os detalhes do projeto dos diagnosticadores propostos
para um caso real em um refrigerador Frost Free. J o captulo 5 mostra
os detalhes da implementao em software dos diagnosticadores obtidos
no captulo anterior a apresenta a ferramenta criada para a gerao automtica deste software. Por fim, o captulo 6 mostra como foi testado e
34
Captulo 1. Introduo
validado os diagnosticadores aps serem embarcados no microcontrolador junto ao software principal de controle do refrigerador. Concluses,
discusses e propostas para trabalhos futuros so apresentados no captulo 7.
35
2 FUNDAMENTOS TERICOS DE DIAGNOSE DE FALHAS EM SEDS
O objetivo deste captulo dar subsdios para o entendimento

dos formalismos tericos aplicados nos captulos seguintes. Para isso
ser feita uma breve reviso terica dos conceitos fundamentais necessrios para o estudo da diagnose de falhas em Sistemas a Eventos Discretos (SEDs), tais como linguagens e autmatos, autmato determinstico e
no-determinstico, projeo e projeo inversa de linguagens, SEDs parcialmente observadas e observadores. Tambm sero revistos os principais conceitos e resultados mais relevantes da teoria de Sistemas a
Eventos Discretos (SEDs) aplicados diagnose de falhas.
2.1
Sistemas a Eventos Discretos

Denominam-se Sistemas a Eventos Discretos (SEDs), sistemas
dinmicos cujo estados podem ser representados de maneira discreta

e a transio destes estados se d atravs de eventos. Um estado discreto significa que o mesmo pode assumir valores simblicos, como por
exemplo: {ligado, desligado}, {aberto, fechado}, {alto, mdio, baixo} ou valores numricos, como por exemplo: {0, 1, 2, . . . }. J os eventos, geralmente esto associados a aes especficas, como por exemplo fechar
uma chave, atingir um faixa de temperatura ou pode ainda ser o resultado
de duas ou mais condies que so satisfeitas, como por exemplo uma
chave ficou fechada por mais de um determinado tempo, uma temperatura no foi alcanada aps um determinado tempo de uma resistncia
ligada, etc. Todas as sequncias de eventos possveis de serem geradas
por um SED caracterizam a linguagem desse SED, sendo esta definida
sobre o conjunto de eventos (alfabeto) do sistema. Embora alguns sistemas sejam naturalmente discretos e com a evoluo determinada pela
ocorrncia de eventos, com um certo grau de abstrao, possvel modelar qualquer sistema fsico como um SED, desde que este modelo seja
36
Captulo 2. Fundamentos tericos de diagnose de falhas em SEDs
capaz de reproduzir, dentro de limites de tolerncia pr-estabelecidos, o

comportamento do sistema (BASILIO et al. 2010).
2.2
2.2.1
Linguagens e Autmatos Determinsticos de Estados Finitos

Linguagens
Todo SED possui um conjunto de eventos a ele associado.
Esse conjunto pode ser interpretado como o alfabeto de uma linguagem,

onde as possveis sequncias formadas por elementos desse conjunto
podem ser interpretadas como palavras de uma linguagem sobre o alfabeto. Uma sequncia que no possui eventos formada pela sequncia
vazia . Assim, possvel utilizar linguagens para modelar o comportamento de um SED. Formalmente, o conceito de linguagem definido
como segue (HOPCROFT et al., 2007):
Definio 1. (Linguagem) Uma linguagem definida sobre um conjunto de
eventos um conjunto formado por sequncias de comprimento finito
construdas a partir de eventos pertencentes a .
Para ilustrar a definio acima, suponha o seguinte conjunto de
eventos = {a, b, c}. Pode-se definir a linguagem L1 = {, ab, abab}, formada por trs sequncias apenas; a linguagem L2 = {ca, cb, cc}, formada por todas as possveis sequncias de tamanho 2 que iniciam com
o evento c.
Algumas operaes podem ser definidas sobre o conjunto de
eventos ou sobre sequncias, uma delas o Fecho de Kleene de um
conjunto , denotado por , que define o conjunto de todas as sequncias finitas formadas por elementos de , incluindo a sequncia vazia .
Assim, um conjunto infinito, uma vez que contm sequncias arbitrariamente longas. Se = {a, b, c} ento = {, a, b, c, aa, ab, ac, ba, bb,
bc, ca, cb, cc, aaa, . . .}. Formalmente, define-se o Fecho de Kleene como
(CASSANDRAS e LAFORTUNE, 2008, p. 56):
2.2. Linguagens e Autmatos Determinsticos de Estados Finitos
37
Definio 2. (Fecho de Kleene) Seja L , ento o Fecho de Kleene

de L denotado por L , definido como:
L := {} L LL LLL . . .
(2.1)
A operao de concatenao, consiste em unir duas ou mais

sequncias para formar uma nova sequncia. Por exemplo, para o conjunto anteriormente definido, a sequncia ab a concatenao dos
eventos a e b. A sequncia vazia o elemento identidade da concatenao, sendo s = s = s para qualquer sequncia s. Formalmente o
operao de concatenao definida como segue (CASSANDRAS e LAFORTUNE, 2008, p. 56):
Definio 3. (Concatenao) Sejam L1 , L2 , ento a concatenao
L1 L2 definida como:
L1 L2 := {s : (s = s1 s2 )[s1 L1 e s2 L2 ]}
(2.2)
Outras duas operaes definidas sobre linguagens so as operaes de prefixo fechamento e ps linguagem, cujas definies so apresentadas a seguir (CASSANDRAS e LAFORTUNE, 2008, p. 56):
Definio 4. (Prefixo Fechamento) Seja L , ento o prefixo fechamento de L, denotado por L definido como:
L := {s : (t )[st L]}
(2.3)
Se L = L, diz-se que a linguagem L prefixo-fechada.

Definio 5. (Ps Linguagem) Seja L e s L , ento a ps linguagem de L aps s, denotada por L/s, a linguagem:
L/s := {t : st L)}
(2.4)
Outra operao bastante til sobre linguagens e cujo conceito

tem bastante relevncia para o estudo de diagnose de falhas em SEDs
38
a projeo de linguagens (RAMADGE e WONHAM, 1989; CASSANDRAS

e LAFORTUNE, 2008). Quando aplicada a uma sequncia de eventos,
a projeo permite manter apenas o conjunto de eventos selecionados
(eventos observveis, por exemplo) desta sequncia e apagar os demais
(no observveis, por exemplo). Formalmente definida como:
Definio 6. (Projeo) Seja e o conjuntos de eventos, onde o .
A projeo Po de uma sequncia de eventos em o definida como:
Po : o
(2.5)
com as seguintes propriedades:
Po ()
:= (,
Po ( )
:=
se o ,
se \o ,
(2.6)
Po (s ) := Po (s)Po ( ), para s , e
onde \ denota a diferena entre conjuntos. Assim a operao \o =
o , isto , o conjunto formado pelos elementos de que no pertencem ao conjunto o .
O operador projeo pode ser estendido para uma linguagem L

aplicando as definies mostradas acima a todas as sequncias pertinentes linguagem L (CARVALHO, 2011). Assim, se L ento:
Po (L) := {t o : (s L) [Po (s) = t]}
(2.7)
O tipo de projeo apresentada na Definio 6 denominada projeo

natural. Pode-se tambm definir a projeo inversa Po1 de uma sequncia, como segue:
39
Definio 7. (Projeo Inversa) A projeo inversa de uma sequncia de

eventos definida como uma funo
Po1 : o 2
Po1 (t) := {s : Po (s) = t}
(2.8)
Em outras palavras, a Definio 7 implica que para uma dada

sequncia formada pelos eventos pertencentes ao conjunto de menor
cardinalidade o , a projeo inversa retornar o conjunto de todas as
sequncias formadas por eventos pertencentes ao conjunto de maior cardinalidade , onde as projees sero a prpria sequncia inicial (LIMA,
2010).
Assim como em (2.7), a projeo inversa tambm pode ser estendida para linguagens de modo que para L o , tem-se:
Po1 (Lo ) := {s : (t Lo )[Po (s) = t]}
(2.9)
Para ilustrar o conceito de projeo, considere o exemplo a seguir.
Exemplo 1. Seja s = {a, b, c}, e seus respectivos subconjuntos 1 =
{a, b} e 2 = {a, c} e tambm a linguagem L = {c, ccb, bca, cabbc, abcbca}

s . Para as duas projees Pi (L) : s i , i = 1,2 tem-se que:
P1 (L) = {,b, ba, abb, abba}

P2 (L) = {c, cc, ca, cac, acca}
P11 ({}) = {c}
P11 ({b}) = {c} {b} {c}
P11 ({a, b}) = {c} {a} {c} {b} {c}
40
Dada a importncia das projees naturais no estudo de diagnose de falhas de SEDs, seguem algumas propriedades relevantes que
auxiliaro o entendimento deste trabalho.
Propriedades de Projees Naturais (CASSANDRAS e LAFORTUNE,
2008, p. 58):
1. P[P1 (L)] = L
L P1 [P(L)]
2. Se A B ento P(A) P(B) e P1 (A) P1 (B)
3. P(A B) = P(A) P(B)
P(A B) P(A) P(B)

4. P1 (A B) = P1 (A) P1 (B)
P1 (A B) = P1 (A) P1 (B)
5. P(AB) = P(A)P(B)
P1 (AB) = P1 (A)P1 (B)
2.2.2
Autmatos Determinsticos de Estados Finitos

Neste trabalho os SEDs considerados sero modelados usando
autmatos de estados finitos, tambm chamados de mquinas de estados de estados finitos. Por simplicidade, ao longo do trabalho utiliza-se
apenas o termo autmato para se referir a autmato de estados finitos.
Um autmato um dispositivo capaz de representar uma linguagem atravs de regras bem definidas. Segundo Cassandras e Lafortune
(2008) um autmato determinstico formalmente definido como segue:
Definio 8. (Autmato Determinstico) Um autmato determinstico, denotado por G, definido pela seguinte sxtupla:
G = (X, , f , , x0 , Xm ),
(2.10)
41
no qual:
X denota o espao de estados;

o conjunto de eventos;
f : X X a funo de transio de estados;
: X 2 a funo dos eventos ativos;

x0 o estado inicial;
Xm X o conjunto de estados marcados
Diz-se que o autmato determinstico pois f uma funo de
X para X , ou seja, a ocorrncia de um evento leva o autmato de

seu estado atual para um nico estado futuro. Em outras palavras, no
possvel haver mais do que uma transio rotulada pelo mesmo evento
saindo de um mesmo estado do autmato. J em um autmato nodeterminstico, f uma funo de X para 2X . Nesse caso, podem
haver diversas transies rotuladas pelo mesmo evento saindo de um
mesmo estado, isto , um mesmo evento pode levar o autmato de seu
estado atual para mais de um estado futuro (CASSANDRAS e LAFORTUNE, 2008). O conceito de autmato no-determinstico ser detalhado
posteriormente na seo 2.3.
Para o conjunto de eventos , denota o conjunto de todas as
sequncias possveis de comprimento finito com elementos pertencentes
a , incluindo a sequncia vazia . Por convenincia, f sempre estendida do domnio X para o domnio X , da seguinte maneira
recursiva (CASSANDRAS e LAFORTUNE, 2008):
f (x,) := x
f (x,s ) :=
f [ f (x,s), ] para s e
(2.11)
O autmato tal como descrito na Definio 8 pode ser representado graficamente por meio de um diagrama de transio de estados,
onde os estados so representados por ns circulares, as transies por
arcos rotulados pelos eventos. O estado inicial identificado por uma seta
42
e os estados marcados so representados por crculos duplos concntricos. A Figura 2.1 mostra um exemplo de um autmato onde possvel
verificar os conceitos acima descritos.
Figura 2.1: Exemplo de um Diagrama de Transio de Estados para um
Autmato
Fonte: Autor
O grafo da Figura 2.1, representa o diagrama de transio de

estados de um autmato do tipo G = (X, , f , , x0 , Xm ), onde:
X = {1, 2, 3};
= {a, b, c};
Xm = {2};
x0 = 1;
f (1, a) = 2, f (1, b) = 3, f (3, a) = 1, f (3, c) = 2, f (2, b) = 2;
(1) = {a, b}, (2) = {b}, (3) = {a, c}
Quando um evento ocorre em um autmato e o estado destino

o prprio estado de origem, ou seja, o evento no gera a mudana de
estado, diz-se que o estado possui um auto-lao. Esta condio pode ser
vista do estado 2 do autmato da Figura 2.1. Por outro lado, quando um
estado no possui nenhum evento ativo, o denominamos como um estado
de bloqueio ou deadlock.
43
A relao entre linguagens e autmatos pode facilmente ser identificada analisando-se o diagrama de transio de estados de um autmato. O conjunto de todas as sequncias de eventos possveis de serem
executadas a partir do estado inicial forma a linguagem gerada por um
autmato. J o conjunto de sequncias pertencentes linguagem gerada
que levam o sistema a um estado marcado constitui a linguagem marcada
por um autmato. Normalmente, a linguagem marcada est relacionada
com a linguagem de interesse de um autmato, podendo representar, por
exemplo, o fim de uma tarefa, ou a disponibilidade de um recurso do sistema. As definies formais so apresentadas a seguir (CASSANDRAS
e LAFORTUNE, 2008):
Definio 9. (Linguagens gerada e marcada) A linguagem gerada por
G = (X, , f , , x0 , Xm ) definida como:

L(G) := {s : f (x0 , s) definida}.
(2.12)
A linguagem marcada por G definida como:
Lm (G) := {s L(G) : f (x0 , s) Xm }.
(2.13)
O exemplo a seguir ilustra a determinao das linguagens gerada

e marcada por um autmato.
Exemplo 2. Seja o autmato da Figura 2.2, onde = {a, b, c}. A linguagem gerada por G L(G) = {{a, b}{c}{a}} , enquanto que a linguagem
marcada por G Lm (G) = {{a, b}{c}{{a}{a, b}{c}} }
2.2.3
Operaes com Autmatos

Algumas operaes com autmatos so definidas para que se
possa modificar, combinar ou compor dois ou mais autmatos, para assim se obter uma melhor representao de um sistema completo a partir
de modelos de componentes individuais do sistema. Algumas destas principais operaes que so relevantes para o estudo de diagnose de falhas
44
Figura 2.2: Autmato para o Exemplo 2
Fonte: Autor
em sistemas a eventos discretos so apresentadas a seguir (CASSANDRAS e LAFORTUNE, 2008).

Definio 10. (Parte Acessvel) A parte acessvel de um autmato G a
operao unria que elimina todos os estados de G que no so alcanveis a partir do estado inicial x0 , assim como as transies relacionadas
com esses estados eliminados. Seja G = (X, , f , , x0 , Xm ), formalmente
define-se a parte acessvel de G, denotada por Ac(G) como o subautmato:
Ac(G) = {Xac , , fac , x0 , Xac,m }.
(2.14)
sendo,
Xac
Xac,m
fac
= {x X : (s )[ f (x0 , s) = x]};
= Xm Xac ;
:
(2.15)
Xac Xac ;
onde fac denota a nova funo de transio obtida restringindo-se o domnio de f para o domnio dos estados acessveis Xac .
Definio 11. (Parte Coacessvel) Parte coacessvel de um autmato G
uma operao unria e obtida eliminando-se todos os estados de
G a partir dos quais no possvel alcanar um estado marcado. Seja

G = (X, , f , , x0 , Xm ). Formalmente define-se a parte coacessvel de G,
45
denotada por CoAc(G) como o subautmato:
CoAc(G) = {Xcoac , , fcoac , x0,coac , Xm }.
(2.16)
sendo,
Xcoac
x0,coac
fcoac
= {x
( X : (s )[ f (x, s) Xm ]}
x0 ,
se x0 Xcoac ,
=
indefinido, se x0
/ Xcoac
Xcoac Xcoac
onde fcoac denota a nova funo de transio obtida restringindo-se o

domnio de f aos estados coacessveis Xcoac .
Alm das duas operaes unrias acima descritas, possvel
fazer a composio de dois ou mais autmatos e assim obter um novo
autmato. Para isso, pode-se usar as operaes de produto ou composio paralela definidas a seguir (CASSANDRAS e LAFORTUNE, 2008).
Definio 12. (Produto) Sejam os autmatos G1 = (X1 , 1 , f1 , 1 , x01 , Xm1 )
e G2 = (X2 , 2 , f2 , 2 , x02 , Xm2 ). Ento, o produto de G1 e G2 , denotado por
G1 G2 formalmente definido como:

G1 G2 = Ac(X1 X2 , 1 2 , f12 , (x01 , x02 ), Xm1 Xm2 )
(2.17)
sendo,
(
f12 ((x1 , x2 ), ) =
( f1 (x1 , ), f2 (x2 , )), se 1 (x1 ) 2 (x2 );

indefinido, caso contrrio
A definio acima implica que qualquer transio de estados no

produto G1 G2 ocorre se, e somente se, essa transio possvel em
ambos autmatos G1 e G2 . Ou seja, a evoluo de estados em G1 G2
completamente sincronizada com a evoluo de estados dos autmatos
G1 e G2 .
Conforme visto acima a composio por produto restritiva, pois
s permite transies em eventos comuns. Contudo, essa operao no
46
muito adequada quando se modela sistemas compostos por componentes que interagem entre si, onde o conjunto de eventos de cada componente inclui eventos particulares (que pertencem ao seu prprio comportamento interno) e eventos comuns que so compartilhados com outros
autmatos e captam a conexo entre os respectivos componentes do sistema. A forma adequada para construo de modelos de sistemas inteiros a partir de modelos de componentes individuais do sistema por meio
da composio paralela (CASSANDRAS e LAFORTUNE, 2008), cuja definio mostrada a seguir.
Definio 13. (Composio Paralela) Sejam os autmatos:
G1 = (X1 , 1 , f1 , 1 , x01 , Xm1 ) e G2 = (X2 , 2 , f2 , 2 , x02 , Xm2 ).

Ento, a composio paralela de G1 e G2 , denotada por G1 k G2 formalmente definido como:
G1 k G2 = Ac(X1 X2 , 1 2 , f1k2 , (x01 , x02 ), Xm1 Xm2 )
(2.18)
de modo que:
f1k2 : (X1 X2 ) (1 2 ) (X1 X2 )
ou seja:
f1k2 ((x1 , x2 ), ) =
( f1 (x1 , ), f2 (x2 , )), se 1 2 e
1 (x1 ) 2 (x2 );
( f1 (x1 , ), x2 ), se 1 e
/ 2 e 1 (x1 );
(x1 , f2 (x2 , )), se 2 e

/ 1 e 1 (x1 );
indefinida, caso contrrio
Na composio paralela um evento comum, isto , um evento em
1 2 , apenas pode ser executado se os dois autmatos execut-lo simultaneamente. Assim, os dois autmatos esto sincronizados nos eventos comuns. J os eventos particulares, isto , aqueles onde (2 \1 )
(1 \2 ), no esto sujeitas a essa restrio e podem ser executados
2.3. Autmatos No-Determinsticos
47
sempre que possvel. Neste tipo de interconexo, um componente pode

executar seus eventos particulares sem a participao do outro componente, contudo um evento comum s pode acontecer se ambos os componentes podem execut-lo (CASSANDRAS e LAFORTUNE, 2008).
2.3
Autmatos No-Determinsticos
No autmato determinstico definido na seo 2.2.2, o estado ini-
cial um estado nico e um evento causa uma transio de x para

um nico estado y = f (x, ). Contudo, possvel que um evento no estado x cause uma transio para mais de um estado, isso pode ocorrer por
exemplo devido falta de informao do sistema modelado, onde o efeito
de um evento no perfeitamente conhecido, no sendo possvel ento
precisar o estado futuro. Outra possibilidade, a necessidade de se agrupar alguns estados do autmato o que resultaria em mltiplas transies
todas com o mesmo rtulo saindo do mesmo estado (agora agrupado
em um s). Nesse caso, f (x, ) no representar mais um nico estado
mas sim um conjunto de estados. Tem-se ainda a possibilidade de estar presente no diagrama de transio de estados de um autmato, ou
seja, alguns estados podem estar conectados por transies rotuladas
pela sequncia vazia denominadas de transies- . Essas transies podem representar, por exemplo, eventos que causam mudanas no estado
de um SED, porm a ocorrncia de tais eventos no so percebidos por
um observador externo. Isso pode ocorrer por exemplo devido falta de
sensores capazes de registrar esses eventos (CASSANDRAS e LAFORTUNE, 2008). Considerando essas possibilidades, define-se uma classe
denominada autmato no-determinstico, cuja representao formal
apresentada a seguir (CASSANDRAS e LAFORTUNE, 2008, p.70):
Definio 14. (Autmato No-Determinstico): Um autmato no-determinstico definido pela sxtupla:
Gnd = (X, {}, fnd ,,x0 ,Xm ),

S
48
em que os parmetros possuem a mesma interpretao dada na definio do autmato determinstico, com apenas duas ressalvas:
i) fnd uma funo fnd : X {} 2X , ou seja, fnd (x, ) X sempre

que for definida, sendo 2X o conjunto de subconjuntos de X , tambm
denominado conjunto das partes de X (CURY, 2001).
ii) O estado inicial pode ser um conjunto de estados, ou seja, xo X .
Para ilustrar esses conceitos, seguem dois exemplos de autmatos no-determinsticos.

Exemplo 3. Autmato no-determinstico simples: Considere o autmato
mostrado na Figura 2.3a. Quando o evento a ocorre no estado 0, existem
duas transies possveis, para o estado 1 e para o estado 2. Assim, aps
a ocorrncia do evento a no possvel determinar com exatido qual o
estado atual do autmato. As transies de estados mapeadas para esse
autmato so: fnd (0, a) = {1, 2}, fnd (1, b) = {0} e fnd (2, c) = {1}, onde
os valores de fnd so expressados como subconjuntos do conjunto de
estados X . As transies fnd (0, b), fnd (1, a) e fnd (2, a) no so definidas.
Exemplo 4. Autmato no-determisnstico com transio- : Considere
agora o autmato mostrado na Figura 2.3b que inclui uma transio- .
Temos que: fnd (1, ) = {2}, fnd (2, b) = {2, 3}, fnd (2, a) = {1} e fnd (3, c) =
{2}. Como se pode observar, a ocorrncia do evento b no estado 2 pode

levar o autmato tanto para o estado 3 como faz-lo permanecer no prprio estado 2. Suponha que imediatamente aps se ligar o sistema se
observe a ocorrncia do evento a, a transio fnd (1, a) no definida,
assim se pode concluir que ocorreu uma transio do estado 1 para o
estado 2 seguida do evento a, fazendo o sistema retornar para o estado
1. A transio do estado 1 para o estado 2, sem que esta tenha sido
observada devida transio-
2.3. Autmatos No-Determinsticos
49
Figura 2.3: (a) Autmato no-determinstico do exemplo 3; (b)Autmato

no-determinstico com transio- do exemplo 4
(a)
(b)
Fonte: Autor
Pode-se estender fnd para uma sequncia u, em vez de aplic-la

apenas a um nico evento, como foi feito para f no caso de autmatos
determinsticos. Em particular:
fnd (x,u ) := {z : z fnd (y, ) para algum estado y fnd (x,u)}
(2.19)
Ou seja, aps a ocorrncia da sequncia u, todos os estados y

que so acessveis a partir de x so identificados e assim, pela ocorrncia
do evento , chega-se ao estado z que pertence ao conjunto fnd (x,u ).
A linguagem que pode ser gerada e marcada por um autmato
no-determinstico definida como (CASSANDRAS e LAFORTUNE, 2008):
L(Gnd ) = {s : (x x0 )[ fnd (x,s) definida]}

Lm (Gnd ) = {s L(Gnd ) : (x x0 )[ fnd (x,s) Xm 6= 0}
/
Conforme Cassandras e Lafortune (2008, p.72), as definies
acima possuem o seguinte significado: Uma sequncia pertence a uma
50
linguagem gerada por um autmato no-determinstico se no diagrama

de transio de estados existe um caminho que consistentemente rotulado por esta sequncia. Se possvel seguir este caminho e este termina
em um estado marcado, ento essa sequncia est contida na linguagem
marcada pelo autmato.
2.4
SEDs Parcialmente Observados

Conforme mencionado anteriormente, em um autmato no- de-
terminstico as transies definidas por representam eventos que ocorrem no sistema modelado mas que no podem ser registrados ou observados. Essa falta de observabilidade pode ocorrer, por exemplo, devido
falta de sensores capazes de registrar tais eventos ou por estes eventos
ocorrerem em uma parte remota que no se comunica com o sistema
modelado.
Se considerarmos o conjunto de eventos composto por dois
subconjuntos disjuntos, o referente ao conjunto de eventos observveis e uo , referente ao conjunto de eventos no observveis, isto =
uo , ento em um autmato onde uo = 0/ , ou seja, o conjunto de eveno

tos composto apenas por eventos observveis (o ), a ocorrncia de
um evento causa a transio do autmato de um estado x conhecido
para um estado y tambm conhecido. No entanto, quando consideramos
uo 6= 0/ , isto , o conjunto agora possui eventos no observveis, teremos uma indeterminao quanto ao estado atual do autmato, devido
no observao dos eventos pertencentes ao subconjunto uo . Na Figura
2.4 mostrado um autmato que ilustra essa possibilidade. Considerando
que o evento a no pode ser observado, ento, aps a ocorrncia (observao) do evento b no ser possvel determinar com exatido o estado
atual do sistema (autmato), uma vez que haver trs estados possveis,
os estados 2, 4 e 5.
Neste contexto, eventos de falha que no causam mudanas
nos sensores podem ser tambm considerados como eventos no observveis. Ento, se ao invs de simplesmente rotularmos esses eventos
2.4. SEDs Parcialmente Observados
51
Figura 2.4: Autmato determinstico para o evento a no observvel
Fonte: Autor
no observveis como sequncias vazias e obter um autmato nodeterminstico, rotularmos essas transies como eventos genunos, porm classificar esses eventos como no observveis, obteremos assim
um autmato determinstico, onde o conjunto de eventos composto
pelos subconjuntos o e uo . Nestas condies, o SED pode ser denominado como "parcialmente observado"(CASSANDRAS e LAFORTUNE,
2008, p.102).
Um autmato determinstico com eventos no observveis que
representa um SED parcialmente observado, definido como:
G = (X,, f ,,x0 ,Xm ),
(2.20)
uo , sendo
a partio de um conjunto, i.e. o uo =
onde, = o
0/ e o uo = .
52
2.5
Observador
O autmato determinstico que descreve o comportamento din-
mico de um autmato determinstico com eventos no observveis, mencionado anteriormente, chamado observador. O conjunto de eventos do
observador formado apenas pelos eventos observveis e seu estado
atual representa uma estimativa do estado atual do autmato parcialmente observado, atualizado aps a ocorrncia de um evento observvel.
O observador de G, denotado como Obs(G) definido da seguinte forma:
Obs(G) = (Xobs ,o , fobs ,obs ,x0obs ,Xmobs ),
(2.21)
onde Xobs 2X e Xmobs = {B Xobs : B Xm 6= 0}

/ .
Um algoritmo para a construo de observadores para autmatos parcialmente observados, proposto por Basilio et al. (2010, p. 517)
apresentado a seguir. Contudo, esse algoritmo requer a noo de alcance no observvel, denotado por UR(x), cuja definio apresentada
a seguir (CASSANDRAS e LAFORTUNE, 2008, p.102):
Seja G = (X, o uo , f , x0 , Xm ) um autmato parcialmente observado. Para cada estado x X define-se:
UR(x) := {y X : (t uo )[ f (x,t) = y]}

A definio acima estendida para um conjunto de estados B
X , da seguinte maneira:
UR(B) =
UR(x)
xB
Ento Obs(G) = (Xobs , o , fobs , x0obs , Xm,obs ) pode ser construdo

atravs do algoritmo a seguir (BASILIO et al., 2010, p. 517):
2.5. Observador
53
Algoritmo 1. (Construo de Observadores):

Passo 1: Defina x0obs = UR(x0 ) e faa: Xobs = {xobs } e Xobs = Xobs
Passo 2: Xobs = Xobs e Xobs = 0/
Passo 3: Para cada B Xobs
obs (B) = (
xB (x)) o ,
Para cada e obs (B),

fobs (B, e) = UR({x X : (y B)[x = f (y,e)]});
Xobs Xobs fobs (B,e)
Passo 4: Xobs Xobs Xobs
Passo 5: Repita os passos 2 a 4 at que toda a parte acessvel de
Obs(G) tenha sido construda.

Passo 6: Xmobs = {B Xobs : B Xm 6= 0}
/
O objetivo desse algoritmo calcular o alcance no-observvel
para cada estado de G alcanado por um evento observvel. Para isso,
calcula-se no primeiro passo o alcance no-observvel do estado inicial
x0 para formar ento o primeiro estado do observador. No passo 3, so

calculados os conjuntos de eventos ativos dos estados do observador obtidos no passo ou na iterao anterior (sendo que o primeiro se refere ao
alcance observvel do estado inicial e o ltimo aos estados de G alcanados por meio de eventos observveis juntamente com os respectivos
alcances no-observveis). Posteriormente so calculados os prximos
estados do observador, que correspondem aos alcances no observveis
dos estados de G alcanados a partir do estado atual do observador por
meio de eventos observveis. Essa sequncia repetida at que todos
os estados acessveis do observador tenham sido encontrados (BASILIO
et al., 2010).
A partir do Algoritmo 1 e da definio de projeo de linguagens
da Equao 2.7, pode-se concluir que L(Obs(G)) = Po [L(G)], ou, em outras palavras, a linguagem gerada por Obs(G) a projeo da linguagem
de G sobre um conjunto de eventos observveis (BASILIO et al., 2010).
Exemplo 5. Para melhor ilustrar a construo de observadores, consi-
54
dere o autmato parcialmente observado da Figura 2.5a, com um con-
uo definido por: = {a, b, c, d, f , }, o =

junto de eventos = o
{a, b, c, d}, e uo = { f , } Aplicando o algoritmo 1, obtm-se o observador Gobs = Obs(G), mostrado na Figura 2.5b, como segue:
i) x0obs = UR(x0 ) = {1}, Xobs = {{1}} e Xobs = {{1}}
ii) Xobs = {{1}} e Xobs = 0/
iii) obs ({1}) = {a,b},
fobs ({1}, a) = UR({4}) = {4,3},

fobs ({1}, b) = UR({2}) = {4,2,3}, e Xobs = {{4,3},{4,2,3}};
iv) Xobs = {{1},{4,3}, {4,2,3}};
Retorne ao passo 2 at que toda parte acessvel de Gobs tenha

sido construda.
2.6
Diagnosticabilidade
O conceito de diagnosticabilidade refere-se capacidade de de-
tectar qualquer falha em um sistema com um atraso finito, com base apenas na ocorrncia de eventos observveis registradas pelos sensores.
Em relao a SEDs modelados por autmatos, de acordo com Basilio et
al. (2010, p. 519), diz-se que uma linguagem gerada por um autmato
diagnosticvel em relao a um conjunto de eventos observveis o e a
um conjunto de eventos de falha f , para f uo se a ocorrncia da
falha puder ser detectada aps um nmero finito de transies depois da
sua ocorrncia, com base apenas em sequncias de eventos observveis. Em geral particiona-se o conjunto f em diferentes subconjuntos,
isto , fi , i = 1, 2, . . . , m, onde cada conjunto fi composto por eventos que modelam as falhas. Supondo que f = { f1 , f2 , . . . , fm } denote
essa partio, ento a ocorrncia de uma falha fi significa ento a ocorrncia de algum evento do conjunto fi .
2.6. Diagnosticabilidade
55
Figura 2.5: Exemplo 5: (a) Autmato Parcialmente Observado; (b) Observador

(a)
(b)
Fonte: Autor
Desde os primeiros estudos envolvendo diagnose de falhas em

SEDs, as seguintes hipteses so consideradas:
A1. (SAMPATH et al., 1995, p.1556) A linguagem L gerada por G viva,
ou seja, h uma transio definida para cada estado x em X , isto ,
o sistema no pode alcanar um ponto onde nenhum evento possvel. Formalmente diz-se (xi ) 6= 0/ para todo xi X;
A2. (SAMPATH et al., 1995, p.1556) No autmato G no existe nenhum

ciclo formado somente por eventos no observveis, i.e. ust L, s
uo , n0 N tal que k s k n0 , onde k s k denota o comprimento da

sequncia s.
56
A3. (BASILIO e LAFORTUNE, 2009) Existe somente um tipo de falha,

i.e., f = { f }, onde f = { f }.
Na hiptese A1 considera-se que o sistema est sempre em operao. A hiptese A2 necessria para evitar que, aps a ocorrncia do
evento de falha, o mesmo possa se tornar indetectvel se o sistema ficar
preso em um ciclo de estados formados apenas por eventos no observveis. No entanto, no trabalho apresentado por Baslio e Lafortune (2009),
esta hiptese foi removida e tais ciclos referido como ciclos escondidos
(BASILIO et al., 2010). J a hiptese A3 feita em alguns trabalhos apenas por simplicidade, uma vez que, para cada conjunto de eventos de
falha do mesmo tipo um rtulo diferente deve ser usado, porm os fundamentos de diagnosticabilidade permanecem os mesmos utilizados para
apenas um tipo de falha (BASILIO et al., 2010).
No trabalho de Sampath et al.(1995) as seguintes definies so
apresentadas:
( fi ) = {s f L : f fi } : conjunto de todas as sequncias de L

que terminam com um evento de falha pertencente fi .
L/s = {t : st L} : continuao da linguagem L aps a sequncia

s.
1
PoL
(y) = {s L : Po (s) = y} : operador projeo inversa em L.
A sequncia s L uma sequncia que contm a falha se f s.

Considerando e s , usamos a notao s para denotar que um evento da sequncia s. Com um ligeiro abuso de notao,
podemos escrever que fi s para denotar o fato que f s para algum
f fi (SAMPATH et al., 1995) ou formalmente:

s ( fi ) 6= 0/ ,
onde s denota o prefixo fechamento de s.
2.6. Diagnosticabilidade
57
Finalmente aps essas definies, pode-se formalmente apresentar a definio de diagnosticabilidade de uma linguagem, conforme
descrito por Sampath et al. (1995):
Definio 15. Seja L a linguagem gerada por um autmato G e suponha

que esta seja viva e prefixo-fechada. Ento, L diagnosticvel em relao
projeo Po e f = f se a seguinte condio for verdadeira:
(n N)(s ( f ))(t L/s)(k t k n D),

e a condio de diagnose D expressa por:
1
( PoL
(Po (st)))( f )
em que:
k t k denota o comprimento da sequncia t

s: sequncia que termina com um evento de falha.
t : continuao de s
De acordo com Sampath et al. (1995), a definio de diagnosticabilidade acima tem o seguinte significado:
Seja s uma sequncia arbitrria gerada pelo sistema, que termina com um evento de falha pertencente ao conjunto f e t qualquer
subsequncia que seja uma continuao da sequncia s. A condio de
diagnosticabilidade D requer que todas as sequncias em L que gerem
o mesmo registro de eventos observveis, tais como a sequncia st deve
conter nela um evento de falha do conjunto f . Isto implica que em todas as continuaes t de s capaz detectar a ocorrncia da falha com
um atraso finito, mais especificamente, com um mximo de n transies
do sistema aps a sequncia s. Em outras palavras, diagnosticabilidade
implica que qualquer evento de falha deve levar a observaes distintas
58
o bastante de tal modo a permitir a identificao de um nico evento de

falha com um atraso finito.
2.7
Diagnosticador
Em alguns casos, a ocorrncia da falha pode ser detectada (ob-
servada) por sensores, por se tratarem de eventos observveis. No entanto, na maior parte dos casos, os sensores so incapazes de detectar
um evento de falha, sendo ento necessrio model-la como um evento
no observvel em um autmato parcialmente observado, por exemplo.
Atravs da teoria de diagnose de falhas em SEDs, podemos verificar se
a ocorrncia de uma falha (evento no-observvel) em um SED pode ser
detectada ou no a partir da construo de um dispositivo denominado
diagnosticador (SAMPATH et al., 1995). O diagnosticador um tipo de
observador, porm neste so adicionados indicadores nos estados de G,
que formam os estados Gobs , formando assim os estados de Gd . Tais indicadores so destinados a fornecer informaes sobre a possibilidade
da ocorrncia ou no da falha. Dois tipos de indicadores (ou marcas) so
utilizados: N, indicando que o "evento f ainda no ocorreu"e Y para indicar que o "evento f j ocorreu". Assim, a notao dos estados x X
ser do tipo xN ou xY (SAMPATH et al., 1995).
No trabalho de Sampath et al. (1995), proposta uma metodologia para a construo deste diagnosticador. No entanto, no trabalho apresentado por Cassandras e Lafortune (2008, p. 112) proposta uma nova
metodologia, que utiliza um autmato rotulador. Esta metodologia ser
detalhada a seguir na Seo 2.8.
Dependendo das caractersticas do sistema e da forma como ele
modelado, as informaes sobre a evoluo do sistema podem estar
disponveis num nico sistema de aquisio ou podem estar distribudas
entre vrios sistemas (CARVALHO, 2011). Para cobrir estas duas possibilidades de configurao, foram propostas duas estruturas de diagnstico
de falhas em SEDs:
2.7. Diagnosticador
59
1. Diagnosticador Centralizado (SAMPATH et al., 1995), o qual usa um

nico diagnosticador que tem acesso a todos eventos observveis
do sistema;
2. Diagnosticador Descentralizado ou Codiagnosticador (DEBOUK et
al., 2000), no qual a leitura dos sensores no est centralizada,
mas distribuda entre diferentes mdulos que compem o sistema,
onde cada mdulo observa o comportamento do sistema usando
um subconjunto do conjunto dos eventos observveis do sistema.
No trabalho de Sampath et al. (1996) proposta uma arquitetura
genrica de um sistema que contm um subsistema para diagnstico de
falha, tal como ilustrado na Figura 2.6. Na camada inferior, tem-se o sistema e seu respectivo conjunto de controladores. Na camada superior
tem-se o supervisor, que executa alm das tarefas de controle o diagnstico de falhas, a recuperao e reconfigurao do sistema aps a identificao da falha e tambm a coordenao da operao de todos estes
subsistemas. A camada de interface entre estes dois nveis responsvel
por passar as informaes sobre a ocorrncia dos eventos observveis do
sistema ao supervisor e comunicar os comandos gerados pelo supervisor
para o sistema.
60
Figura 2.6: Arquitetura Conceitual de um Sistema com um Subsistema de

Diagnstico de Falhas
Fonte: Adaptado de Sampath et al. (1996, p. 106)
2.8
Diagnose Centralizada
O diagnosticador Gd , um autmato cuja definio apresen-
tada na equao 2.22, obtido, conforme mencionado anteriormente,

modificando-se o observador Gobs , com o objetivo de indicar, se possvel,
a ocorrncia ou no de um dado evento de falha, atravs de marcaes
Y e N respectivamente.
Gd = (Xd , o , fd , d , x0d )
onde:
Xd denota o espao de estados do diagnosticador;

o o conjunto de eventos observveis;
(2.22)
2.8. Diagnose Centralizada
61
fd : Xd o Xd a funo de transio de estados;
d : X 2 a funo dos eventos ativos;

x0d o estado inicial;
Pode-se construir o autmato Gd seguindo os dois passos abaixo

(CASSANDRAS e LAFORTUNE, 2008, p. 112):
i) obter a composio paralela do autmato G com o autmato Al , i.e.,
(G k Al ), onde Al o autmato rotulador mostrado na Figura 2.7.
ii) calcular Obs(G k Al ), seguindo o procedimento descrito no Algoritmo

1 na Seo 2.5.
Figura 2.7: Autmato Rotulador para Construo de Diagnosticadores
Fonte: Adaptado de Cassandras e Lafortune (2008, p. 112)
Em geral, tem-se que:
Gd = Obs(G k Al )
(2.23)
Note que o autmato resultante obtido no passo (i) gera a mesma

linguagem de G, porm nesta estaro anexados rtulos nos estados de
G, formando estados do tipo (x,Y ) ou (x, N) dependendo da presena
ou ausncia, respectivamente, de f na sequncia que leva x0 a x. Por
simplicidade, geralmente (x, N) e (x,Y ) so representadas como xN e xY
respectivamente (CASSANDRAS e LAFORTUNE, 2008; BASILIO et al.,
2010).
62
A seguir apresenta-se um exemplo a fim de ilustrar a construo

de diagnosticadores
Exemplo 6. Considere o autmato mostrado na Figura 2.8a, onde f
representa o evento de falha no observvel e a, b e c so os eventos
observveis do sistema. As Figuras 2.8b e 2.8c mostram a composio
paralela (G k Al ) e o diagnosticador Gd = Obs(G k Al ), respectivamente.
Figura 2.8: (a) Autmato G para o exemplo 6; (b) G k Al ; (c) Gd = Obs(G k
Al )
(a)
(b)
(c)
Fonte: Autor
Na Figura 2.8b podemos notar que o estado 6 de G se divide em

dois estados {6,Y} e {6,N} devido existncia de trs sequncias distintas s1 = f ac, s2 = b f c e s3 = bab que leva x0 = 1 para x = 6, onde
as sequncias s1 e s2 possuem o evento de falha f . No diagnosticador
(Figura 2.8c), podemos ver trs tipos de estados em relao aos rtulos
63
Y e N. Os estados onde somente o rtulo Y est presente ({4Y} e {6Y})

indicam um estado de falha, no qual o diagnosticador est certo sobre
a ocorrncia da falha. De modo similar, estados marcados apenas com
rtulos do tipo N representam estados de no falha, para os quais o diagnosticador est certo sobre a no ocorrncia da falha (estados {5N}
e {6N}). J os estados onde ambos os rtulos Y e N esto presentes,
representam estados onde o diagnosticador no pode determinar com
certeza se a falha ocorreu ou no, esses estados so denominados como
estados incertos (sobre a ocorrncia da falha), representados neste diagnosticador pelo estados {1N, 2Y} e {3N, 4Y}.
importante ressaltar que, uma vez estando o diagnosticador
certo sobre a ocorrncia da falha, ele no retornar, i.e., todos os estados seguintes continuaro indicando a falha. Entretanto, possvel que o
diagnosticador mude de um estado de no falha (normal) para um estado
incerto e desse para um estado certo de falha ou at mesmo normal.
Formalmente os estados do diagnosticador em relao a presena dos
rtulos Y e N so definidos como segue (SAMPATH et al., 1995):
Definio 16. Um estado xd Xd dito certo (de falha) se ` = Y para
todo x` xd , e normal (ou de no falha) se ` = N para todo x` xd . Se
xd , x no necessariamente distinto de y, tal que ` = Y e

existe (x`,y`)
` = N ento xd um estado incerto de Gd .
Na Figura 2.8c o estado inicial de Gd ({1N, 2Y }) um estado
incerto, porque o evento no observvel f pode ter ocorrido sem ter
sido registrado pelo diagnosticador. Esta possibilidade representada
pela componente 2Y, que significa que o sistema pode estar no estado 2,
aps a ocorrncia da falha f . No entanto, no estado inicial tambm pode
ocorrer o evento observvel b, de modo que o diagnosticador deve indicar que o sistema se manteve no estado 1 (devido ao evento b ainda no
ter sido registado) e, portanto, a falha ainda no ocorreu, a componente
1N indica essa possibilidade. A partir desse estado, quando o sistema
reporta para o diagnosticador a ocorrncia do evento a, ele muda para o
estado {4Y}, o que torna o diagnosticador certo da ocorrncia de falha
64
( f ). Uma vez neste estado, apenas o evento c ser considerado pelo diagnosticador e mesmo aps a sua ocorrncia o diagnosticador ainda vai
permanecer em um estado de falha, mas agora representado pelo estado
{6Y}. Contudo, a partir do estado inicial, se o sistema informar a ocorrncia do evento b, o diagnosticador mudar para o estado {3N, 4Y} e ainda
estar incerto sobre a ocorrncia da falha. Porm, se o prximo evento
que ocorrer for o evento c, ento o diagnosticador passar para o estado
{6Y} tornando-se agora certo da falha, caso contrrio, se o evento a ocorrer, o diagnosticador mudar para o estado {5N} indicando que est certo
da no ocorrncia da falha, em outras palavras, o sistema est operando
em condies normais.
A partir das definies 15 e 16, o seguinte lema uma consequncia direta entre os estados do diagnosticador e as sequncias da
linguagem gerada por G:
Lema 1. (SAMPATH et al., 1995) :
1
i) Seja xd = fd (x0d , s). Se xd um estado certo, ento [ PoL
(s)], f
ii) Se xd um estado incerto, ento s1 , s2 L, tal que f s1 e f

/ s2 ,
contudo Po (s1 ) = Po (s2 ) e fd (x0d , Po (s1 )) = xd e f (x0 , s1 ) 6= f (x0 , s2 )
Da definio de estado certo (Definio 16) e do Lema 1, percebese que, quando o estado atual do diagnosticador um estado certo, podemos afirmar que a falha ocorreu. No entanto, quando o diagnosticador
est em um estado incerto, isso indica que h duas sequncias s1 e s2 L
que reproduzem o mesmo registro de eventos observveis, onde s1 tem o
evento de falha, mas s2 no. Portanto, neste caso, baseado nos eventos
observveis no podemos concluir se a falha ocorreu.
A partir do lema anterior e da Definio 15, podemos concluir
que a linguagem L(G) ser diagnosticvel com relao a sua projeo Po
e f se, e somente se o diagnosticador sempre atingir um estado certo
para todas as sequncias de L que contm o evento de falha f . Isso no
65
ocorrer se, e somente se existir uma sequncia em L que faz com que
o diagnosticador fique preso em um ciclo indeterminado formado apenas
por estados incertos (BASILIO et al., 2010).
As definies 17 e 18 definem formalmente estes ciclos e as condies necessrias para um conjunto de estados incertos formarem um
ciclo indeterminado.
Definio 17. Seja L(G,x) = {s : f (x,s) X}, ou seja, o conjunto
de todas as sequncias que levam o autmato G do estado x X para
um outo estado. Ento um conjunto de estados {x1 , x2 , . . . , xn } X forma
um ciclo em um autmato G se s tal que s = 1 2 . . . n L(G, x1 ) onde
f (xl , l ) = xl+1 , l = 1, . . . , n 1 e f (xn ,n ) = x1 (SAMPATH et al., 1995).
Definio 18. Um conjunto de estados incertos {xd1 , xd2 , . . . , xd p } Xd

forma um ciclo indeterminado se:
1) xd1 , xd2 , . . . , xd p forma um ciclo em Gd , ou seja, existem l o , l =
1, 2, . . . , p, tais que fd (xdl , l ) = xdl+1 , l = 1, 2, . . . , p 1 e fd (xd p , p ) =

xd1 ;
r
2) (xl kl ,Y ), (xl l ,N) xd l , para xl l no necessariamente distinto de xl l , l =
1, 2, . . . , p, kl = 1, 2, . . . , ml , e rl = 1, 2, . . . , m l de tal forma que as sequnk
cias de estados {xl l }, l = 1, 2, . . . , p, kl = 1, 2, . . . , ml e {xl l }, l = 1, 2,
. . . , p, rl = 1, 2, . . . , m l , podem ser dispostas de modo a formar ciclos

em G, cujas sequncias correspondentes s e s, formadas com eventos
que definem a evoluo dos ciclos, tm como projeo 1 2 , . . . , p ,
onde 1 , 2 , . . . , p so definidos de acordo com o item 1 (BASILIO et
al., 2010).
Atravs das definies 15, 17 e 18 e do Lema 1, pode-se apresentar a seguinte condio necessria e suficiente para o diagnstico de
uma linguagem (BASILIO et al., 2010; SAMPATH et al., 1995).
66
Teorema 1. Uma linguagem L gerada por um autmato G ser diagnosticvel em relao a sua projeo Po e f = { f } se, e somente se, seu
diagnosticador Gd no possuir ciclos indeterminados.
Para o autmato do Exemplo 6, note que o diagnosticador Gd ,
mostrado na Figura 2.8c no possui ciclos indeterminados nem estados
ambguos, ento pode-se concluir que L diagnosticvel em relao a
Po e f = { f }.
Exemplo 7. Considere agora o autmato G da Figura 2.9a. Considere

tambm que = {a, b, c, f }, onde o = {a, c} o conjunto de eventos observveis, uo = {b, f } o conjunto de eventos no observveis e f =
{ f }, onde f representa o evento de falha.

A Figura 2.9b mostra a composio paralela de G k Al e o respectivo diagnosticador Gd de G mostrado na Figura 2.9c. Note que o
estado {5N, 4Y } um estado incerto e como fd ({5N, 4Y }, c) = {5N, 4Y },
ento o estado incerto {5N, 4Y } forma um ciclo indeterminado em Gd .
Este ciclo devido aos dois ciclos em G formado pelos estados 4 e 5,
como se pode ver na Figura 2.9a. Pode-se concluir ento, que neste caso
L no diagnosticvel em relao a Po e f
Observao A presena de ciclos em Gd formada apenas por estados
incertos no significa, necessariamente a impossibilidade de diagnosticar
a ocorrncia de falha. Para que L seja no diagnosticvel em relao a Po
e f , necessrio que aps a ocorrncia de falha, exista em G um ciclo
de estados que corresponda ao ciclo de estados incertos em Gd (SAMPATH et al., 2005; BASILIO et al., 2010). Em Cassandras e Lafortune
(2008, p. 114) mostrado um exemplo que ilustra esta condio.
2.9
Diagnose Descentralizada com Coordenao

O diagnstico centralizado no aplicvel a todos os tipos de
sistemas, principalmente queles que possuem uma caracterstica distri-
2.9. Diagnose Descentralizada com Coordenao
67
Figura 2.9: (a) Autmato G para o exemplo 7; (b) G k Al ; (c) Diagnosticador

Centralizado de G
(a)
(b)
(c)
Fonte: Autor
buda, uma vez que o diagnosticador no ter acesso a todos os conjuntos de eventos necessrios para diagnose (BASILIO e LAFORTUNE,
2009).
Considerando este cenrio, foi proposto por Debouk et al., (2000)
uma estrutura descentralizada com coordenao, chamada codiagnose.
Esta abordagem utiliza mdulos locais onde cada mdulo capaz de observar parte dos eventos observveis do sistema. Esses mdulos locais
se comunicam com um coordenador, o qual responsvel pelo diagnstico de falhas. Mais tarde, no trabalho proposto por Contant et al., (2006)
o conceito de diagnosticabilidade modular foi introduzido pela primeira
vez para um sistema que pode ser modelado pela composio paralela
de autmatos, onde cada autmato representa um componente local (ou
subsistema) do sistema global. Assim, se cada subsistema diagnosticvel, ento o diagnstico de falhas para o sistema global ser obtido
68
utilizando apenas os diagnosticadores locais (BASILIO et al., 2010). Em

Basilio e Lafortune (2009), foi formalmente apresentado o conceito de
codiagnose robusta, suas propriedades e as condies necessrias e suficientes para codiagnose robusta; onde um sistema descentralizado com
codiagnose ser dito robusto se e somente se aps a perda de comunicao entre um ou mais mdulos e o coordenador, o sistema ainda continuar
sendo diagnosticvel (BASILIO et al., 2010).
Conforme mostrado na Figura 2.10 (BASILIO e LAFORTUNE,
2009), as leituras dos sensores no so centralizadas, mas distribudas
entre diferentes mdulos Mi , i = 1,2, . . . , N . Cada mdulo possui seu prprio conjunto de eventos observveis oi , i = 1,2, . . . , N , conforme os sensores a ele conectados. Assim, cada mdulo observa o comportamento
do sistema com base nas informaes fornecidas pelos sensores a ele
conectados e processa o diagnstico, em seguida, de acordo com a estrutura descentralizada proposta por Debouk et al., (2000), cada mdulo
comunica seu diagnstico somente ao coordenador. O coordenador, por
sua vez processa a informao conforme um conjunto de regras prestabelecidas e toma a deciso sobre a ocorrncia ou no de falha (BASILIO et al., 2010).
importante notar que o coordenador , em geral um sistema
dedicado e sem conhecimento do modelo do sistema, possuindo ento
capacidades de memria e de processamento limitados (BASILIO e LAFORTUNE, 2009).
O diagnstico da linguagem L pela estrutura descentralizada com
coordenao, mostrada da Figura 2.10, depende, alm do conjunto de
falha f , de outros quatro elementos (BASILIO e LAFORTUNE, 2009):
i) do conjunto de regras usado para gerar os diagnsticos locais;

ii) das regras de comunicao entre mdulos e coordenador;
iii) das regras de deciso de diagnstico empregadas pelo coordenador;
2.9. Diagnose Descentralizada com Coordenao
69
Figura 2.10: Arquitetura Descentralizada com Coordenao
Fonte: Adaptado de Basilio e Lafortune (2009, p. 2205)
iv) das projees Po,i : o,i , i = 1,2, . . . N associadas a cada mdulo
Mi .
O conjunto de elementos (i), (ii) e (iii) so geralmente referidos

na literatura como protocolo (BASILIO e LAFORTUNE, 2009).
A Definio 15 pode ser modificada para incluir coordenao com
sistemas descentralizados, como segue (DEBOUK et al., 2000).
Definio 19. Uma linguagem L viva e prefixo-fechada dita diagnosticvel em relao a um protocolo, um conjunto de projees Po,i , i = 1, . . . , n,
e a um conjunto de falhas f = { f }, se a seguinte condio for verdadeira:
(n N)(s ( f ))(t Ls)(k t k n C est certa),
em que C denota a informao passada para o coordenador para fazer
70
o diagnstico e para cada caminho do sistema, C representado por um

conjunto de informaes que dependente do protocolo usado.
A condio de diagnosticabilidade definida acima, requer que
a deteco de qualquer falha seja efetuada pelo coordenador aps um
atraso finito de sua ocorrncia (DEBOUK et al., 2000).
Trs protocolos foram propostos por Debouk et al. (2000), em
particular, para o protocolo 3, um diagnosticador parcial implementado
em cada mdulo, cujo estado representa a informao diagnstico aps
a ocorrncia de um evento observvel. Quando um mdulo observa um
evento que leva o seu diagnosticador para um estado certo, ento este
comunica a ocorrncia da falha somente para o coordenador. O coordenador entretanto, declara a ocorrncia de uma falha, sempre que pelo
menos um dos mdulos comunicar uma ocorrncia de falha, caso contrrio, se no h relato de ocorrncia de falhas de qualquer mdulo, ele permanece em silncio. O protocolo 3 pode ser considerado como uma extenso do diagnstico centralizado para diagnstico descentralizado com
coordenao, e, portanto, ele tambm conhecido como codiagnose e
os diagnosticadores locais chamados de diagnosticadores parciais (BASILIO e LAFORTUNE, 2009).
2.10
Concluses do Captulo
Neste captulo foram apresentados os conceitos bsicos e prin-
cipais resultados acerca do estudo da diagnose de falhas em SEDs. Foram apresentadas as condies necessrias e suficientes para diagnose,
tanto para o caso centralizado como para o caso descentralizado com
coordenao (codiagnose). Tambm foi mostrada uma metodologia para
construo de diagnosticador atravs de um autmato rotulador. Nos captulos seguintes estes conceitos sero aplicados para a diagnose de falhas em sistemas embarcados, e uma metodologia de diagnstico multicamadas proposta e, posteriormente, aplicada a um estudo de caso.
71
3 PROPOSTA
DE
ARQUITETURA
MULTICAMADAS
PARA O DIAGNSTICO DE FALHAS EM SISTEMAS

EMBARCADOS
A complexidade dos dispositivos eletrnicos que fazem parte do

nosso cotidiano est em constante crescimento e particularmente emergente nos sistemas embarcados, onde um novo recurso ou uma nova
variante do equipamento pode ser rapidamente introduzida no mercado
apenas atualizando o software atual. Este tipo de abordagem est cada
vez mais presente em produtos eletrnicos tais como telefones celulares,
eletrodomsticos, automveis e outros. Em combinao com a reduo
de time-to-market (tempo para lanamento) o tempo de projeto tambm
tem diminudo sistematicamente, o que leva necessidade de introduzir
tcnicas de diagnstico de falhas mais eficientes a fim de identificar e
corrigir as falhas que podem ocorrer tanto durante a fase de concepo
quanto aps o lanamento e, assim, garantir no s que o produto seja
lanado no prazo desejado, como tambm com a qualidade exigida (ZOETEWEIJ et al., 2008). No que diz respeito ao ps-lanamento, ou seja,
no perodo em que o produto est em uso pelo consumidor, um melhor
diagnstico ajuda no s a identificar e entender rapidamente um modo
de falha e, assim prontamente corrigi-lo, mas tambm usar as informaes obtidas no diagnstico de falhas para mudar os prximos projetos
a fim de evitar a ocorrncia das mesmas. Quando se tratam de produtos
eletrnicos de consumo, aps o lanamento, uma falha no identificada
anteriormente pode ser muito prejudicial para a empresa, tanto em termos
financeiros devido ao custo com cobertura de garantias ou at mesmo um
recall, como em termos de imagem da marca associada a este equipamento ou produto. Isso torna o diagnstico de falhas algo ainda mais relevante e tem levado as grandes empresas a investir cada vez mais dentro
dos projetos em solues e ferramentas para diagnstico e recuperao
de falhas.
Captulo 3. Proposta de Arquitetura Multicamadas para o Diagnstico de Falhas em

72
Sistemas Embarcados
Frente a esse problema, tanto o projeto de diagnosticadores bem

como a definio de uma estrutura de sistema de diagnstico se torna
algo crucial e complexo, o que requer o uso de tcnicas e sistemticas
apuradas e adequadas para resolver este problema. A busca por tais tcnicas e sistemticas tornaram-se os principais motivadores deste trabalho. Neste captulo ser inicialmente apresentado uma breve introduo
sobre sistemas embarcados e em seguida ser apresentada uma proposta de arquitetura multicamadas para diagnstico voltada a sistemas
embarcados.
3.1
Sistemas Embarcados
Um sistema embarcado um sistema microprocessado no qual o
computador completamente dedicado ao dispositivo ou sistema que ele

controla (EMBARCADOS, 2014). Diferentemente dos computadores de
propsito geral, como o computador pessoal, um sistema embarcado realiza um conjunto de tarefas predefinidas e com requisitos especficos. Em
geral, tais sistemas no podem ter sua funcionalidade alterada durante o
uso e o usurio final no tem acesso ao programa que foi embutido no dispositivo. Em alguns casos, o sistema tambm executado com recursos
computacionais limitados: sem teclado, sem tela e com pouca memria e
possuem restries para computao em tempo real por questes de segurana ou usabilidade. O software escrito para sistemas embarcados
muitas vezes chamado firmware, e armazenado em uma memria ROM
ou memria Flash ao invs de um disco rgido.
O primeiro sistema embarcado reconhecido foi o Apollo Guidance
Computer, desenvolvido por Charles Stark Draper no MIT e utilizado no
projeto Apollo (HALL, 1996). J o primeiro sistema embarcado de produo em massa foi o computador guia do mssil nuclear LGM-30 Mssil
Minuteman, lanado em 1961, que possua um disco rgido como memria principal. Em sua segunda verso em 1966, o computador guia
foi substitudo por um novo, que constituiu o primeiro uso em grande volume de circuitos integrados. Desde suas primeiras aplicaes na dcada
3.1. Sistemas Embarcados
73
de 1960, os sistemas embarcados vm reduzindo de preo e crescendo

em poder de processamento e funcionalidade. Em meados da dcada de
1980, vrios componentes externos foram integrados no mesmo chip do
processador, dando origem ao single-chip, o que resultou em circuitos integrados chamados microcontroladores e na difuso dos sistemas embarcados. Com o baixssimo custo dos microcontroladores, tornou-se vivel
substituir componentes analgicos caros como potencimetros e capacitores por eletrnica digital controlada por pequenos microcontroladores.
No final da dcada de 1980, os sistemas embarcados j eram a regra ao
invs da exceo em dispositivos eletrnicos. A indstria automobilstica
comeou a fazer uso do microprocessador to logo as CPUs em singlechip tornaram-se disponveis. Segundo Wolf (2008), at meados de 2008
o uso mais importante e sofisticado de microprocessadores em automveis foi para controlar o motor determinando, quando as velas de ignio
deveriam gerar as fascas e controlando-se a mistura de combustvel e ar,
para aumentar a eficincia do motor. Dada a grande variedade de tipos
de microcontroladores disponveis hoje, no surpresa que eles estejam presentes em quase tudo que nos cerca e fazemos uso em nosso
cotidiano. Alm dos automveis, podemos citar os eletrodomsticos, tais
como forno de micro-ondas, geladeiras, foges e televises. Estas, por
sua vez, fazem um uso extensivo de processadores embarcados e, em
muitos casos, CPUs especializadas so especialmente projetadas para
executar algoritmos crticos, como por exemplo a CPU projetada para o
processamento de udio no chip set SGS Thomson para DirecTV (LIEM
et al., 1998). Podemos citar ainda alguns dispositivos de uso pessoal,
como celulares, Smart Phones e I-Pods, etc.
Quanto sua aplicao, um sistema embarcado pode ser classificado como:
De Propsito geral: so as aplicaes mais parecidas com os desktops, porm esto montados em "embalagens"especficas. Caracterizamse pela grande interao entre o usurio e o sistema, geralmente atravs
de terminais de vdeo ou monitores. Como exemplo tm-se os videogames, os conversores de TV a cabo e caixas de bancos;

74
Sistemas Embarcados
Sistemas de controle: realizam controles em malha fechada com realimentao em tempo real. Geralmente so as aplicaes mais robustas,
com placas dedicadas e mltiplos sensores de entrada e sada. Muitas
vezes fornecem pouca interao com o usurio, mostrando sinalizaes
atravs de LEDs ou displays. Usados para o controle de motores de automveis, processos qumicos, controle de voo, usinas nucleares, etc.;
Processamento de sinais: onde envolve um grande volume de informao a ser processada em curto espao de tempo. Os sinais a serem
tratados so digitalizados por meio de conversores Analgicos-Digitais,
processados, e novamente convertidos em sinais analgicos. Caso de
tratamento de udio, filtros, modems, compresso de vdeo, radares, sonares, etc.;
Comunicaes e redes: em aplicaes que evolvem chaveamento e

distribuio de informaes, tais como sistemas de telefonia, telecomunicaes e internet.
Dois modos de funcionamento dos sistemas embarcados so determinantes para saber como projetar o dispositivo e como ser seu funcionamento e comportamento na aplicao para o qual foi desenhado:
Reativo: o funcionamento se d como resposta a eventos externos, que

podem ser peridicos (de controles de loop) ou assncronos (pressionamento de um boto por parte do usurio, por exemplo). H, portanto, uma
necessidade de entrada de dados para que aconteam as aes de funcionamento;
Controle em tempo real: existem limites de tempo para executar cada

tarefa (leitura de sensor, emisso de sinais para um atuador, atualizao
de display, etc.). Este modo de operao, por ser cclico, no depende da
entrada de sinais para executar as atividades, sendo inclusive capaz de
tomar decises referentes ausncia dos mesmos.
Os sistemas de tempo real so classificados em:
i) Soft Real Time: As tarefas podem ser executadas em um intervalo de
3.2. Estrutura de Sistemas Embarcados
75
tempo especfico, sem consequncias graves se este limite de tempo

no for cumprido. Um exemplo um sistema bancrio, onde apenas
uma mensagem de erro aparecer se determinada tarefa no for realizada dentro do tempo pr-determinado.
ii) Hard Real Time: As tarefas devem ser executadas em um tempo especfico, com consequncias graves se qualquer tarefa falhar. Como
exemplo pode-se pensar nos sistemas de controle de um avio, onde
uma falha pode resultar em queda da aeronave e perdas de vidas.
3.2
Estrutura de Sistemas Embarcados

Analisando de maneira sistmica, pode-se perceber que os dife-
rentes equipamentos ou dispositivos que so controlados por um sistema

embarcado so em sua grande maioria compostos pelos seguintes elementos:
Hardware: placa eletrnica que contm um ou mais microcontroladores, tambm circuitos de condicionamento de sinais alm dos circuitos de
potncia e de acionamento de cargas e atuadores;
Software: conjunto de algoritmos para executar rotinas tais como leitura de sensores, tratamento matemtico dos sinais, lgica de controle,
rotinas de aplicao e interao com o usurio, dentre outras;
Cargas e Sensores: cargas e atuadores propriamente ditos tais como

motores, vlvulas e displays. Dentre os sensores podem-se citar os sensores de temperatura, presso, infravermelho, calor ou ainda simples chaves como chaves de fim de curso e tambm teclados.
Para exemplificar o contexto acima, tomemos dois equipamentos
bem distintos uma lavadora de roupas e um aparelho de TV. A seguir,
para ambos os equipamentos, so mostrados alguns dos componentes
presentes de cada um dos elementos Hardware, Software, Cargas e Sensores:

76
Sistemas Embarcados
Hardware:
- TV : Filtros analgicos, circuitos amplificadores, condicionadores de sinais de udio e vdeo, circuitos de potncia para auto-falantes e para tela
(display de LCD, LED, Plasma, etc.);
- Lavadora: Circuitos de potncia para acionamento do motor, condicionadores de sinais dos sensores, circuitos de acionamento para vlvulas
e bombas.
Software:
- TV : Processamento de imagem e som, menus do usurio, controle da
matriz da tela (display de LCD, LED, Plasma, etc.);
- Lavadora: Rotinas de controle de motor, processamento dos sinais dos
sensores, rotinas de programas de lavagem.
Cargas e sensores:
- TV : Tela (display de LCD, LED, Plasma, etc.), auto-falantes, sensor de
infravermelho do controle remoto;
- Lavadora: Motor, vlvulas, bombas, sensores de nvel e presso.
Na Figura 3.1a apresenta-se o diagrama de blocos para um dispositivo com sistema de controle embarcado.
Pode-se organizar estes elementos (Hardware, Software, Cargas
e Sensores) em trs categorias distintas que chamaremos de Camada de
Hardware, Camada de Software e Camada de Cargas e Sensores. Desta
forma, neste trabalho representa-se a estrutura bsica de um sistema
embarcado em camadas, conforme ilustrado na Figura 3.1.
De maneira geral temos:
Camada de Software : onde so implementados os algoritmos de controle, tratamento de sinais, aplicao, etc.;
Camada de Hardware: constituda pelos componentes e circuitos que
3.3. Diagnstico Multicamadas
77
compem a placa eletrnica, tais como rels, circuitos de potncia, circuitos de condicionamento de sinais, microcontroladores, etc.;
Camada de Cargas e Sensores: composta pelas cargas ou atuadores,

tais como motores, vlvulas, etc., e tambm pelo sensores.
Esta diviso adequada tanto sob o ponto de vista do equipamento quanto do ponto de vista do projeto. Nas grandes empresas o projeto de sistemas embarcados dividido em equipes com qualificaes
especficas para trabalhar em cada uma destas camadas, ou seja, uma
equipe mais especializada no desenvolvimento do software, outra mais
especializada no projeto do hardware e outra com conhecimentos especficos nas caractersticas eltricas e funcionais das cargas, atuadores e
sensores que sero aplicadas ao projeto. Esta diviso permite ainda estabelecer uma metodologia de desenvolvimento de projeto que seja flexvel
e maximize o reuso dos circuitos, rotinas de software, cargas, etc. desenvolvidos no projeto. Desta forma possvel por exemplo que a equipe
de desenvolvimento de software construa toda uma arquitetura onde seja
possvel atender diferentes tipos de hardware e cargas com um mnimo
ou sem nenhuma parametrizao, ou ainda, que a equipe de desenvolvimento de hardware possa projetar circuitos que atenderam diferentes
especificaes de cargas e sensores. Estabelecendo-se padres, interfaces definidas e especificaes claras possvel ainda que o projeto de
cada uma das camadas ocorra de maneira independente e com pouca
necessidade de interao entre as equipes, prtica muito comum em empresas que possuem equipes de trabalho descentralizadas, muitas vezes
at localizadas em pases diferentes.
3.3
Diagnstico Multicamadas
Normalmente, nos sistemas de diagnstico tradicionais, devido
ao efeito ou caracterstica da falha, nem sempre possvel identificar a

real origem desta falha. Para ilustrar isso, tomemos como exemplo novamente uma lavadora de roupas, onde temos uma bomba usada para

78
Sistemas Embarcados
Figura 3.1: (a) Diagrama de blocos para um dispositivo com sistema de

controle embarcado; (b) Diviso de camadas para um dispositivo com
sistema embarcado
(a)
(b)
Fonte: Autor
permitir enchimento de gua. No caso de uma falha onde a lavadora no

consegue encher de gua o cesto, para assim iniciar um ciclo de lavagem,
temos como potenciais fontes de falha:
i) a prpria bomba, isto , uma possvel falha na carga;
ii) sensor de vazo danificado, ou seja, uma falha de sensor;
iii) um problema eltrico no placa eletrnica, tal como um componente ou
circuito danificado, no permitindo assim o acionamento da bomba,
ou seja, neste caso temos uma falha no hardware;
iv) um erro ou inconsistncia no algoritmo de controle da bomba, que
pode ser causado tanto por um erro de lgica no software ou pelo
3.3. Diagnstico Multicamadas
79
corrompimento de algum dado da memria, devido a uma interferncia eletromagntica por exemplo, que cause uma falha no software e
impea o acionamento da bomba.
Em um sistema de diagnstico comum, esta falha seria caracterizada simplesmente como uma falha do sistema de enchimento, no
permitindo distinguir a real origem da mesma, uma vez que no prprio
diagnstico no so distinguidas as interaes entre software, hardware
e carga e apenas o efeito final da falha no sistema como um todo observado, ou seja, o cesto no encheu de gua.
Uma vez que cada camada possui funes e caractersticas bem
distintas umas das outras e, com o intuito de identificar precisamente a
origem da falha, prope-se a utilizao de diagnosticadores em cada uma
destas camadas para assim assegurar que a falha est por exemplo no
hardware do circuito de acionamento da bomba, e no no software de
controle ou ainda na prpria bomba, permitindo ento que uma possvel
ao de recuperao ou correo possa ser corretamente aplicada.
Na Figura 3.2 mostra-se de maneira genrica como estes diagnosticadores podem ser distribudos em cada uma destas camadas,
dando origem ao que denominamos neste trabalho de Sistema de Diagnstico Multicamadas. O objetivo do diagnstico multicamadas permitir
uma maior descriminao quanto origem da falha, possibilitando assim
um diagnstico mais preciso e robusto.
Em outras palavras, os diagnosticadores alocados da Camada de
Software so responsveis por diagnosticar falhas referentes s rotinas
ou algoritmos de software, como desvio do fluxo de software, mudanas
de estados no permitidas ou no previstas, etc.
J os diagnosticadores alocados na Camada de Hardware so
responsveis por diagnosticar falhas em circuitos ou componentes eltricos, como por exemplo falha de rels, em circuitos de potncia, circuitos
de acionamentos, circuitos de condicionamentos de sinais, etc.

80
Sistemas Embarcados
Figura 3.2: Sistema de Diagnstico Multicamadas
Fonte: Autor
Por fim, os diagnosticadores da Camada de Cargas e Sensores

sero responsveis por identificar quando uma carga ou sensor em especfico falhou como, por exemplo, um motor danificado que no d partida,
uma vlvula que no aciona ou ainda um sensor cujo sinal gerado est
fora do esperado ou admitido.
O grande objetivo por trs do diagnstico multicamadas assegurar que a origem da falha seja realmente identificada com a maior descriminao possvel, assim podemos dizer que o sistema de diagnstico
multicamadas aqui proposto ser um sistema de diagnstico multicamadas determinstico se, e somente se, a condio abaixo for satisfeita:
Definio 20. (Sistema de Diagnstico Multicamadas Determinstico):
Seja f = fsw
fhw
fcs , o conjunto de falhas do sistema, onde fsw =
{swi }, com i I = 1, ..., s, fhw = {hw j }, com j I = 1, ..., h e fcs =

{csk }, com k I = 1, ..., c, denotam respectivamente os conjuntos de falhas nas camadas de software, hardware e de cargas e sensores, e s,
h e c denotam o nmero de falhas nestes conjuntos. Sejam ainda Gdswi ,

Gdhw e Gdcsk os diagnosticadores para as falhas do tipo swi , hw j e csk ,
j
respectivamente.
Um conjunto de diagnosticadores com as caractersticas descritas dito
3.4. Arquitetura Multicamadas para Diagnstico de Falhas em Sistemas Embarcados
81
ser um Sistema de Diagnstico Multicamadas Determinstico se a ocorrncia de uma falha f f identificada somente pelo seu respectivo
diagnosticador (Gdswi , Gdhw ou Gdcsi ), permanecendo os demais inalterai
dos.
Para exemplificar a Definio 20, vamos retomar o exemplo da

lavadora. No caso de uma falha na bomba de enchimento, onde a mesma
no ligue por estar com enrolamento da bobina rompido, o diagnosticador
desta bomba, alocado na Camada de Cargas e Sensores, deve detectar
esta falha, e no ser permitido, por exemplo, que o diagnosticador do
circuito de acionamento da bomba alocado na Camada de Hardware detecte esta falha, confundindo como uma falsa falha de hardware ou ainda
que um diagnosticador da rotina de acionamento desta bomba alocado
na Camada de Software diagnostique a mesma falha, confundindo como
uma falsa falha de software.
3.4
Arquitetura Multicamadas para Diagnstico de Falhas em Sistemas Embarcados

Para que o sistema de diagnstico mostrado na Figura 3.2 possa
ser embarcado no dispositivo ou equipamento no qual se deseja realizar o diagnstico de falhas, e ainda, para que o diagnstico possa ser
realizado, necessrio criar uma arquitetura que permita que estes diagnosticadores acessem todas as informaes necessrias para tanto.
Muitas vezes, aps a ocorrncia de uma falha importante que
alguma ao de recuperao seja tomada pelo sistema, assim quanto
mais preciso for o diagnstico quanto origem da falha, mais efetiva ser
esta ao de recuperao. Em alguns casos tambm se faz necessrio
exteriorizar de algum modo (via display, LEDs, etc.) a ocorrncia da falha, para fins de manuteno corretiva, por exemplo. Portanto, novamente
quanto mais preciso for o diagnstico, mais eficaz ser a interveno tcnica para manuteno.

82
Sistemas Embarcados
Assim, no intuito de atender a estas condies, neste trabalho

apresenta-se uma arquitetura multicamadas de diagnstico de falhas em
sistemas embarcados. Esta arquitetura ilustrada por intermdio da Figura 3.3 e detalhada a seguir.
Figura 3.3: Arquitetura Multicamadas para Diagnstico
Fonte: Autor
Comeando de baixo para cima, temos as trs camadas anterior-
3.4. Arquitetura Multicamadas para Diagnstico de Falhas em Sistemas Embarcados
83
mente definidas: Camada de Cargas e Sensores; Camada de Hardware;

Camada de Software. Nestas camadas, esto os elementos que compem um sistema embarcado propriamente dito, conforme apresentado
na Seo 3.2. Na sequncia temos o bloco Interface o qual responsvel
por requisitar e gerenciar as informaes necessrias provenientes das
rotinas de controle, dos sensores e das cargas, destes dois ltimos previamente tratadas pelos circuitos de condicionamento de sinais da Camada
de Hardware e processadas na Camada de Software. Estas informaes
so ento transmitidas ao bloco Manipulador de Eventos. Este bloco por
sua vez responsvel por "manipular"corretamente essas informaes a
fim de fornecer os eventos necessrios para os diagnosticadores. importante mencionar tambm que este bloco pode, se necessrio, atuar
como um "sensor virtual", combinando duas ou mais informaes para
criar um evento no formato esperado pelos diagnosticadores.
Logo acima, temos o bloco denominado Sistema de Diagnstico,
onde os diagnosticadores so implementados de forma modular. Os diagnosticadores recebem os eventos do bloco Manipulador de Eventos,
processam e comunicam seu diagnstico ao bloco Gerenciador de Falhas (GF).
O Gerenciador de Falhas (GF) gerencia as informaes de falhas
reportadas por cada diagnosticador antes de comunic-la Aplicao e
ao bloco denominado Sistema de Recuperao de Falhas (SRF). Dentre
os principais atributos do GF destacam-se: a capacidade de gerar cdigos de identificao de falha, organizar as falhas em uma lista de acordo
com uma prioridade pr estabelecida, gerar um log com uma "fotografia"das condies do sistema no momento em que uma falha foi relatada
por qualquer diagnosticador, por exemplo.
O bloco SRF responsvel por executar as rotinas de recuperao de falhas, quando necessrio. Este bloco contm as rotinas de recuperao para cada tipo de falha que pode ser reportada pelos diagnosticadores via GF e tambm possui as regras de como e quando aplicar
cada uma destas rotinas.

84
Sistemas Embarcados
Finalmente, no topo temos o bloco de Aplicao, onde podem

ser implementadas as rotinas e mtodos necessrios para exteriorizar as
informaes referentes s falhas e reiniciar as condies de falhas, para
o caso de uma manuteno corretiva por exemplo. Portanto este bloco
responsvel por proporcionar uma interao com o usurio externo.
Como se pode notar, esta arquitetura considera a utilizao de
um conjunto de diagnosticadores conectados a um coordenador (bloco
GF, neste caso), que se assemelha diagnose descentralizada com coordenao proposta por Debouk et al. (2000) (ver Figura 2.10). No entanto, a arquitetura aqui proposta difere daquela, pois considera-se cada
diagnosticador como um diagnosticador centralizado, como proposto por
Sampath et al., (1995), j que cada diagnosticador responsvel por diagnosticar uma falha em especfico e tem acesso a todos os eventos
necessrios do sistema para a realizao do diagnstico. Pode-se considerar como uma extenso da arquitetura mostrada na Figura 2.6 onde
cada diagnosticador uma instncia adicional do bloco de Diagnstico de
Falhas
3.5
Neste captulo foram apresentados os conceitos bsicos e as
principais caractersticas dos sistemas embarcados. Props-se que os

elementos de um sistema embarcado fossem organizados em trs camadas: Camada de Software, Camada de Hardware e Camada de Cargas
e Sensores, onde cada uma destas camadas possui caractersticas, funcionalidades e finalidades distintas. Viu-se que esta diviso por camadas
no s traz facilidades em termos de metodologia de projeto como tambm permite que diagnosticadores possam ser devidamente desenvolvidos para realizar um diagnstico mais preciso que permita uma melhor
descriminao da origem da falha. Por fim, foi apresentado uma estrutura de diagnstico completa, onde seu principal objetivo viabilizar a
implementao do sistema de diagnstico multicamadas e tambm pro-
3.5. Concluses do Captulo
85
ver meios para que aps identificada uma falha, a mesma possa ser tratada por uma rotina de recuperao, se necessrio, ou ainda, que seja
possvel exteriorizar sua ocorrncia e tambm qualquer tipo de informao desejvel referente a esta falha. importante ressaltar que tanto o
sistema de diagnstico multicamadas como a arquitetura de diagnstico
apresentadas so independentes da metodologia a ser empregada para
a construo dos diagnosticadores ou da arquitetura de software utilizada
no sistema embarcado.
No prximo captulo ser apresentado um estudo de caso para
um refrigerador Frost Free constitudo por um sistema embarcado, onde
ser aplicado tanto o sistema de diagnstico multicamadas como a arquitetura de diagnstico apresentadas neste captulo. Os diagnosticadores
sero projetados no contexto de diagnose de falhas em SEDs conforme
proposto por Sampath et al. (1995). Posteriormente, no Captulo 5 sero
apresentados os detalhes da implementao em software destes diagnosticadores, segundo a arquitetura apresentada na Figura 3.3.
87
4 ESTUDO DE CASO: REFRIGERADOR DOMSTICO

FROST FREE
No captulo anterior foi apresentado um sistema de diagnstico

multicamadas, bem como uma arquitetura de diagnstico onde este sistema pode ser aplicado. Neste captulo apresentado um estudo de caso
para um refrigerador domstico do tipo Frost Free, onde este sistema de
diagnstico aplicado. O refrigerador em questo controlado por um
sistema embarcado constitudo de um microcontrolador juntamente com
uma placa de controle onde h diversos circuitos que vo desde condicionadores de sinais at circuitos de acionamento das cargas e tambm
possui certa diversidade em termos de sensores e tipos de cargas. J
em relao ao software, tm-se diferentes rotinas que vo desde o controle de acionamento de cargas at o controle da rotina termosttica e de
degelo. Por possuir esta diversidade de elementos em termos de hardware, software e cargas, que podem estar sujeitos a falhas, o refrigerador
em questo se mostra adequado para ser utilizado como estudo de caso
para validao da arquitetura multicamadas para o diagnstico preciso de
falhas, proposto no captulo anterior, pois permite explorar as caractersticas desta arquitetura. Os diagnosticadores foram projetados no contexto
de diagnose de falha em sistemas a eventos discretos, conforme proposto
por Sampath et al. (1996), uma vez que o comportamento do sistema do
refrigerador proposto neste estudo de caso pode ser, com certo nvel de
abstrao, modelado como SED.
Nas sees seguintes sero apresentadas as informaes relevantes sobre o funcionamento de um refrigerador Frost Free, necessrios
para o desenvolvimento deste estudo de caso, sero apresentados os
elementos de cada uma das camadas (hardware, software e cargas) para
qual se deseja realizar o diagnstico de falhas e, por fim, ser detalhado
o projeto dos diagnosticadores de cada um desses elementos.
88
4.1
4.1.1
Captulo 4. Estudo de Caso: Refrigerador Domstico Frost Free
Descrio do Refrigerador Frost Free

Principio de Funcionamento de um Refrigerador
Um refrigerador, como o mostrado na Figura 4.1 da fabricante
Whirlpool, de um modo geral funciona em ciclos, usando um fludo refrigerante num circuito fechado, que circula permanentemente retirando o
calor do interior do refrigerador e trocando-o com o exterior. O fludo refrigerante normalmente utilizado nos refrigeradores domsticos caracterizase por possuir elevado valor de calor latente de condensao e baixa temperatura de ebulio, alm de no ser inflamvel. Inicialmente usava-se
o gs freon 12 (clorofluorcarbono) como fludo refrigerante, contudo aps
o mesmo ser identificado como agressor camada de oznio, foi substitudo por outros fludos com propriedades semelhantes porm inofensivos
camada de oznio, como o caso do HFC-134A.
Figura 4.1: Refrigerador Forst Free
Fonte: Whirlpool Latin America
4.1. Descrio do Refrigerador Frost Free
89
Um refrigerador basicamente composto pelos componentes

conforme ilustrado na Figura 4.2, cujas funes so descritas a seguir:
- Fluido Refrigerante: Fluido utilizado para o processo de refrigerao,
o qual deve possuir baixa presso de vaporizao e alta presso de
condensao;
- Compressor : Sua funo puxar o fluido refrigerante sob baixa presso
atravs da linha de suco, comprimi-lo e direcion-lo ao condensador
sob alta presso e temperatura na fase gasosa (vapor super aquecido),
fazendo-o assim circular pela tubulao interna do aparelho;
- Condensador : Responsvel por prover a troca trmica com o ambiente
externo, liberando o calor absorvido no evaporador e no compressor
durante a compresso. Neste processo o fluido refrigerante passa do
estado de vapor super aquecido para o estado lquido sub resfriado a
alta presso;
- Filtro Secador : Possui duas funes importantes. A primeira reter partculas slidas que em circulao no circuito podem ocasionar obstruo ou danos a partes mecnicas do compressor. A segunda absorver totalmente a umidade residual do circuito que porventura no tenha
sido removida pelo processo de vcuo, evitando danos ao sistema, tais
como: corroso, aumento das presses e obstruo do tubo capilar por
congelamento da umidade;
- Tubo Capilar : um tubo de cobre com dimetro reduzido que age como
um elemento de expanso, pois recebe o fluido refrigerante sub resfriado a alta presso proveniente do condensador e promove uma perda
de carga, diminuindo a presso, separando assim os lados de alta e
baixa presso do circuito;
- Evaporador : Composto por um tubo em forma de serpentina, responsvel por receber o fluido refrigerante no estado lquido a baixa presso e temperatura. Nesta condio, o fluido refrigerante evapora absorvendo o calor da superfcie da tubulao do evaporador, ocorrendo
90
a transformao do lquido sub resfriado para vapor saturado a baixa

presso. Este efeito acarreta a diminuio da temperatura do ambiente
interno do refrigerador;
- Linha de Suco: Aps absorver o calor ao longo do percurso no evaporador, o fluido refrigerante, retorna ao compressor atravs da linha
de suco, no estado vapor super aquecido a baixa presso, para ser
ento novamente comprimido, dando incio a um novo ciclo.
Figura 4.2: Componentes Bsicos de um Refrigerador
Fonte: TECUMSEH do Brasil
4.1.2
Tecnologia Frost Free

A tecnologia Frost Free ou No Frost ("sem-gelo", em traduo
literal), um sistema de refrigerao inteligente controlado eletronicamente. caracterizado pela sua capacidade de refrigerao sem formao de gelo nas paredes do compartimento. Nos refrigeradores comuns,
91
o evaporador disposto em torno da parede do freezer ou do congelador, fazendo assim com que toda a parede fique bastante fria. A grande
desvantagem desta configurao que toda a umidade do ambiente se
condensa sobre essas paredes frias, que em seguida congelam e acabam ficando depositadas nas paredes, ficando cada vez maiores com o
passar do tempo diminuindo a eficincia trmica do compartimento.
J em um refrigerador Frost Free, o evaporador fica afastado e
termicamente isolado das paredes. Neste sistema somente o ar frio
soprado para dentro do compartimento por um ventilador, mantendo assim este ambiente seco e sem gelo. Contudo, no evaporador, e somente
l, haver formao de gelo, que por sua vez ser periodicamente derretido atravs da rotina de degelo, que controla o acionamento de uma
resistncia eltrica montada em torno do evaporador. Na Figura 4.3a
mostrado um evaporador onde possvel visualizar a resistncia de degelo j montada em torno do mesmo. J na Figura 4.3b, mostrado o
mesmo evaporador, contudo j em uma condio crtica de formao de
gelo, onde a rotina de degelo precisa ser realizada.
Figura 4.3: (a) Detalhe do Evaporador Montado com uma Resistncia de

Degelo; (b) Condio do Evaporador com Formao de Gelo
(b)
(a)
Fonte: Autor
92
Devido necessidade do uso desta resistncia eltrica, o consumo de energia neste tipo de refrigerador tende a ser maior em relao
aos refrigeradores comuns. Por este motivo, h um grande esforo por
parte dos fabricantes em desenvolver refrigeradores que sejam mais eficientes, buscando uma melhor isolao trmica, um controle de temperatura mais robusto e principalmente rotinas de degelo que sejam mais
inteligentes, isto , rotinas que estejam constantemente monitorando o
comportamento e uso do refrigerador para assim determinar o melhor
momento para realizar o degelo.
4.1.3
Controle Termosttico
O controle de temperatura do tipo de refrigerador escolhido neste
estudo de caso baseia-se no liga/desliga do compressor e do ventilador.

Atravs de um termistor do tipo NTC (Negative Temperature Coefficiente),
possvel monitorar a temperatura do compartimento e assim determinar
quando o compressor e o ventilador devem ser ligados ou desligados. Estes valores de temperatura so pr estabelecidos e denominados de TON
(temperatura para ligar o compressor) e TOFF (temperatura para desligar
o compressor) e definem uma histerese em torno de um setpoint, sendo
este o valor mdio de temperatura desejado para o compartimento. Na
Figura 4.4 mostrado o grfico de temperatura e ciclos de acionamentos
do compressor, onde possvel verificar como a temperatura varia em
torno de TON e TOFF durante o ciclo termosttico.
4.1.4
Rotina de Degelo
A rotina de degelo ou descongelamento responsvel por garan-
tir que o gelo formado no evaporador seja periodicamente derretido, evitando assim que o refrigerador perca eficincia de resfriamento e ainda
que este gelo possa migrar para as paredes internas no compartimento.
Essa rotina usualmente formada por duas partes, uma responsvel por
monitorar as condies de uso e desempenho do produto para assim determinar quando necessrio realizar o degelo, e outra responsvel por
93
Figura 4.4: Forma de Onda da Temperatura Durante os Ciclos Termostticos
Fonte: Autor
executar o degelo propriamente dito atravs do controle de acionamento

de uma resistncia de aquecimento. No entanto, determinar qual o melhor momento para iniciar um degelo no uma tarefa simples, requer
informaes tanto dos sensores de temperatura, sensores de abertura de
porta e ainda de informaes provenientes de algumas rotinas de software como fator de funcionamento do compressor, tempo transcorrido
desde o ltimo degelo, tempo e nmero de aberturas de porta, dentre
outras. Ou seja, o tempo entre cada degelo pode variar dependendo das
condies de uso do produto. Vale a pena ressaltar que intervalos muito
longos de degelo podem gerar um acmulo muito grande de gelo no evaporador, o que prejudica a troca de calor alm de prolongar o tempo de
resistncia ligada para eliminar todo este gelo, aumentando o consumo de
energia durante o degelo. Por outro lado, intervalos muito curtos de degelo podem ocasionar uma perda de eficincia do produto, uma vez que
ao fim de cada degelo o produto precisa se recuperar, isto , estabilizar a
temperatura em torno do setpoint, j que o processo de degelo gera um
94
calor excessivo que precisa ser retirado. Por razes de segredo industrial
no sero mostrados neste trabalho os detalhes do algoritmo responsvel por determinar quando o degelo deve ser iniciado, implementado no
refrigerador proposto utilizado neste estudo de caso. Ser considerado
apenas a rotina de controle de acionamento da resistncia, j durante o
processo de degelo.
4.2. Aplicao do Diagnstico de Falhas Multicamadas em um Refrigerador Domstico

Frost Free
4.2
95
Aplicao do Diagnstico de Falhas Multicamadas em um Refrigerador Domstico Frost Free

Um refrigerador do tipo Frost Free minimamente composto por
uma placa eletrnica onde residem o microcontrolador, circuitos de condicionamento de sinais de sensores, circuitos de potncia para acionamento de cargas, dentre outros; por cargas tais como compressor, resistncia de aquecimento para fins de degelo e motor do ventilador; e
finalmente por sensores, dentre os quais se podem citar os sensores de
temperatura (NTC ou PTC por exemplo), sensores de abertura de porta
e sinais de feedback de circuitos de acionamentos. No microcontrolador
encontra-se o software que controla tanto as rotinas referentes aplicao (interao com o usurio) como as rotinas de controle do refrigerador, como por exemplo a rotina termosttica, rotina de degelo e a rotina
de controle do compressor, conforme mostrado na Figura 4.5
Figura 4.5: Diagrama de Blocos de um Refrigerador
Fonte: Autor
96
Como mencionado anteriormente, para um diagnstico efetivo

deve-se considerar diagnosticadores para cada uma das trs camadas,
i.e., deve ser feito o diagnstico para os elementos que compem a camada de software (rotinas de software), a camada de hardware (circuitos
e componentes eltricos) e a camada de cargas (cargas do sistema).
Neste captulo sero apresentados os detalhes do projeto desses diagnosticadores, conforme mostrado na Figura 4.6, onde para a camada de
software foi considerado o diagnstico para a rotina termosttica, rotina
de degelo e rotina de controle do compressor. J para a camada de hardware, foram admitidos diagnosticadores para os circuitos de acionamento
tanto do compressor como da resistncia de degelo, circuito este composto por rel e circuito de comando. Finalmente para a camada de cargas, considerou-se diagnosticadores para o compressor e para a resistncia de degelo.
Todos os diagnosticadores foram projetados no contexto de diagnose de falha em sistemas a eventos discretos, conforme proposto
por Sampath et al. (1996), e, uma vez que todos os diagnosticadores
possuem acesso a todos os eventos observveis necessrios para a diagnose, adotou-se a arquitetura de diagnose centralizada. As seces
seguintes detalham o projeto de cada um dos diagnosticador acima mencionados.
4.3
Projeto dos Diagnosticadores da Camada de Software

Na camada de software h trs rotinas cujo diagnstico neces-
srio: a rotina termosttica, a rotina de controle do compressor e a rotina

de degelo, descritas a seguir. Definimos ento o conjunto de falhas pertencente camada de software, como segue:
fsw = {sw1 , sw2 , sw3 }

onde:
- sw1 = TC_Fail Evento de falha da rotina termosttica;
4.3. Projeto dos Diagnosticadores da Camada de Software
97
Figura 4.6: Sistema de Diagnstico Multicamadas para um Refrigerador
Fonte: Autor
- sw2 = Comp_Ctrl _Fail Evento de falha da rotina de controle do compressor;

- sw3 = De f _Fail Evento de falha da rotina de degelo.
Uma vez que temos acesso a algumas informaes do software
de controle, consideraremos essas informaes como se fossem provenientes de sensores, ou seja, teremos uma espcie de "sensor virtual", cuja
informao simplesmente um dado da memria referente a alguma varivel interna ao software.
4.3.1
Diagnosticador da Rotina Termosttica

A rotina termosttica responsvel por controlar quando o com-
pressor deve ser ligado e desligado para assim manter a temperatura

do refrigerador dentro da faixa de temperatura selecionada (setpoint).
Para efetuar este controle, esta rotina se baseia na leitura proveniente
do sensor de temperatura, comparando-a com o valor de referncia (TON )
e (TOFF ), conforme o setpoint selecionado. Assim, se a temperatura est
acima do valor de referncia para acionamento do compressor (TON ), esta
rotina deve requisitar que o compressor seja ligado, e quanto a tempera-
98
tura estiver abaixo do valor de referncia de desligamento (TOFF ), esta

rotina deve ento solicitar o desligamento do compressor.
O autmato que representa o modelo da rotina termosttica GTC
mostrado na Figura 4.7. Esta rotina composta por trs estados principais, aqui denominados como TC_SATISF, TC_COOLING e TC_DEF.
O quarto estado TC_FAIL foi adicionado para representar o estado de
falha desta rotina. O estado TC_SATISF (Termosttica Satisfeita) representa a condio onde a rotina termosttica est satisfeita, isto , a temperatura est abaixo de TOFF (evento Below_CP) e portanto enquanto
esta condio perdurar a rotina termosttica deve requisitar que o compressor permanea desligado, condio esta representada pelo evento
Req_Comp_Off. No entanto, caso a temperatura suba acima de TON , o
evento Above_CP gerado, fazendo a rotina mudar ento para o estado
TC_COOLING (Termosttica Resfriando), e requisitar assim que o compressor seja ligado, atravs do evento Req_Comp_On e esta condio
deve se manter enquanto a temperatura estiver acima do valor de desligamento do compressor (TOFF ). Agora, a partir do estado TC_COOLING,
se a temperatura cair abaixo de TOFF , o evento Below_CP gerado fazendo a rotina termosttica retornar ao estado TC_SATISF. Para ambos
estados TC_SATISF e TC_COOLING, caso um processo de degelo precise ser iniciado, o evento OK_to_Def (OK para Degelo) ser gerado
e a termosttica ir ento mudar para o estado TC_DEF (Termosttica
Degelando) e o compressor deve ser requisitado para ser mantido desligado, mesmo que a temperatura suba acima da temperatura de ligamento. Esta condio representada pelos auto-laos Req_Comp_Off,
Above_CP e Below_CP. Uma vez no estado TC_DEF, aps a ocorrncia do evento de fim de degelo (Defrost_End), a rotina retornar ao estado TC_COOLING. Em condies normais esperado que aps o fim
de um degelo a temperatura esteja acima do setpoint, contudo por questo de simplicidade independentemente da temperatura, ao trmino de
um degelo a rotina sempre retorna ao estado TC_COOLING. Os autolaos Req_Comp_On no estado TC_COOLING e Req_Comp_Off nos
estados TC_SATISF e TC_DEF so usados para representar o fato de
99
que essa rotina faz uma atualizao peridica da condio requisitada do

compressor (ligado ou desligado). De maneira anloga, as condies de
temperatura Above_CP e Below_CP tambm so periodicamente atualizados. A falha desta rotina representada pelo evento no observvel
TC_Fail (Falha na Termosttica). Na ocorrncia deste evento, a partir de
qualquer estado (TC_SATISF, TC_COOLING ou TC_DEF ) o autmato
mudar para o estado TC_FAIL e ali ficar preso.
Figura 4.7: Autmato que Modela a Rotina Termosttica, GTC
Fonte: Autor
Observe que em nenhum momento a rotina termosttica liga ou

desliga diretamente o compressor, ela apenas faz requisies para ligar
ou desligar o mesmo. Estas requisies so recebidas pela rotina de con-
100
trole do compressor e esta por sua vez quem ir atuar para efetivamente
ligar ou desligar o compressor. Esta rotina ser detalhada mais adiante
na seo 4.3.2.
A Figura 4.8 mostra a autmato rotulador AlT h considerado para
o diagnstico da rotina termosttica.
Figura 4.8: Autmato Rotulador para Falha na Rotina Termosttica, AlT h
Fonte: Autor
O prximo passo para se obter o diagnosticador GdT h determinar a composio sncrona da planta GTC com o autmato rotulador AlT h ,
isto fazer (GTC ||AlT h ), cujo resultado mostrado na Figura 4.9.
Em seguida, o diagnosticador GdT h obtido determinando-se o
observador deste ltimo autmato, ou seja, GdT h = Obs(GTC ||AlT h ), mostrado da Figura 4.10. O estado {4Y } representa o estado onde o diagnosticador est certo da ocorrncia da falha. Uma vez atingido este estado, no h como o diagnosticador retornar para algum estado incerto,
ou seja, ele ficar ali preso independente de qual evento ocorra, satisfazendo assim a condio de diagnosticabilidade enunciada por Sampath
et al. (1995) e Basilio et al. (2010). importante ressaltar que embora
o diagnosticador obtido possua ciclos formados apenas por estados incertos, isso no necessariamente implica na impossibilidade de se diagnosticar a ocorrncia de uma falha. Conforme mostrado anteriormente na
seo 2.8, para que L seja diagnosticvel em relao a Po e f , aps a
ocorrncia da falha, no pode existir um ciclo de estados em G que corresponda a um ciclo de estados incertos no diagnosticador. Um exemplo
101
Figura 4.9: Autmato obtido pela composio GTC ||AlT h
Fonte: Autor
que ilustra a situao onde um ciclo de estados incertos no formam um

ciclo indeterminado no diagnosticador pode ser encontrado em Cassandras e Lafortune (2008, p.114). Como pode-se observar na Figura 4.7,
aps ocorrncia da falha independente do estado atual, o autmato sempre alcanar para o estado de falha, isso no deixar o diagnosticador
preso no ciclos formados apenas por estados incertos.
102
Figura 4.10: Diagnosticador para Rotina Termosttica, GdT h
Fonte: Autor
4.3.2
Diagnosticador da Rotina de Controle do Compressor

Essa rotina gerencia as requisies para ligar e desligar o com-
pressor. Ela ir avaliar e tratar adequadamente estas requisies antes

de atuar no circuito de acionamento para assim ligar ou desligar o compressor, conforme solicitado.
Como mostrado na Figura 4.11, o autmato GCompRoutine que modela o comportamento desta rotina possui sete estados, como segue:
103
COMP_ON (Compressor Ligado);

COMP_OFF (Compressor Desligado);
COMP_OFF_NOT_PROTEC (Compressor Desligado e no protegido);
COMP_ON_NOT_PROTEC (Compressor Ligado e no protegido);
COMP_WAIT_ON (Compressor Ligado e protegido, aps requisio
para desligar),
COMP_WAIT_OFF (Compressor Desligado e protegido, aps requisio para ligar) e
COMP_CTRL_FAIL (Falha da Rotina de Controle do Compressor),
Este autmato possui o seguinte conjunto de eventos:

- Req_Comp_On (Requisio para Ligar o Compressor);
- Req_Comp_Off (Requisio para Desligar o Compressor);
- Set_Comp_On (Liga Compressor);
- Set_Comp_Off (Desliga Compressor);
- CompON_Prot_Timeout (Fim da Proteo de Compressor Ligado) e
- CompOFF_Prot_Timeout (Fim da Proteo de Compressor Desligado).
O estado COMP_CTRL_FAIL representa o estado de falha da

rotina de controle do compressor.
O modelo desta rotina considera duas protees, a primeira est
relacionada com o tempo mnimo que o compressor deve ser mantido
desligado e a segunda refere-se ao tempo mnimo na qual o compressor deve ser mantido ligado. O objetivo da primeira proteo garantir
que o compressor ficar desligado o mnimo de tempo necessrio para
equalizar a presso do sistema de refrigerao, caso contrrio, um sobreaquecimento ocorrer sob as bobinas do motor do compressor, podendo
danific-lo. J e segunda proteo usada para os casos onde se deseje
fixar um tempo mnimo de funcionamento do compressor entre cada ciclo de liga e desliga do compressor, e assim melhor controlar o fator de
funcionamento, que um dos parmetros essenciais para a tomada de
deciso de quando iniciar um novo ciclo de degelo.
104
Figura 4.11: Autmato que Modela a Rotina de Controle do Compressor,
GCompRoutine
Fonte: Autor
Assim, caso o compressor esteja ligado (estado COMP_ON) e

chegue uma requisio para deslig-lo enquanto a proteo de tempo
mnimo ligado ainda no expirou, a rotina estar ciente desta nova re-
105
quisio, mudando para o estado COMP_WAIT_ON, mantendo ainda o

compressor ligado at que o tempo expire, quando mudar ento para
o estado COMP_ON_NOT_PROTEC. Neste momento, se a requisio
para desligar o compressor ainda persistir a rotina mudar para o estado
COMP_OFF, e finalmente o compressor ser desligado. Entretanto, caso
a proteo de tempo mnimo ligado expire antes da ocorrncia da requisio de desligar, a rotina ir para o estado COMP_ON_NOT_PROTEC,
mantendo o compressor ainda ligado. Uma vez neste estado, ocorrendo
agora sim, a requisio para desligar, a rotina atender essa requisio
sem restries, mudando para o estado COMP_OFF desligando assim o
compressor.
De maneira similar, quando o compressor est desligado, porm
ainda dentro do tempo de proteo de tempo mnimo desligado, e h uma
requisio
para
ligar,
autmato
mudar
para
estado
COMP_WAIT_OFF, indicando que a rotina est ciente desta requisio

mas manter o compressor desligado at que o tempo de proteo expire.
Quando
isso
acontecer,
autmato
ir
para
estado
COMP_OFF_NOT_PROTEC, e se a requisio de ligar o compressor

ainda se mantiver, ele mudar para o estado COMP_ON, ligando finalmente o compressor. Caso contrrio, se a proteo expirar sem que tenha
ocorrido alguma requisio para ligar o compressor, o autmato ir para
o estado COMP_OFF_NOT_PROTEC. Neste estado, ocorrendo uma requisio para ligar, a mesma ser atendida e o autmato ir para o estado
COMP_ON.
A proteo de tempo mnimo ligado ativada sempre que h uma
transio do estado do compressor de desligado para ligado e de maneira
anloga, a proteo de tempo mnimo desligado ativada sempre que h
uma transio do compressor do estado ligado para o estado desligado.
No entanto estes eventos de ativao no so considerados no modelo
pois no so relevantes do ponto de vista de diagnstico. Somente os
eventos relacionados expirao destas protees se mostraram relevantes para o diagnstico, e so representadas, conforme mencionado,
106
pelos eventos CompON_Prot_Timeout e CompOFF_Prot_Timeout respectivamente.

Na Figura 4.12 mostra-se o autmato rotulador AlCompModel usado
para o diagnstico da rotina de controle do compressor.
Figura 4.12: Autmato Rotulador para Falha na Rotina de Controle do
Compressor, AlCompModel
Fonte: Autor
O prximo passo para obter o diagnosticador GdCompRoutine determinar a composio sncrona de GCompRoutine com AlComp , cujo autmato resultante mostrado na Figura 4.13. Por fim, o diagnosticador da
rotina de controle do compressor obtido determinando-se o observador
deste autmato, ou seja, GdCompRoutine = Obs(GCompRoutine ||AlCompModel )
(ver Figura 4.14) .
Por questes de espao, no intuito de obter uma figura legvel,
para a representao do diagnosticador, os nomes originais dos eventos foram substitudos por identificadores (IDs) de uma nica letra, cuja
correspondncia mostrada na Tabela 4.1. O estado {3Y } representa
a situao em que o diagnosticador est certo da ocorrncia da falha,
e uma vez alcanado este estado, o diagnosticador ali ficar preso, no
sendo possvel retornar para um estado incerto.
De maneira anloga ao diagnosticador obtido para a rotina termosttica na seo anterior, o fato do diagnosticador obtido possuir ciclos
formados apenas por estados incertos, no implica na impossibilidade de
se diagnosticar a ocorrncia da falha. Para que L seja diagnosticvel em
107
Figura 4.13: Autmato resultante de GCompRoutine ||AlCompModel
Fonte: Autor
relao a Po e f , no pode existir um ciclo de estados em G aps a

ocorrncia da falha que corresponda ao ciclo de estados incertos no diagnosticador. Como se pode observar na Figura 4.11, aps ocorrncia da
falha, independentemente do estado atual, o autmato sempre alcanar
o estado de falha. Isso no deixar o diagnosticador preso no ciclos formados apenas por estados incertos.
108
Figura 4.14: Diagnosticador para a Rotina de Controle do Compressor,
GdCompRoutine
Fonte: Autor
4.3.3
Diagnosticador da Rotina de Degelo

A rotina de degelo uma rotina extremamente crtica para um
refrigerador do tipo Frost Free, pois ela quem controla a operao da

resistncia de degelo para garantir um degelo automtico e eficiente, o
que caracteriza um refrigerador do tipo Frost Free. Essa rotina com-
109
Tabela 4.1: Tabela de Eventos para o Diagnosticador da Rotina do Compressor

Nome do Evento
CompO f f _Prot _Timeout
CompOn_Prot _Timeout
Req_Comp_O f f
Req_Comp_On
Set _Comp_On
Set _Comp_O f f
ID do Evento
A
B
C
D
E
F
posta por diversos passos que vo desde monitorar o comportamento

do refrigerador, coletando e processando informaes para determinar o
melhor momento para iniciar um novo ciclo de degelo at realizar o controle de ativao da resistncia de degelo durante a execuo do ciclo de
degelo. O autmato que modela o algoritmo de software desta rotina,
mostrado a seguir na Figura 4.15.
O primeiro estado desta rotina o DEF_MONITOR (Monitor de
Degelo). Neste passo a rotina est aguardando que as condies de incio de degelo sejam satisfeitas. Por questes de sigilo industrial, sem que
haja prejuzo para o modelo de diagnstico aqui proposto, essas condies no sero mostradas. Quando estas condies so satisfeitas, o
evento Ready_to_Def (Pronto para Degelo) gerado, levando assim o
autmato para o estado READY_TO_DEF (Pronto para Degelo). Neste
estado, a rotina est esperando pelo evento de confirmao de incio de
degelo Defrost_Trigger_True (Disparo de Degelo Verdadeiro), para assim
iniciar o processo de degelo. Essa confirmao feita pela rotina de aplicao ( rotina responsvel por gerenciar as configuraes selecionadas
pelo usurio, tais como nvel de temperatura, rotinas de congelamento
rpido, modo frias, turbo gelo, etc.), pois em alguns casos, ela pode
ser postergada devido execuo de alguma outra rotina que no pode
ser interrompida no momento, como por exemplo as rotinas de congelamento rpido e turbo gelo. Assim que o incio de degelo confirmado
(evento Defrost_Trigger_True gerado), o autmato mudar ento para
110
Figura 4.15: Autmato que Modela a Rotina de Degelo, GDe f Model
Fonte: Autor
o prximo estado, denominado INIT_HEATER_ON (Estado Inicial de Resistncia Ligada), onde a resistncia de degelo ligada. Neste momento,
a rotina passa a verificar trs condies, representadas pelos eventos
abaixo listados:
i) Initial_HeaterON_TimeComplete: Tempo inicial de resistncia ligada

completo;
ii) Def_End_Temp: Temperatura de fim de degelo alcanada, e
111
iii) Def_Timeout: Tempo mximo de degelo alcanado.
O primeiro evento refere-se ao mximo tempo permitido para a

resistncia permanecer ligada neste passo, o segundo se a temperatura
de fim de degelo foi atingida e o terceiro se o tempo mximo de execuo
da rotina de degelo foi alcanado.
Na ocorrncia do evento Initial_HeaterON_TimeComplete, a rotina de degelo ir ento alternar a resistncia entre desligada e ligada,
atravs da alternncia dos estados PULSED_OFF (Pulso Inativo) e PULSED_ON (Pulso Ativo) respectivamente, atravs da ocorrncia dos eventos Pulsed_OFF_TimeComplete (Tempo de Pulso Ativo Completo) e Pulsed_ON_TimeComplete (Tempo de Pulso Inativo Completo) respectivamente. Quando a temperatura de fim de degelo ou o tempo mximo
de durao do gelelo so atingidos, ou seja, na ocorrncia do evento
Def_End_Temp ou Def_Timeout respectivamente, o prximo estado permitido o DEF_EXT (Degelo Estendido). Neste estado, a resistncia
pode ser mantida ligada por um tempo extra, se necessrio, ou alguma
resistncia auxiliar pode tambm ser ligada, at que o evento DefExtTime_Complete (Tempo Extra de Degelo Completo) ocorra, levando assim a rotina para o ltimo estado, denominado DROPPING (Escorrimento).
O objetivo deste ltimo estado apenas esperar at que toda a gua proveniente do degelo escorra pelo duto de sada antes de ligar novamente
o compressor, evitando assim que esta gua congele dentro dos dutos,
bloqueando-os.
Assim
que
este
tempo
expirar,
evento
DropTime_Complete (Tempo de Escorrimento Completo) ser gerado levando ento o autmato para o estado inicial DEF_MONITOR novamente.
O estado DEF_CNTRL_FAIL (Falha na Rotina de Degelo) representa o estado de falha desta rotina devido ocorrncia do evento no
observvel Def_Fail (Falha no Degelo). A Figura 4.16 mostra o autmato
rotulador AlDe f Label para esta rotina e a Figura 4.17 a composio sncrona entre o modelo da rotina de degelo e seu autmato rotulador, isto
GDe f Model ||AlDe f Label .
112
Figura 4.16: Autmato Rotulador para Falha na Rotina de Degelo,
AlDe f Label
Fonte: Autor
Figura 4.17: Autmato obtido pela composio GDe f Model ||AlDe f Label
Fonte: Autor
113
O diagnosticador GdDe f Model foi obtido calculando-se o observador deste ltimo autmato, isto , GdDe f Model = Obs(GDe f Model ||AlDe f Model ),
mostrado da Figura 4.18
Figura 4.18: Diagnosticador para a Rotina de Degelo, GdDe f Model
Fonte: Autor
Assim como feito na seo anterior, no intuito de obter uma figura legvel para representao do diagnosticador, os nomes originais
dos eventos foram substitudos por identificadores (IDs) de uma nica
letra, cuja correspondncia mostrada na Tabela 4.2. O estado {3Y } representa a situao em que o diagnosticador est certo da ocorrncia da
falha, e uma vez alcanado este estado, o diagnosticador ali ficar preso,
no sendo possvel retornar para um estado incerto.
114
De maneira anloga aos diagnosticadores obtidos nas sees

anteriores, a condio de diagnosticabilidade no foi violada, uma vez
que o diagnosticador no possui ciclos indeterminados, isto , aps a
ocorrncia da falha o diagnosticador consegue sair deste ciclo de estados incertos. Como pode-se observar na Figura 4.15, aps ocorrncia da
falha independente do estado atual, o autmato sempre alcanar para o
estado de falha, isso no deixar o diagnosticador preso no ciclos formados apenas por estados incertos.
Tabela 4.2: Tabela de Eventos para o Diagnosticador da Rotina de Degelo
Nome do Evento
De f rost _Trigger_True
Ready_to_De f
InitalHeater_ON _TimeComplete
Pulsed _OFF _TimeComplete
Pulsed _ON _TimeComplete
De f _End _Temp
De f _Timeout
De f ExtTime_Complete
DropTime_Complete
Set _Heater_O f f
Set _Heater_On
ID do Evento
A
B
C
D
E
F
G
H
I
J
K
4.4. Projeto dos Diagnosticadores da Camada de Hardware
4.4
115
Projeto dos Diagnosticadores da Camada de Hardware

Na camada de hardware existem dois circuitos importantes para
os quais o diagnstico deve ser considerado: circuito de acionamento do

compressor e circuito de acionamento da resistncia de degelo. Conforme
mencionado anteriormente, ambos so compostos por um circuito de comando do rel e pelo prprio rel. Para fins de diagnstico, tanto a parte
referente ao comando como o rel sero considerados como um dispositivo nico e daqui por diante sero referidos apenas por rels.
Definimos ento o conjunto de falhas pertencente camada de
hardware, como segue:
fhw = {hw1 , hw2 , hw3 , hw4 }

onde:
- hw1 = FailOpen Evento de falha para o rel do compressor travado
aberto;
- hw2 = FailClosed Evento de falha para o rel do compressor travado
fechado;
- hw3 = FailOpen Evento de falha para o rel da resistncia de degelo
travado aberto;
- hw4 = FailClosed Evento de falha para o rel da resistncia de degelo travado fechado;
4.4.1
Diagnosticadores dos Rels

A placa eletrnica usada neste projeto possui um circuito de feed-
back, o qual faz uma amostragem do sinal na sada do rel. Este feedback
pode ento ser usado como um sensor de resposta de acionamento do
rel, podendo assim indicar o estado do rel, aberto ou fechado. Assim,
quando o rel abre e, portanto no h nenhum sinal presente em sua
sada, gerado o evento FB_O f f (feedback de rel desligado), de modo
anlogo, quando o rel fecha, gerado o evento FB_On (feedback de
116
rel ligado). As leituras provenientes deste sensor sero consideradas no

projeto dos diagnosticadores.
Uma vez que ambos os rels (compressor e resistncia de degelo) possuem o mesmo modelo, por simplicidade ser usado um modelo
e um diagnosticador genrico para ambos rels, onde na notao Load_x,
o x deve ser entendido como Compressor ou Resistncia de Degelo para
cada caso. Na Figura 4.19 mostra-se o modelo para os rels e, como se
pode notar, diferentemente dos casos anteriores, este modelo considera
dois tipos de falhas para o rel: FailOpen (Falha de Rel Travado Aberto)
e FailClosed (Falha de Rel Travado Aberto).
Contudo este modelo no possui um conjunto de eventos adequado para o diagnstico, pois conforme mostrado na Figura 4.20, o diagnosticador possui apenas estados incertos, ou seja, com base nos eventos no modelo proposto na Figura 4.19 a ocorrncia das falhas no diagnosticvel. Assim, um mapeamento de sensor (Sampath et al., 1996) se
faz necessrio neste caso. O mapeamento de sensor basicamente consiste em uma tabela que relaciona os estados dos sensores com cada
estado do autmato. Usando as informaes de feedback dos rels, foi
definido o mapeamento de sensor mostrado na Tabela 4.3.
Neste mapeamento, cada estado do rel foi relacionado com os
comandos para ligar e desligar o rel (Set _Load _x_On e Set _Load _x_O f f ,
respectivamente) e seu respectivo feedback (FB_On e FB_O f f ). Assim,
para o estado RELAY _OPEN (rel aberto) por exemplo, tem-se os eventos Set _Load _x_O f f e FB_O f f ], que indicam que o rel foi requisitado
para ser desligado e seu respectivo sinal de feedback detectou que o
mesmo desligou. De modo anlogo no estado RELAY _FAIL_CLOSED
(rel em falha fechado), tem-se a situao onde o rel foi requisitado para
desligar atravs do evento Set _Load _x_O f f , contudo seu respectivo feedback indicou que o mesmo permaneceu ligado gerando ento o evento
FB_On.
O autmato que modela o comportamento dos rels considerando o mapeamento de sensores pode ser visto na Figura 4.21.
4.4. Projeto dos Diagnosticadores da Camada de Hardware
117
Figura 4.19: Autmato que Modela os Rels, GLoad _x_Relay
Fonte: Autor
Os autmatos rotuladores tanto para a falha FailOpen como para

a falha FailClosed so mostrado a seguir na Figura 4.22.
O autmato resultante da composio sncrona do modelo do
rel com ambos autmatos rotuladores pode ser visto na Figura 4.23 e
seu respectivo diagnosticador GdLoad _x = Obs(GMap_Load _x_Relay ||
AlRelayClosed || AlRelayOpen ) na Figura 4.24.
118
Figura 4.20: Diagnosticador para o Modelo GLoad _x_Relay
Fonte: Autor
Tabela 4.3: Mapeamento de Sensor para o Modelo dos Rels

Estado
RELAY _OPEN
RELAY _CLOSED
RELAY _FAIL_OPEN
RELAY _FAIL_CLOSED
4.5
Mapeamento
[Set _Load _x_O f f , FB_O f f ]
[Set _Load _x_On, FB_On]
[Set _Load _x_On, FB_O f f ]
[Set _Load _x_O f f , FB_On]
Projeto dos Diagnosticadores da Camada de Cargas

Esta seo apresenta o projeto dos diagnosticadores para as
duas cargas pertencentes a esta camada: o compressor e a resistncia

de degelo.
Definimos ento o conjunto de falhas pertencente camada de
cargas, como:
fcs = {cs1 , cs2 }

onde:
- cs1 = Comp_Fail Evento de falha do compressor;

- cs2 = Heater_Fail Evento de falha da resistncia de degelo;
4.5. Projeto dos Diagnosticadores da Camada de Cargas
119
Figura 4.21: Autmato que Modela os Rels considerando Mapeamento

de Sensor, GMap_Load _x_Relay
Fonte: Autor
120
Figura 4.22: Autmatos Rotuladores para Falhas de Rel, AlRelayClosed e

AlRelayOpen
Fonte: Autor
4.5.1
Diagnosticador para o Compressor

O autmato que modela o funcionamento do compressor mos-
trado na Figura 4.25 e composto pelos seguintes estados: C_ON (Compressor Ligado), C_OFF (Compressor Desligado) e pelo estado de falha
CS_OFF (Compressor Travado Desligado).
Note que a falha do tipo Travado Ligado no considerada neste
modelo, pois do ponto de vista do compressor (motor), esta falha implicaria em ter o compressor sempre ligado mesmo quando no h tenso
sobre ele (quando o rel que o aciona est desligado), o que no fisicamente possvel de ocorrer. Entretanto, uma falha no circuito de acionamento ou em alguma rotina de software pode fazer com que o compressor fique constantemente ligado. Caso isso ocorra, a origem da falha
no ser o compressor mas sim em algum dos elementos das camadas
superiores, isto , na camada de hardware para o caso de falha de rel
travado fechado, ou na camada software no caso de uma falha na rotina
termosttica ou de controle do compressor por exemplo. Assim, os di-
121
Figura 4.23: Autmato obtido pela composio GMap_Load _x_Relay ||

AlRelayClosed || AlRelayOpen
Fonte: Autor
agnosticadores pertencentes a estas camadas devero detectar a falha.

Contudo, no caso da falha Compressor Travado Desligado, o compressor
permanece desligado mesmo quando alimentado com sua tenso de funcionamento, o que indica que a falha est realmente no compressor e no
em qualquer outro elemento das camadas superiores. Normalmente esta
falha est relacionada a danos fsicos do compressor, como por exemplo,
122
Figura 4.24: Diagnosticador para os Rels, GdL oad _x_Relay
Fonte: Autor
queima na bobina do motor ou de algum dispositivo interno do compressor. O autmato rotulador para este caso mostrado na Figura 4.26.
Para que seja possvel distinguir a falha do compressor da falha
do rel que o aciona, necessrio considerar tambm o modelo do rel
como parte da planta, como mostrado na Figura 4.27.
O diagnosticador obtido a partir dos modelos mostrados nas figuras 4.25 e 4.27, composto somente por estados incertos (ver Figura
4.28), ou seja, a falha no diagnosticvel com base nos modelos propostos.
123
Figura 4.25: Autmato que Modela o Compressor, GComp
Fonte: Autor
Figura 4.26: Autmato Rotulador referente a Falha do Compressor,
AlCompMotorModel
Fonte: Autor
Para contornar este problema, necessrio aplicar o mapeamento de sensores novamente. Uma vez que o sistema possui dois sensores de temperatura, precisamos entender se eles podem prover algum
tipo de informao adicional que seja relevante em termos de diagnstico da falha do compressor e, caso positivo, qual a melhor maneira de se
124
Figura 4.27: Modelo para o Rel do Compressor, GCompRelay
Fonte: Autor
Figura 4.28: Diagnosticador para o modelo (G(Comp ||GCompRelay )
Fonte: Autor
utilizar essa informao no modelo do diagnosticador.

Na Figura 4.29 mostrado o comportamento da temperatura em
diferentes situaes de uso do refrigerador. Neste grfico, vemos o comportamento da temperatura lida pelo Defrost Sensor (Sensor de Degelo),
que est localizado junto ao evaporador do sistema de refrigerao e tambm o comportamento da temperatura lida pelo RC Sensor (Sensor do
Compartimento Refrigerador) localizado dentro do compartimento refrigerador. Como se pode notar, conforme o compressor liga e desliga, o
125
Defrost Sensor possui uma resposta mais rpida s mudanas de temperatura, em relao ao RC Sensor. Assim, por se mostrar mais sensvel
a estas variaes de temperatura, o sensor de degelo se mostra mais
adequado para o mapeamento.
Figura 4.29: Comportamento das Temperaturas do Refrigerador
Fonte: Autor
Ainda, neste grfico pode-se observar o perfil da temperatura em

relao abertura de porta. Mesmo estando o compressor ligado, constantes aberturas de porta fazem a temperatura aumentar. Como o refrigerador provido de circuito de leitura do estado da porta (via feedback do
interruptor de porta), podemos considerar o estado da porta no mapeamento a fim de evitar um erro de interpretao entre a temperatura lida e
o real estado do compressor. O autmato que modela o comportamento
da porta mostrado na Figura 4.30.
Finalmente, o modelo completo para o compressor GC mostrado
126
Figura 4.30: Autmato que Modela o Comportamento da Porta, GDoor
Fonte: Autor
na Figura 4.31, obtido compondo-se os modelos do compressor, do rel

e da porta, ou seja, GC = GComp ||GCompRelay ||GDoor .
A Tabela 4.4 mostra o mapeamento de sensor considerado no
modelo de GC , onde foram mapeados a variao de temperatura sob o
sensor de degelo e o estado da porta. Nesta tabela, Delta+ e Delta- representam uma variao positiva e negativa respectivamente sob o sensor
de degelo. Os estados 4, 6, 7 e 8 referem-se aos estados onde h a falha
do compressor, indicado por CS_OFF . Estes estados esto associados
ocorrncia de uma variao positiva de temperatura Delta+, contudo
esta variao pode ser tambm devido a outros fatores que no a falha
do compressor propriamente dita. No caso do estado 4, esta variao poderia ser devido ao fato de que o rel responsvel por ligar o compressor
est desligado (RELAY _OPEN ). J o estado 8, o aumento da temperatura poderia ser tambm devido a uma abertura de porta (D_OPEN ). Por
fim, o estado 6 representa uma condio onde o aumento de temperatura
somente devido falha do compressor uma vez que o rel de acionamento do compressor est ligado (RELAY _CLOSED) e a porta fechada
(D_CLOSE ).
Aplicando-se o mapeamento de sensores definido na Tabela 4.4
no modelo GC e fazendo a composio sncrona deste com o autmato
127
Figura 4.31: Modelo Final para o Compressor, GC
Fonte: Autor
rotulador AlCompMotorModel , obtm-se o autmato GC _Map, mostrado na

Figura 4.32.
Por fim, o diagnosticador GdComp para o compressor, mostrado
na Figura 4.33, foi obtido calculando-se o observador de GC _Map.
possvel ainda simplificar o diagnosticador obtido agrupando-
128
Figura 4.32: Autmato GC _Map resultante de GC ||AlCompMotorModel
Fonte: Autor
Figura 4.33: Diagnosticador para o Compressor, GdComp
Fonte: Autor
129
130
Tabela 4.4: Mapeamento de Sensor para o Modelo do Compressor

Estado
1 (C_OFF,RELAY _OPEN,D_CLOSE)
2 (C_ON,RELAY _CLOSED,D_CLOSE
3 (C_OFF,RELAY _OPEN,D_OPEN)
4 (CS_OFF,RELAY _OPEN,D_CLOSE)
5 (C_ON,RELAY _CLOSED,D_OPEN)
6 (CS_OFF,RELAY _CLOSED,D_CLOSE)
7 (CS_OFF,RELAY _OPEN,D_OPEN)
8 (CS_OFF,RELAY _CLOSED,D_OPEN)
Mapeamento
[FB_O f f , Delta+]
[FB_On, Delta]
[FB_O f f , Delta+]
[FB_O f f , Delta+]
[FB_On, Delta+]
[FB_On, Delta+]
[FB_O f f , Delta+]
[FB_On, Delta+]
se os estados incertos {3N,7Y} e {5N, 8Y} e tambm {1N,4Y} e {2N,6Y}.

Analogamente para os estados certos 6Y, 8Y , 4Y e 7Y, como mostrado
na Figura 4.34. Contudo, os auto-laos dos estados {(3N,7Y), (5N, 8Y)},
{(1N,4Y), (2N,6Y)} e {6Y,8Y,4Y,7Y} no possuem nenhum efeito do ponto
de vista de diagnstico e podem no entanto ser omitidos do modelo do
diagnosticador deixando-o ainda mais simples, como mostrado na Figura
4.35. Essa simplificao importante e deve ser realizada sempre que
possvel pois ajudar a economizar espao de memria no microcontrolador na fase de implementao, conforme ser discutido no Captulo 5.
4.5.2
Diagnosticador da Resistncia de Degelo

O autmato que modela a resistncia de degelo, mostrado na Fi-
gura 4.36, composto pelos estados H_ON (Resistncia Ligada), H_OFF

(Resistncia Desligada) e H_FAIL (Resistncia em Falha). Note que o estado H_FAIL considera apenas a situao onde a resistncia no ligou
quando era esperado que a mesma ligasse. Quando o diagnosticador
da resistncia detecta uma falha, implica que a falha est realmente na
resistncia e no em algum dos elementos das camadas de hardware
(rel) ou software (rotina de degelo). Em outras palavras, caso a resistncia no esteja fisicamente danificada, mas no observado seu acionamento quando solicitado, isto implica que h uma falha ou no circuito
de hardware responsvel pelo seu acionamento (rel) ou ainda uma falha
131
Figura 4.34: Diagnosticador do Compressor Minimizado, GdCompMin
Fonte: Autor
Figura 4.35: Diagnosticador do Compressor Minimizado e Simplificado,
GdCompMinSimple
Fonte: Autor
132
Figura 4.36: Autmato que modela a Resistncia de Degelo, GHeater
Fonte: Autor
de software (rotina de degelo) e, portanto, os diagnosticadores responsveis por estas falhas devero identific-la. Agora, para o caso onde haja
realmente uma falha na resistncia que faa com a mesma permanea
constantemente desligada mesmo havendo tenso sobre seus terminais,
implica que o diagnosticador da resistncia deve detectar essa falha.
Para que seja possvel distinguir a falha da resistncia da falha
do rel que a aciona, necessrio considerar tambm o modelo do rel
que aciona a resistncia, como mostrado da Figura 4.37.
A composio sncrona entre o modelo da resistncia e de seu
respectivo rel pode ser visto na Figura 4.38.
Este modelo tambm requer um mapeamento de sensor, conforme mostrado na Tabela 4.5. Este mapeamento foi obtido criando-se
um sensor virtual para gerar os eventos referentes rotina de degelo e
tambm usando a informao do sensor de degelo. Este ltimo foi es-
133
Figura 4.37: Autmato que Modela o Rel da Resistncia de Degelo,
GHeaterRelay
Fonte: Autor
colhido por duas razes: primeiro por ser o sensor que est em contado
com o evaporador, que o mesmo lugar onde a resistncia de degelo est
inserida, ento a variao de temperatura neste sensor maior quando
comparada com o outro sensor (RC Sensor ); e segundo por ser este o
sensor que l a temperatura de fim de degelo. Na rotina de degelo foram
mapeados os eventos de incio de degelo (De f _Start ), de degelo finalizado por temperatura (De f _End _By_Temp) e de degelo finalizado por
tempo limite (De f _End _By_Timeout ). J em relao ao sensor de degelo,
sua leitura de temperatura comparada com um valor de referncia Tre f .
Esta referncia se refere mxima temperatura que pode ser alcanada
durante um degelo quando a resistncia no est aquecendo (no est,
portanto, ligada).
O tempo mximo de degelo (DEF_TIMEOUT ) um parmetro
que depende da plataforma do produto, para o refrigerador considerado
neste estudo de caso, este valor definido como 50 minutos. Para definir o valor de Tre f , foi monitorado o comportamento real do refrigerador
durante consecutivos ciclos de degelo, quando a resistncia foi mantida
desligada e portanto todos os degelos tiveram durao de 50 minutos.
Como se pode observar no grfico da Figura 4.39, o sensor de degelo
no registrou temperaturas maiores que -7 C em nenhum dos casos,
134
Figura 4.38: Autmato GH obtido pela composio GHeater ||GHeaterRelay
Fonte: Autor
135
Tabela 4.5: Mapeamento de Sensor para Resistncia de Degelo

Estado
(H _OFF,RELAY _OPEN)
(H _ON,RELAY _CLOSED)
(H _FAIL,RELAY _OPEN)
(H _FAIL,RELAY _CLOSED)
Mapeamento
HeaterRelay_FB_O f f AND
[De f _End _By_Temp OR
De f _End _By_Timeout]
HeaterRelay_FB_On
AND
De f _Start
HeaterRelay_FB_O f f AND
De f _End _By_Timeout AND
De f _End _Temp < Tre f
HeaterRelay_FB_On
AND
De f _Start
Evento
C1
C2
C3
C2
Figura 4.39: Comportamento do Degelo para o Caso de Resistncia Desconectada
Fonte: Autor
assim definiu-se este valor como Tre f .

Na Figura 4.40 mostrado o modelo final da resistncia j considerando o mapeamento de sensor.
136
Figura 4.40: Autmato GH _Map que modela a Resistncia de Degelo considerando Mapeamento de Sensor
Fonte: Autor
137
O autmato rotulador mostrado na Figura 4.41 e o autmato

obtido pela composio sncrona GH _Map ||AlHeater mostrado na Figura
4.42. Finalmente o diagnosticador Gd _Heater da Figura 4.43 obtido
calculando-se Obs(GH _Map ||AlHeater) .
Entretanto, os auto-laos nos estados {1N,3Y},{2N,4Y}, {3Y} e
{4Y}, no possuem nenhum efeito no ponto de vista de diagnstico da
resistncia de degelo e podem portanto ser removidos. Alm disso, os
estados {3Y} e {4Y} podem ser agrupados num estado nico {3Y,4Y},
simplificando assim o modelo do diagnosticador. A Figura 4.44 mostra
o diagnosticador final considerando estas simplificaes.
Figura 4.41: Autmato Rotulador para Falha da Resistncia de Degelo,
AlHeater
Fonte: Autor
138
Figura 4.42: Autmato obtido pela composio GH _Map ||AlHeater
Fonte: Autor
4.6
Neste captulo foi feita uma breve reviso dos conceitos bsicos
relativos ao funcionamento de um refrigerador Frost Free, mostrado seus

principais componentes e a funo que cada um desempenha do sistema. Foi detalhado tambm o comportamento das principais rotinas de
controle de um refrigerador: termosttica e degelo. Em seguida, foi aplicado o sistema de diagnstico multicamadas apresentado do Captulo 3
para o refrigerador proposto neste estudo de caso. Por fim, foi detalhado
o projeto de cada diagnosticador, segundo a teoria de diagnose de falhas
em SEDs proposto por Sampath et al. (1996). Viu-se tambm que em
alguns casos, a fim de se obter um modelo de planta que seja mais ade-
139
Figura 4.43: Diagnosticador da Resistncia de Degelo, GdHeater
Fonte: Autor
Figura 4.44: Diagnosticador Simplificado da Resistncia de Degelo,
GdHeaterSimple
Fonte: Autor
140
quado para a diagnose de falhas, necessrio obter um modelo com o

mapeamento de sensores. Com a obteno de todos os diagnosticadores
propostos, verificou-se que no s possvel dividir o sistema em camadas e projetar diagnosticadores individuais para os elementos de cada
camada como tambm observou-se que o mtodo proposto por Sampath
et al. (1996) tambm aplicvel mesmo quando subdividimos o sistema
(em camadas neste caso) e tambm quando se considera um maior grau
de abstrao do sistema, como o caso dos diagnosticadores da camada
de software, onde as informaes das variveis de software foram consideradas como eventos provenientes de sensores virtuais. O prximo
captulo ser dedicado apresentao de uma metodologia para a implementao do software que modela os diagnosticadores obtidos em
forma de autmatos bem como uma ferramenta para a gerao automtica deste software. Finalmente ser mostrado como esta modelagem se
relaciona com a arquitetura de diagnstico proposta no Captulo 3.
141
5 METODOLOGIA DE IMPLEMENTAO DO SISTEMA

DE DIAGNSTICO MULTICAMADAS
Uma vez projetados os diagnosticadores, o prximo passo consiste em traduzi-los para uma linguagem de software para ento serem
embarcados em um microcontrolador. Esta uma tarefa crtica, pois
necessrio garantir que esta traduo no inclua erros em relao aos
modelos dos diagnosticadores. A fim de garantir um padro na implementao deste software necessrio criar ento um modelo que possa
ser aplicado para qualquer diagnosticador concebido sob a metodologia
de diagnstico de falhas em SEDs. Este captulo apresenta o modelo
desenvolvido para este propsito e que pode ser aplicado arquitetura
multicamadas de diagnstico mostrada no Captulo 3.
5.1
Software de Implementao dos Diagnosticadores

Normalmente o software de um sistema embarcado composto
por um conjunto de pequenas rotinas de software, onde cada uma realiza

uma tarefa especfica e possui o mnimo de dependncia possvel com
as demais. Estas pequenas rotinas, tambm conhecidas como mdulos,
podem ser agrupadas a fim de formarem bibliotecas e so desenvolvidas
de modo que possam ser parametrizadas ou configuradas externamente,
conforme as necessidades da aplicao na qual sero inseridas. Desta
forma, evita-se que o cdigo fonte da biblioteca seja indevidamente alterado, garantindo assim no s a integridade do software como tambm
o reuso destas bibliotecas em outros projetos. Grande parte dos sistemas embarcados so desenvolvidos utilizando linguagem ANSI C (KERNIGHAN e RITCHIE, 1988) como padro (BARR, 2006). Nesta linguagem
comum se estruturar uma biblioteca com os seguintes arquivos:
lib_name.c e lib_name.h: arquivos que implementam os algoritmos cujo

contedo no pode ser alterado;
lib_name_prv.h (cabealho de parmetros privado) e lib_name_prm.h
142 Captulo 5. Metodologia de Implementao do Sistema de Diagnstico Multicamadas
(cabealho de parmetros pblicos): arquivos de cabealhos onde so

inseridos os parmetros e configuraes. Esses arquivos podem ser modificados pelo implementador (usurio da biblioteca).
Retornando ao problema da implementao dos autmatos diagnosticadores em software, para que uma soluo possa ser aplicvel a
qualquer sistema embarcado necessrio que se crie uma biblioteca especfica que seja capaz de manipular qualquer autmato diagnosticador
da mesma maneira, ou seja, um algoritmo nico que gerencie e realize a
evoluo dos estados de cada autmato diagnosticador. Essa biblioteca
deve permitir tambm que as informaes referentes cada autmato
(nome dos estados, nome dos eventos, funo de transio, relao de
eventos ativos, etc) possam ser configurveis externamente segundo um
padro, sem que seja necessrio realizar alteraes no algoritmo principal. importante tambm que essa biblioteca no tenha dependncia
com o tipo do microcontrolador no qual ela ser embarcada, em outras
palavras, a biblioteca no deve acessar diretamente nenhum registrador
ou perifrico do microcontrolador.
Para atender os requisitos acima descritos, proposto neste trabalho um modelo para software em linguagem ANSI C, denominado DAM
(Diagnoser Automata Model), cujo diagrama de classe est representado
na Figura 5.1. O DAM composto pelas bibliotecas Diagnoser Automata
Player e Events.
A biblioteca Diagnoser Automata Player por sua vez composto
pelos seguintes arquivos:
AutomataPlayer.c: Implementa o algoritmo que trata a evoluo dos estados dos autmatos diagnosticadores, conforme a ocorrncia dos eventos, ou seja, l os eventos registrados pelo mdulo Events e atualiza
adequadamente o estado de cada autmato diagnosticador. Este mdulo
tambm implementa o mtodo (funo) para informar quando um autmato diagnosticador chegou a um estado que certo da ocorrncia da
falha;
AutomataPlayer.h: Contm os prottipos das funes pblicas imple-
5.1. Software de Implementao dos Diagnosticadores
143
Figura 5.1: Diagrama de Classe do DAM
Fonte: Autor
mentadas no AutomataPlayer.c para fornecer a API (Application Programming Interface) para os demais mdulos do software;
AutomataPlayer_prv.h: Onde todas as tabelas de estados e transies

para todos os diagnosticadores so implementadas seguindo um formato
de representao padro.
J a biblioteca Events refere-se ao bloco Manipulador de Eventos
mostrado na Figura 3.3 e composto por:
Events.c: Implementa as funes (algoritmos) para ler e adicionar no

buffer os eventos do sistema necessrios para o diagnstico. Tambm
implementa as funes relativas ao mapeamento de sensores, quando
necessrio;
Events.h: Contm a lista de eventos necessria para o diagnstico e

os prottipos (API) das funes usadas para escrever e ler os eventos no
buffer.
A funo "void AutomataPlayer__Handler(void)", mostrada na Figura 5.2, implementa o algoritmo de evoluo dos autmatos diagnosticadores. Esta funo constantemente l os eventos do buffer e atualiza
os estados de todos os autmatos com base nas tabelas definidas em
AutomataPlayer_prv.h. importante ressaltar que esta funo nica e
capaz de manipular at 256 autmatos por vez, ou seja, necessrio implementar (instalar o mdulo AutomataPlayer.c) apenas uma vez, j que
os diagnosticadores esto mapeados em forma de tabela no arquivo de
cabealho AutomataPlayer_prv.h. A limitao ser dada ento pelo espao de memria e capacidade de processamento do microcontrolador
usado.
Figura 5.2: Rotina que Manipula os Autmatos Diagnosticadores
Fonte: Autor
145
O algoritmo mostrado na Figura 5.2 utiliza a tcnica de ponteiro

de funo, onde para cada estado h uma lista de transies que contm
o evento e o estado de destino. Para cada lista h uma transio de fechamento usada para concluir a busca, para esta transio de fechamento
usado um evento desconhecido chamado EVENT_NO_EVENT (MAAS et
al., 2012). Esta lista implementada no arquivo AutomataPlayer_prv.h e
um exemplo de sua estrutura mostrado na Figura 5.3. Como se pode
observar, cada estado do autmato mapeado considerando o conjunto
de eventos associados com o estado atual e o estado destino aps a
ocorrncia de um desses eventos.
Figura 5.3: Formato da Lista de Transies Relativa aos Eventos
Fonte: Autor
Para exemplificar como esta lista funciona, considere a lista Automata_1_State_0_Event_List[], mostrada na Figura 5.3, que mapeia todos
os eventos referentes ao estado 0 do autmato 1, como: OK_TO_DEF,
ABOVE_CP, REQ_COMP_ON, etc. O nmero que aparece ao lado de
cada evento, identifica o estado de destino para o qual o autmato deve
mudar quando ocorrer o evento em questo. Por exemplo, a partir do atual

estado 0, se o evento OK_TO_DEF ocorrer, ento o autmato mudar
para o estado 1.
O algoritmo que manipula as transies dos autmatos diagnosticadores usa uma lista, tambm implementada em AutomataPlayer_prv.h,
que aponta para um dado estado, como mostrado na Figura 5.4.
Figura 5.4: Lista de Estados Relativos a cada Autmato
Fonte: Autor
Assim, supondo que o autmato 1 esteja no estado 0 (isto Automata_1_States[0]), ele estar apontando para a lista Automata_1_State_0_Event_List, que mesma anteriormente mostrada na Figura 5.3.
Quando um novo evento ocorre, o software faz uma busca na lista de
eventos deste estado, caso este evento esteja presente nesta lista, o estado atual torna-se ento o estado de destino, conforme definido na lista
de transio.
Na Figura 5.5 mostrado um exemplo da lista de eventos necessrios para o diagnstico que deve ser implementada no arquivo Events.h.
Esta consiste em uma lista enumerada com definio de tipo (typedef
147
enum), cujo tipo EVENTS_LABEL_DEF.

Figura 5.5: Exemplo de Implementao da Lista de Eventos
Fonte: Autor
Conforme mencionado anteriormente, o Events.c implementa os

algoritmos para remover e adicionar eventos em um buffer, definidos respectivamente pelas funes "unsigned short int Events__GetEvent(void)"
e "void Events__Queue(unsigned short int event)".
Neste mdulo devem ser implementados tambm os algoritmos
para ler os eventos necessrios do sistema e convert-los (caso preciso)
no formato segundo o padro estabelecido na lista de eventos definida no
arquivo Events.h. Na Figura 5.6 mostra-se parte do software que implementa o algoritmo usado para gerar os eventos para o diagnosticador do
Heater, conforme o mapeamento de sensor da Tabela 4.5. Note que, uma

vez que o evento detectado, a funo Events__Queue usada para
adicion-lo ao buffer.
Para que seja possvel externar o estado atual de cada diagnosticador, bem como se algum deles detectou uma falha, h duas funes
implementadas no mdulo AutomataPlayer.c, mostradas na Figura 5.7. A
primeira funo retorna o estado atual para o autmato diagnosticador
informado no parmetro automata. J a segunda funo ir retornar Verdadeiro (TRUE) caso o estado do autmato diagnosticador informado no
parmetro automata for um estado certo de falha, caso contrrio, retornar Falso (FALSE).
5.2
Ferramenta de Gerao Automtica de Cdigo

Conforme mostrado anteriormente, a configurao da biblioteca
Diagnoser Automata Player feita atravs do arquivo AutomataPlayer_prv.h. Este um processo crtico, uma vez que neste arquivo que estaro descritas todas as tabelas de estados e transies dos autmatos
diagnosticadores e o menor erro no preenchimento deste arquivo pode
comprometer o diagnstico. Outro arquivo que precisa ser manualmente
preenchido o Events.h, nele o usurio deve implementar a lista de eventos necessria para o diagnstico. Assim, mais seguro e produtivo ter
uma ferramenta que seja capaz de gerar automaticamente os contedos
destes arquivos a partir dos modelos dos diagnosticadores, tornando o
processo mais robusto. Para este propsito, foi desenvolvida neste trabalho uma ferramenta capaz de gerar automaticamente esses arquivos.
Esta ferramenta, chamada de Doctor Who, mostrada na Figura
5.8, tem como entrada os autmatos diagnosticadores e como sada os
arquivos cabealho AutomataPlayer_prv.h e Events.h. Atualmente os arquivos referentes aos autmatos diagnosticadores devem estar no formato .xmd do programa IDES (2010), usado para projetar o autmato
diagnosticador. importante ressaltar neste momento que, para o correto funcionamento da ferramenta proposta, necessrio que todos os
5.2. Ferramenta de Gerao Automtica de Cdigo
149
Figura 5.6: Parte do Software do Mdulo Events Relativo Implementao do Modelo do Heater
Fonte: Autor
Figura 5.7: Funes que retornam os estado de um dado autmato e

resultado do diagnstico
Fonte: Autor
estados certos (da ocorrncia da falha) do autmato diagnosticador sejam representados como estados marcados, isto , assim que obtido o
diagnosticador Gd , os estados que possuem apenas rtulos Y, devem ser
configurados no IDES como estados marcados.
Esta ferramenta tambm gera os arquivos AutomataPlayer.c e
AutomataPlayer.h, porm esses arquivos no devem ser modificados pelo
usurio pois possuem o cdigo fonte do algortimo que manipula os autmatos diagnosticadores, conforme mencionado anteriormente. O arquivo
Events.c tambm gerado j com as funes "Events__Queue" e
5.3. Aplicao da Metodologia no Estudo de Caso
151
Figura 5.8: Ferramenta de Gerao Automtica de Cdigo
Fonte: Autor
"Events__GetEvent" devidamente implementadas. O usurio ser responsvel apenas por implementar neste arquivo os mtodos necessrios
para obter os eventos do sistema e convert-los (se necessrio) no formato de acordo com o padro definido em Events.h e adicion-los no
buffer, conforme mencionado anteriormente.
Assim, obtemos uma soluo completa para o projeto e implementao dos diagnosticadores para sistemas embarcados. Os diagnosticadores podem ser projetados atravs da teoria de diagnose de falhas
em SEDs, tal como apresentado no Captulo 2 e modelados com auxlio da ferramenta IDES. Por fim, importando-se os arquivos .xmd gerados
pelo IDES na ferramenta Doctor Who gera-se o software em linguagem
ANSI C que permite a implementao dos diagnosticadores junto ao sistema embarcado. O procedimento a ser seguido ilustrado na Figura 5.9.
5.3
Aplicao da Metodologia no Estudo de Caso

Uma vez definidas uma metodologia e uma estrutura para im-
plementao em software tanto dos autmatos diagnosticadores como

do Manipulador de Eventos e, ainda, em posse de uma ferramenta que
Figura 5.9: Sequncia de Projeto e Implementao de Diagnosticadores
Fonte: Autor
153
permite gerar automaticamente estes cdigos, pode-se aplic-la para gerar os cdigos de cada autmato diagnosticador projetado no Captulo 4,
para finalmente embarc-lo no microcontrolador da placa de controle do
refrigerador, juntamente com o cdigo principal do produto. Seguindo a
metodologia mostrada na Figura 5.9, o arquivo .xmd de cada diagnosticador foi importado para ferramenta Doctor Who e os arquivos AutomataPlayer.c, AutomataPlayer.h, AutomataPlayer_prv.h, Events.c e Events.h
foram gerados. Em seguida, foram implementados no arquivo Events.c os
mtodos para obter e adicionar no buffer os eventos necessrios do sistema, conforme listado no arquivo Events.h. Na Figura 5.10 mostrada a
arquitetura de diagnstico completa aplicada ao estudo de caso proposto
neste trabalho. Na camada de cargas tm-se o compressor e a resistncia de degelo, j na camada de hardware os circuitos de acionamentos
destas cargas (rels e circuitos de potncia) e finalmente na camada de
software as rotinas termosttica, degelo e de controle do compressor. O
bloco Interface neste caso composto por um mdulo de software denominado LSI (Load Sensing Interface), que possui as rotinas para realizar
o acionamento das cargas e tambm a leitura dos sensores disponveis
na placa eletrnica. Por se tratar de uma biblioteca proprietria da Whirlpool, por questes de sigilo seu contedo no poder ser mostrado neste
trabalho, contudo tal omisso no representa nus para o entendimento
ou validao desta aplicao. Em seguida tem-se o bloco Manipulador
de Eventos, onde implementado o mdulo Events que por sua vez se
comunica com a camada de sistema de diagnstico, onde esto implementados todos diagnosticadores, atravs da biblioteca AutmataPlayer.
O bloco Gerenciador de Falhas (GF) usado nesta aplicao, tambm de propriedade da Whirlpool, responsvel por monitorar o estado
de cada diagnosticador e caso algum deles atinja um estado certo (da
ocorrncia da falha), ir associar a esta falha um cdigo predefinido e
armazen-lo em uma lista, segundo uma prioridade previamente estabelecida. Esta falha ser ento informada ao bloco SRF (Sistema de Recuperao de Falhas), que por sua vez tomar as aes necessrias para a
recuperao do sistema, caso seja aplicvel a esta falha.
Figura 5.10: Arquitetura de Diagnstico Aplicada ao Estudo de Caso
Fonte: Autor
155
Figura 5.11: Exemplo de Externao de um Cdigo de Falha
Fonte: Autor
A aplicao pode requisitar a qualquer momento ao GF as informaes referentes ao diagnstico. Para o produto utilizado no estudo de
caso, os cdigos de falhas armazenados no GF, podem ser mostrados
para o usurio atravs de uma combinao de LEDs acesos e apagados no painel do produto, conforme mostrado na Figura 5.11, ou ainda
extrados atravs da comunicao serial, utilizando-se um dispositivo especfico desenvolvido pela Whirlpool. Estes dados do diagnstico permitem tanto que o tcnico efetue uma manuteno corretiva mais assertiva
como tambm fornecem informaes equipe de engenharia a fim de
entender o modo de falha e corrigi-los nos projetos seguintes, tornando
os produtos mais robustos.
Assim, temos finalmente a implementao completa da soluo
de diagnstico de falhas multicamadas para sistemas embarcados, proposta neste trabalho.
5.4
Neste captulo foi apresentada uma metodologia para traduzir em
linguagem de software os diagnosticadores projetados segundo a metodologia de diagnose de falhas em SEDs apresentada no Captulo 2. Com
o intuito de obter um software de fcil integrao com software principal
do sistema embarcado e que fosse independente de microcontrolador e
arquitetura usada neste sistema, foi criada uma biblioteca capaz de manipular os autmatos diagnosticadores e os eventos gerados pela planta.
Para essa biblioteca, as tabelas de estado e transies dos autmatos diagnosticadores so lidas atravs de um arquivo de configurao privado
AutomataPlayer_prv.h. Os arquivos desta biblioteca bem como o arquivo
de configurao, podem ser automaticamente gerados atravs da ferramenta de gerao automtica de cdigo Doctor Who. Em seguida esta
metodologia foi aplicada ao estudo de caso mostrado no Captulo 4. Embora a metodologia apresentada, bem como a gerao automtica de cdigo foram desenvolvidas com foco em linguagem C, possvel aplic-las
para outras linguagens, uma vez que sua aplicao independente do
sistema e do microcontrolador utilizado. Atualmente a ferramenta Doctor
Who aceita apenas arquivos do IDES (.xmd), no entanto, isso no uma
restrio, pois pretende-se futuramente atualizar a ferramenta para receber outros formatos de arquivos. Mostrou-se tambm como os arquivos
gerados automaticamente pela ferramenta, bem como os arquivos que
devem ser implementados pelo desenvolvedor, so alocados dentro da
arquitetura de diagnstico proposta no Captulo 3. Por fim, constatou-se
que a arquitetura de diagnstico proposta, juntamente como a soluo
de gerao automtica de cdigo, permitiram embarcar todo o software
necessrio para o diagnstico de maneira rpida, localizada e sem interferncia com o restante do software j existente do refrigerador, garantindo assim integridade dos algoritmos de controle originais. O captulo
seguinte dedicado para a validao tanto dos modelos dos diagnosticadores como tambm da metodologia e da ferramenta de gerao automtica de cdigo para implementao destes diagnosticadores.
157
6 VALIDAO DOS DIAGNOSTICADORES
No captulo anterior mostrou-se que atravs da ferramenta Doctor Who foram gerados os arquivos necessrios com o cdigo em linguagem C, para cada diagnosticador projetado no Captulo 4. Em seguida foram implementados os algoritmos necessrios no mdulo Event.c, para a
gerao dos eventos necessrios para o diagnstico. Uma vez implementados os diagnosticadores, necessrio validar a sua eficcia, ou seja,
verificar se os modelos considerados para constru-los, bem como seu
projeto esto corretos e tambm verificar se no foram introduzidos erros durante a fase de implementao do software, principalmente quando
implementando o mdulo Events.c. Neste captulo sero mostrados as
ferramentas usadas e desenvolvidas para a realizao desta validao,
bem como o processo de validao de cada um dos diagnosticadores
anteriormente projetados.
6.1
Metodologia de Validao
Os arquivos de cdigo C, gerados conforme mostrado no captulo
anterior para os diagnosticadores projetados no Captulo 4, foram compilados juntamente com os demais arquivos que compem o software
principal do refrigerador utilizado no estudo de caso, e posteriormente
embarcado no microcontrolador STM8S105K6 de 8 bits da famlia STM8,
utilizado na placa de controle deste refrigerador.
Na validao do sistema de diagnstico foi utilizado um refrigerador do mesmo tipo do mencionado no estudo de caso. Alm disso, foram
utilizadas duas ferramentas para auxiliar o processo de validao. Com o
objetivo de monitorar e forar algumas condies para se reproduzir algumas das falhas, foi utilizada uma ferramenta que permite o acesso tanto a
variveis e dados internos ao software bem como a manipulao destes
dados em tempo real. Ainda, com a finalidade de prover uma interface
158
Captulo 6. Validao dos Diagnosticadores
grfica do estado de cada diagnosticador, facilitando assim o processo

de validao, foi utilizada uma segunda ferramenta capaz de sincronizar
os diagnosticadores executados dentro do software com seus respectivos
modelos gerados pelo IDES.
Para a validao dos diagnosticadores relativos camada de
software, foram feitas algumas modificaes pontuais no software principal do refrigerador a fim de forar falhas nas rotinas para as quais os
diagnosticadores haviam sido projetados. J para a validao dos diagnosticadores relativos camada de hardware, modificaes em circuitos
da placa de controle foram feitas a fim de reproduzir as condies das
possveis falhas que poderiam ocorrer. Finalmente, para a validao dos
diagnosticadores da camada de cargas, foram simulados as condies
reais de falha em cada uma das cargas.
A seguir ser detalhado o funcionamento das ferramentas utilizadas e em seguida sero apresentados os detalhes referentes validao
de cada um dos diagnosticadores, bem como os resultados obtidos.
6.1.1
Ferramenta de Depurao
Para auxiliar a validao do software foi utilizada a ferramenta
STVD (ST Visual Develop) (STVD, 2010). Esta ferramenta uma IDE
(Integrated Development Environment) fornecida pela STMicroelectronics
para as famlias de microcontroladores ST7 e STM8, que permite o monitoramento e editao online de variveis do software e tambm adicionar
software breakpoints para fins de depurao, conforme ilustrado na Figura 6.1
6.1.2
Ferramenta Automata Player Monitor

Alm do STVD tambm foi utilizada uma ferramenta chamada
Automata Player. Esta ferramenta foi inicialmente desenvolvida em parceria entre Whirlpool e UDESC, voltada aplicao de controle supervisrio. Contudo, esta ferramenta possui um mdulo de monitoramento
6.1. Metodologia de Validao
159
Figura 6.1: Ferramenta STVD
Fonte: Autor
denominado Automata Player Monitor, que devido a sua generalidade do

que diz respeito interface de monitorao, foi possvel utiliz-la tambm
neste trabalho.
Esta ferramenta permite importar um autmato (arquivo no formato .xmd do IDES) e fornece uma interface visual que permite seguir
offline e online a evoluo dos estados deste autmato.
No modo offline, possvel disparar manualmente as transies
de estados (eventos) e a ferramenta automaticamente atualiza o grafo
de estados do autmato e o mostra na janela de interface. J no modo
online necessrio prover uma comunicao serial entre o PC (onde a
ferramenta Automata Player Monitor est sendo executada) e o microcontrolador (onde os diagnosticadores esto implementadas) para assim
acompanhar pela interface a evoluo de estados que ocorre no sistema
embarcado. O mdulo AutomataPlayer.c j possui uma API que permite
enviar por uma interface serial o estado atualizado de cada autmato.
160
Assim, quando no modo online, deve-se importar para esta ferramenta o mesmo arquivo .xmd usado para gerar os arquivos em linguagem
C dos diagnosticadores. Logo, tanto a ferramenta como o microcontrolador tero os mesmos modelos dos autmatos diagnosticadores. Ento,
o algoritmo implementado na funo "AutomataPlayer__Handler" atualizar os estados dos autmatos de acordo com a ocorrncia de eventos,
como discutido antes, e enviar via comunicao serial, usando a API definida, o estado atual de cada autmato diagnosticador. Finalmente, a ferramenta Automata Player ir receber esta mensagem e automaticamente
atualizar o grafo de estados dos autmatos na janela de interface. A ttulo de ilustrao, na Figura 6.2 mostra-se um autmato exibido atravs
desta ferramenta, cujo detalhes so descritos a seguir.
Figura 6.2: Ferramenta Automata Player Monitor
Fonte: Autor
6.2. Validao dos Diagnosticadores: Detalhamento
161
O boto Show Initial State permite reiniciar o autmato para seu

estado inicial. O boto Undo permite desfazer a ltima operao (evento),
quando no modo offline. O campo Graph Orientation permite selecionar
o modo de exibio do autmato entre horizontal e vertical. O campo
Graph Deep permite selecionar a profundidade da alcanabilidade com
qual o autmato deve ser exibido, isto , quantos estados alcanveis a
partir do estado atual devem ser exibidos na janela de interface. O campo
denominado Actual State fornece o estado atual do autmato. A barra localizada do lado esquerdo denominada Actual State Transitions mostra
os eventos ativos para o estado atual, onde os eventos no controlveis
so mostrados na cor vermelha e os eventos controlveis na cor preta.
Quando operando no modo offline, possvel simular a ocorrncia de
qualquer uma destas transies clicando-se sobre a mesma. Na janela
principal mostrado o grafo do autmato, onde as transies referentes
aos eventos no controlveis so mostradas em vermelho e as referentes
aos eventos controlveis mostradas em preto. As linhas cheias representam as transies ativas para o estado atual, enquanto as tracejadas as
transies dos estados futuros.
6.2
Validao dos Diagnosticadores: Detalhamento

Nesta seo ser discutida a abordagem usada para simular e/ou
forar as diferentes falhas a fim de validar os diagnosticadores desenvolvidos. Dependendo da camada para qual o diagnosticador foi projetado,
isto camada de Software, Hardware ou Cargas, uma abordagem diferente foi utilizada, devido suas particularidades, conforme detalhado a
seguir.
6.2.1
Validao dos Diagnosticadores da Camada de Software

Para validar os diagnosticadores desta camada, a abordagem uti-
lizada foi simular (ou forar) a falha atravs da introduo de bugs conhecidos em cada rotina de software para o qual foram desenvolvidos os
diagnosticadores e assim verificar o resultado do diagnstico.
162
A Figura 6.3 mostra um exemplo de um dos bugs propositais utilizados para simular a falha na rotina termosttica. A introduo deste
bug foi feita pela remoo da linha (a mesma foi comentada) responsvel
por mudar o estado da termosttica para o estado TC_COOLING, isso fez
com
que
rotina
termosttica
permanecesse
no
estado
TC_TEMP_SATISFIED (este estado de software refere-se ao estado

TC_SATISF do autmato), mesmo aps a temperatura ficar acima o ponto
de controle (cutin). Assim, a termosttica manteve a solicitao para manter o compressor desligado, quando o mesmo deveria ser solicitado para
ligar.
Para entender melhor este teste, considere que o diagnosticador
da termosttica (ver Figura 4.10) estava no estado {1N, 4Y} e que com
o aumento da temperatura acima do ponto de controle tenha ocorrido o
evento Above_CP, levando o autmato para o estado {2N, 4Y}. Nesta
situao, era esperado que a termosttica requisitasse o ligamento do
compressor atravs do evento Req_Comp_ON, contudo devido ao bug
inserido nesta rotina, a mesma permaneceu no TC_TEMP_SATISFIED
requisitando o desligamento do compressor (evento Req_Comp_OFF ),
levando assim o autmato para o estado {4Y}, tornando-se assim certo
da ocorrncia da falha.
De forma semelhante, para simular uma falha na rotina de controle do compressor foi inserido um bug nesta rotina. Na Figura 6.4 mostrase a mudana feita na linha Compressor_Type[cmpr].State =
COMPRESSOR_ON,
qual
foi
modificada
para
Compressor_Type[cmpr].State = COMPRESSOR_OFF o que forou o

compressor ser desligado quando ele deveria na verdade ter permanecido ligado. O respectivo diagnosticador (ver Figura 4.14) estava inicialmente no estado {3Y, 6N}, que se refere ao estado WAIT_ON. Quando o
tempo de proteo do compressor expirou, ou seja, a condio
Timers__HMSGetStatus(COMPRESSOR_PROTECTION_TIMER) ==
TIMERS_COMPLETED foi satisfeita, o evento CompOn_Prot_Timeout foi
163
Figura 6.3: Insero de Bug na Rotina Termosttica para Validao do

Diagnosticador
Fonte: Autor
ento gerado, mudando o diagnosticador para o estado {3Y, 7N}. Neste

momento, o pedido para manter o compressor ligado ainda estava ativo, o
evento Req_Comp_On deveria ter sido gerado e levado o autmato para
o estado {3Y, 5N}, contudo devido a modificao feita nesta linha do cdigo, o pedido foi para desligar o compressor, o que causou a ocorrncia
do evento Set_Comp_Off. Assim, o diagnosticador mudou para o estado
{3Y} indicando por sua vez a ocorrncia de falha.
164
Figura 6.4: Insero de Bug na Rotina de Controle do Compressor para

Validao do Diagnosticador
Fonte: Autor
A Figura 6.5 mostra um dos bugs inseridos para validar a rotina de degelo. Neste caso, o incio de um novo degelo foi forado enquanto um degelo ainda estava ocorrendo. A linha com Defrost_Trigger =
TRUE foi inserida dentro do estado DROPPING da rotina de degelo. Assim, quando a rotina de degelo atingiu o estado DROPPING, a execuo
da linha Defrost_Trigger = TRUE causou o evento Defrost_Trigger_True,
165
fazendo o diagnosticador de degelo (mostrado na Figura 4.18) mudar do

estado {3Y, 7N} para o estado {3Y}, que um estado certo da ocorrncia
da falha.
Figura 6.5: Insero de Bug na Rotina de Degelo para Validao do Diagnosticador
Fonte: Autor
166
6.2.2
Validao dos Diagnosticadores da Camada de Hardware

Os diagnosticadores dos rels detectam dois tipos de falhas: tra-
vado fechado e travado aberto. Para simular a situao de travado fechado, a entrada e a sada do rel foram curto-circuitadas. J para simular
a falha do rel travado aberto, a bobina do rel foi desconectada do circuito de acionamento, impedindo assim o seu acionamento e mantendo
seus contatos sempre abertos.
No primeiro cenrio, ou seja, rel travado fechado, alterando-se
a temperatura para um valor acima do ponto de controle o compressor foi colocado no estado ligado, fazendo assim o diagnosticador ficar
inicialmente no estado {(3N_FC N_FO),(2Y_FC N_FO),(4N_FC Y_FO)}.
Em seguida, a temperatura foi alterada para um valor abaixo do ponto
de controle, fazendo a termosttica requisitar o desligamento do compressor. Contudo, o mesmo permaneceu ligado devido ao curto-circuito
externo. Neste momento, o feedback do rel continuou indicando que
o mesmo permanecia fechado, o que gerou o evento FB_ON. Por outro lado, o pedido da termosttica para desligar o compressor gerou o
evento Set_Comp_OFF. Estes dois eventos foram detectados pelo diagnosticador, devido ao mapeamento de sensor [Set_Comp_OFF, FB_ON],
levando o diagnosticador para o estado {2Y_FC N_FO} o que indica que o
diagnosticador certo sobre a falha do tipo travado fechado (componente
2Y_FC) e, consequentemente, certo da no ocorrncia da falha do tipo
travado aberto (componente N_FO).
Para o segundo cenrio (rel travado aberto) a temperatura foi
inicialmente ajustada para um valor abaixo do ponto de controle de forma
a manter o rel do compressor aberto. Neste momento, o diagnosticador
estava no estado {(1N_FC N_FO),(2Y_FC N_FO),(4N_FC Y_FO)} como
esperado. Em seguida, a temperatura foi alterada para um valor acima
do ponto de controle, fazendo a termosttica requisitar o ligamento do
compressor, gerando ento o evento Set_Comp_On. No entanto o rel
permaneceu desligado, gerando por sua vez o evento FB_Off. Assim, es-
167
tes dois eventos foram detectados pelo mapeamento de sensor, levando

o diagnosticador para o estado{4N_FC Y_FO}, ou seja, um estado onde
o diagnosticador est certo sobre a ocorrncia da falha do tipo travado
aberto (componente Y_FO) e, consequentemente, certo da no ocorrncia da falha do tipo travado fechado (componente N_FC).
O diagnosticador do rel da resistncia de degelo foi validado
utilizando a mesma abordagem, porm iniciando e terminando ciclos de
degelo para forar a abertura e fechamento deste rel.
6.2.3
Validao dos Diagnosticadores da Camada de Cargas

O modo de falha tanto para resistncia de degelo como para o
compressor um circuito aberto, isto , filamento de aquecimento rompido para o caso da resistncia de degelo e bobina ou rel interno de
partida danificado, no caso do compressor. Assim, ambas as falhas foram
simuladas simplesmente deixando a respectiva carga desconectada da
placa de controle.
O diagnosticador da resistncia de degelo depende dos eventos
C1, C2 e C3, que so uma combinao de eventos HeaterRelay_FB_On,
HeaterRelay_FB_Off, Def_End_By_Temp, Def_End_By_Timeout e Tre f ,
como mapeados na Tabela 4.5. Na Figura 5.6 mostrou-se como os eventos C1, C2 e C3 so gerados pela combinao dos eventos acima citados.
Assim, no incio do degelo tanto a condio Lsi__GetDigitalInput(HEATER_RELAY_FDBK) == RELAY_FEEDBACK_ON quanto a condio Defrost__GetDefrostState() == DEFROST_STATE_DEFROSTING estavam
satisfeitas, o que gerou o evento C2 (veja Figura 5.6). Em seguida, o degelo foi terminado por timeout e a temperatura do Defrost Sensor era menor que -7 C, conforme esperado, de acordo com o grfico apresentado
na Figura 4.39. Assim, as condies Defrost__GetDefrostDuration() >=
DEF_TIMEOUT e Sensor__GetValue(DEF_SENSOR) < (T_REF) foram
satisfeitas (Figura 5.6), o que gerou o evento C3, levando o diagnosticador para o estado certo de falha {3Y,4Y} (Figura 4.44).
168
O diagnosticador do compressor mostrado na Figura 4.35 depende do estado da porta, do sinal de feedback do rel do compressor
e da variao positiva (delta positivo) da temperatura lida pelo sensor
Defrost Sensor. A primeira avaliao feita neste diagnosticador foi mudando o estado da porta entre aberto e fechado, onde se observou na
janela de interface da ferramenta Automata Player, que o diagnosticador
estava mudando entre os estados {(3N,7Y),(5N,8Y)} e {(1N,4Y),(2N,6Y)}
como esperado. Em seguida, mantendo a porta fechada, a temperatura foi
ajustada para um valor acima do ponto de controle, forando o compressor a ligar. Quando o rel do compressor fechou para ligar o compressor,
seu feedback mudou para ligado tambm, gerando o evento FB_ON. No
entanto, o compressor permaneceu desligado, pois o mesmo estava desconectado da placa de controle. Em seguida, a temperatura continuou
se elevando gradativamente. Quando a temperatura aumentou mais de
5 C o evento de delta positivo foi gerado fazendo o diagnosticador mudar
para o estado certo de falha {6Y,8Y,7Y,4Y}, diagnosticando assim a falha
do compressor.
Posteriormente, foi repetido o mesmo teste anterior, entretanto
desta vez a porta foi mantida aberta. Para essa condio a falha do compressor no poderia ser diagnosticada, uma vez que no seria possvel distinguir se o aumento da temperatura era devido ao no ligamento
do compressor ou prpria abertura da porta, conforme descrito anteriormente na Seo 4.5.1. Verificou-se ento que o diagnosticador permaneceu no estado {(3N,7Y),(5N,8Y)}, devido ocorrncia do evento
Door_Opened e mesmo tendo um delta positivo de temperatura, o diagnosticador no detectou falha. No entanto, aps o fechamento da porta
o diagnosticador mudou para o estado {(1N,4Y),(2N,6Y)} e assim que detectou o delta positivo de temperatura, ele finalmente muda para o estado
{6Y,8Y,7Y,4Y}, indicando finalmente a ocorrncia da falha.
6.3
169
Neste captulo foi apresentada a metodologia e as ferramentas
utilizadas para a validao da arquitetura multicamadas de diagnstico.

Os diferentes tipos de falhas foram simuladas atravs de alteraes propositais no software, no hardware e nas cargas. Assim foi possvel verificar a efetividade tanto dos modelos dos diagnosticadores como da implementao em software destes modelos, ou seja, validar tanto o cdigo
automaticamente gerado para o mdulo AutomataPlayer como os algoritmos manualmente implementados no mdulo Event.c, alm de validar
tambm a integrao destes mdulos com o software de controle do refrigerador j existente. A ferramenta Automata Player Monitor permitiu verificar de maneira visual e online a ocorrncia dos eventos e a evoluo dos
estados autmatos diagnosticadores dentro do sistema embarcado. J a
ferramenta STVD auxiliou na depurao do software, permitindo o monitoramento e edio online de variveis. Desta maneira, certificou-se que o
software embarcado para o diagnstico de falhas, conforme a arquitetura
proposta, cumpriu os requisitos esperados do DAM (Diagnoser Automata
Model, ver Figura 5.1), descritos na Seo 5.1 e tambm certificou-se efetividade do cdigo automaticamente gerado pela ferramenta Doctor Who.
171
7 CONCLUSO E TRABALHOS FUTUROS
Neste trabalho foi tratado o problema de diagnstico de falhas

preciso para sistemas embarcados. Para este problema foi proposto um
sistema de diagnstico multicamadas com foco nos principais elementos que compem um sistema embarcado: hardware, software, cargas e
sensores. O objetivo deste sistema prover uma maior descriminao
da origem da falha, tornando assim o diagnstico mais preciso e possibilitando uma ao corretiva mais eficaz. Foram apresentadas tambm as
condies necessrias para que se possa definir o sistema de diagnstico
como um sistema de diagnstico multicamadas determinstico. Para que
fosse possvel embarcar este sistema de diagnstico, foi proposta uma arquitetura que define as interfaces necessrias com o sistema embarcado
(planta) onde se deseja realizar o diagnstico. Esta arquitetura tambm
considera as interfaces tanto para o gerenciamento como para recuperao das falhas. A arquitetura de diagnstico proposta neste trabalho
independente tanto da metodologia usada para o projeto dos diagnosticadores quanto do tipo de microcontrolador onde a mesma ser embarcada,
possibilitando assim sua aplicao em diferentes tipos e modelagens de
sistemas embarcados.
No estudo de caso de um refrigerador Frost Free apresentado
neste trabalho, os diagnosticadores foram projetados no contexto de diagnose de falhas em sistemas a eventos discretos, conforme apresentado por Sampath et al. (1996). Para os autmatos diagnosticadores obtidos segundo esta metodologia, foi ento desenvolvida uma classe de
software, denominada DAM (Diagnoser Automata Player ), composta pelas bibliotecas Diagnoser Automata Player e Events as quais permitiram
embarcar e manipular adequadamente estes autmatos diagnosticadores. Na biblioteca Diagnoser Automata Player os autmatos diagnosticadores so representados por meio de tabelas padronizadas e configurados atravs de um arquivo de parametrizao desta biblioteca (Automata-
172
Captulo 7. Concluso e Trabalhos Futuros
Player_prv.h). Contudo a traduo do autmato para linguagem de cdigo

atravs da configurao destas tabelas no est livre de erros, uma vez
que este um processo manual. Para se resolver este problema, neste
trabalho tambm foi desenvolvida uma ferramenta denominada Doctor
Who, a qual permite a gerao automtica de cdigo para essas tabelas, atravs da importao do arquivo .xmd gerado pelo programa IDES,
usado para modelar o autmato diagnosticador. Esta ferramenta tambm
gera os demais arquivos de cdigo da biblioteca Diagnoser Automata
Player, isto , os aquivos AutomataPlayer.c e AutomataPlayer.h alm da
lista de eventos necessrios para o diagnstico, no arquivo Events.h.
Assim, neste trabalho foi apresentada uma soluo completa para
o diagnstico em sistemas embarcados, deste a arquitetura de diagnstico, a qual prov as interfaces necessrias para a integrao com o sistema embarcado; o sistema de diagnstico multicamadas que permite um
diagnstico mais preciso que o usual; uma metodologia de implementao em software dos diagnosticadores, quando os mesmos so projetados do ponto de vista de SEDs e por fim uma ferramenta para automaticamente gerar este software.
Como possveis continuaes deste trabalho, podem-se citar: (i)
o desenvolvimento do sistema de recuperao (Self Recovery ) ou tolerante falha (Fault-Tolerant) em SEDs, o qual pode ser incorporado na
arquitetura proposta neste trabalho; (ii) a utilizao de diagnosticador robusto para a identificao dos sensores que falharam durante o processo
de diagnose de falhas e (iii) utilizar outra metodologia para o projeto do
diagnosticadores, tal como redes de Petri, a fim de se comparar a complexidade e tamanho do software necessrio para embarcar os diagnosticadores.
173
REFERNCIAS BIBLIOGRFICAS
ATHANASOPOULOU, E., LINGXI, L. e HADJICOSTIS, C. (2010). Maximum likelihood failure diagnosis in finite state machines under unreliable observations, IEEE Transactions on Automatic Control, 2010.
BALEMI, S. Control of Discrete Event Systems: Theory and Applications, Ph.D. Thesis, Swiss Federal Institute of Technology, Zurich, 1992.
BARR, M. Programming Embedded Systems, With C and GNU Development Tools. 2nd Edition, OReilly, 2006, p.21.
BASILIO, J. C. e LAFORTUNE, S. Robust codiagnosability of discrete
event systems, Proceedings of the American Control Conference, St.
Louis, Missouri, 2009, p. 22022209.
BASILIO, J. C. ,CARVALHO, L. K. E MOREIRA, M. V. Diagnose de falhas
em sistemas a eventos discretos modelados por automatos finitos,
Revista Controle & Automao (Impresso), v. 21, p. 510-533, 2010.
BASILIO, J. C., LIMA, S. T. S., LAFORTUNE, S., e MOREIRA, M. V. Computation of minimal event bases that ensure diagnosability. Discrete
Event Dynamic Systems, v. 22, p. 249-292, 2012.
CARVALHO, L. K., BASILIO J.C., MOREIRA, M.V. Robust diagnosability
of discrete event systems subject to intermittent sensor failures. In:
Proc. of 10th international Workshop on Discrete Event Systems, Berlin,
Germany, 2010, p. 9499
CARVALHO, L. K. Diagnose Robusta de Sistemas a Eventos Discretos. Tese (Doutorado em UFRJ COPPE-PEE Programa de Engenharia
Eltrica) - Universidade Federal do Rio de Janeiro, 2011.
CARVALHO, L. K. BASILIO, J. C. , e MOREIRA, M. V. Robust diagnosis
of discrete event systems against permanent loss of observations.
Automatica. Vol. 49, Vol. 1, January 2013, p. 223-231.
174
CASSANDRAS, C. G., LAFORTUNE, S. Introduction to Discrete Event

Systems, 2nd ed. Boston, Kluwer Academic Publishers, 2008.
CONTANT, O., LAFORTUNE, S., TENEKETZIS D. Diagnosability of Discrete Event Systems with Modular Structure. Discrete Event Dynamic
Systems, 2006, 16: 937
CURY, J. E. Teoria de Controle Supervisrio de Sistemas a Eventos
Discretos. V Simpsio de Automao Inteligente, 2001.
DEBOUK, R., LAFORTUNE, S. e TENEKETZIS, D. Coordinated decentralized protocols for failure diagnosis of discrete event systems,
Discrete Event Dynamic Systems: Theory and Applications 10: 3386,
January, 2000.
_____. Embarcados 2014. Introduo: Embarcados Bsico. Disponvel
em: <http://www.embarcadosbasico.wordpress.com>. Acesso em: 15 de
Agosto de 2014.
HALL, ELDON C. Journey to the Moon: The History of the Apollo Guidance Computer. Reston, Virginia, USA: American Institute of Aeronautics and Astronautics, 1996. p. 196.
HALGAMUGE, S. Advanced Methods for Fusion of Fuzzy System and
Neural Networks in Intelligent Data Processing. Fortschr. Ber. VDI
Reihe 10, Nr. 401, VDI-Verlag - Diisseldorf, 1996.
HOPCROFT, J. E., MOTWANI, R., ULLMAN, J. D. Introduction to automata theory, languages, and computation. 3 ed. Boston, Prentice Hall,
2006.
IDES
ase
(Integrated
3
beta
1,
Discrete-Event
September
Systems)
2010
Disponvel
Releem:
<https://qshare.queensu.ca/Users01/rudie/www/software.html>. Acesso
em: 20 de Fevereiro, 2014.
175
ISERMANN, R. Supervision fault-detection and fault-diagnosis

methods-an introduction, Control Eng. Practice, vol. 5, no. 5, pp 639652, 1997.
JESUS, T., C. Diagnosticabilidade e Diagnose On-Line de Falhas de
Sistemas a Eventos Discretos Modelados por Autmatos Finitos.
Dissertao (Mestrado em UFRJ COPPE-PEE Programa de Engenharia
Eltrica) - Universidade Federal do Rio de Janeiro, 2011.
JIANG, S., HUANG, Z., CHANDRA, V. e KUMAR, R. A polynomial algorithm for testing diagnosability of discrete-event systems, IEEE
Transactions on Automatic Control, 2001, 46(8): 13181321.
JIROVEANU, G., BOEL, R.K., e DE SCHUTTER, B. Fault diagnosis for
time Petri nets, In Proc. WODES 06, Ann Arbor - USA, Julho 2006.
KERNIGHAN, B.; RITCHIE, D. The C Programming Language. 2nd. ed.
Englewood Cliffs,New Jersey,USA: Prentice Hall Inc., 1988.
LAFORTUNE, S., TENEKETZIS, D., SAMPATH, M., SENGUPTA, R., e
SINNAMOHIDEEN, K. Failure diagnosis of dynamic systems: An approach based on discrete event systems. Proceedings of the American
Control Conference, Arlington, USA, p. 2058-2071, 2001.
LIEM C. e PAULIN P. Compilation techniques and tools for embedded
processor architectures, Chapter 5. In Hardware/Software Co-Design:
Principles and Practice, eds. J. Staunstrup and W.Wolf, Boston: Kluwer
Academic Publishers, 1998.
LIMA, S. T. Diagnose Robusta de Sistemas a Eventos Discretos Sujeitos Perda Permanente de Sensores. Dissertao (Mestrado em UFRJ
COPPE-PEE Programa de Engenharia Eltrica) - Universidade Federal
do Rio de Janeiro, 2010.
LIMA, S,T., BASILIO, J.C., LAFORTUNE, S., MOREIRA, M.V. Robust diagnosis of discrete-event systems subject to permanent sensor failures. In: Proc. of 10th International Workshop on Discrete Event Systems, Berlin, Germany, 2010, p. 100107, 2010a.
176
LIMA, S,T., BASILIO, J.C., LAFORTUNE, S., MOREIRA, M.V. Bases Mnimas para a Diagnose de falhas de Sistemas a Eventos discretos.
Parte 1: Eventos Essenciais para a diagnose e Trajetrias Primas.
XVIII Congresso Brasileiro de Automtica, Setembro 2010, Bonito-MS,
2010b.
LIN, F. Diagnosability of discrete event systems and its applications,
Journal of Discrete Event Dynamic Systems, v. 4, p. 197212, 1994.
LIN, W. C.,Garcia, H. E., Yoo, T. S. A diagnoser algorithm for anomaly
detection in DEDS under partial and unreliable observations: characterization and inclusion in sensor configuration optimization. Discrete Event Dynamic Systems (2013) 23:6191.
Lunze, J., Schrder, J. (2004). Sensor and actuator fault diagnosis of
systems with discrete inputs and outputs, IEEE Trans. Systems, Man
and Cybernetics, Part B, Vol.34, n. 3, 2004, p. 1096-1107.
MAAS, D. N., LEAL, A. B., PINOTTI, A. J. Sntese e Implementao de
Controle Supervisrio Monoltico para um Ice Maker. XIX Congresso
Brasileiro de Automtica (CBA), Setembro 2012, Campina Grande-PB.
MOREIRA, M. V., JESUS, T. CARVALHO, K. L., BASILIO J. C. Um novo
Algortimo para Verificao da Diagnosticabilidade Descentralizada
de Sistemas a Eventos Discretos. XVIII Congresso Brasileiro de Automtica (CBA), Setembro 2010, Bonito-MS.
QIU W.; KUMAR, R. Decentralized Failure Diagnosis of Discrete Event
Systems, IEEE Transactions on Systems, Man and Cybernetics- Part A:
Systems and Humans, 2005.
RAMADGE, P. J.; WONHAM, W. M. The Control of Discrete Event Systems, Proceedings of IEEE,Vol. 77, n. 1, 1989, p. 81-98.
RIVIERA, M. H. M. Diagnstico de Falhas em Sistemas a Eventos
Discretos: Uma Proposta de Aplicao em Processos de Separao
leo-Gs, Dissertao de Mestrado, COPPE/UFRJ, 2007.
177
ROHLOFF, K. R. Sensor failure tolerant supervisory control, Proc.

and 2005 European Control Conference Decision and Control CDC-ECC
05. 44th IEEE Conference on, Seville, Spain, 2005, p. 34933498.
SAMPATH M., SENGUPTA, R., LAFORTUNE, S. Diagnosability of
discrete-event systems, IEEE Trans. on Automatic Control, v. 40, 1995,
p. 15551575.
SAMPATH M., SENGUPTA, R., LAFORTUNE, S. Failure Diagnosis
Using Discret-Event Models, IEEE Trans. on Automatic Control Systems
Technology, vol 4, 1996, p. 105124.
STVD
(ST
Visual
STM8
MCUs
Develop)
applications,
IDE
for
Setembro
developing
2010
ST7
and
Disponvel
em:
<http://www.st.com/web/catalog/tools/FM147/CL1794/SC1808/SS1767/
PF210567> . Acesso em: 15 de Agosto de 2014.
TEIXEIRA, E. Diagnstico Inteligente de Falhas em um Processo de
Separao leo-Gs em Plataformas Offshore, Dissertao de Mestrado, COPPE/UFRJ, 1993.
WANG, Y., YOO, T. S. e LAFORTUNE, S. Diagnosis of Discrete Event
Systems using Decentralized Architectures, Discrete, Event Dynamic
Systems: Theory and Applications , Vol. 17, No. 2, June 2007, p. 233-263.
WOLF, W., Computers as Components Principles of Embedded Computing System Design, Second Edition, Morgan Kaufmann Publishers
2008, Chapter 1.
ZAD, S. H., KWONG, R. H. e WONHAM, W. M. Fault diagnosis in
discrete-event systems: framework and model reduction, IEEE Transactions on Automatic Control, 2003, p. 11991212.
ZOETEWEIJ, P., PIETERSMA, J., ABREU, R., FELDMAN, A. e GEMUND,
A. J. C. Automated Fault Diagnosis in Embedded Systems, The Second International Conference on Secure System Integration and Reliability Improvement, 2008

Dissertacao Daniel Maas

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dissertacao Daniel Maas

Cargado por

Copyright:

Formatos disponibles

Joinville, 2014

Orientador: Prof. Dr. Andr Bittencourt Leal

Este trabalho apresenta uma arquitetura de

UNIVERSIDADE DO ESTADO DE SANTA CATARINA UDESC

DANIEL GUMIERO NORONHA MAAS

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC

DANIEL GUMIERO NORONHA MAAS

DIAGNSTICO DE FALHAS MULTICAMADAS DE SISTEMAS

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC

DANIEL GUMIERO NORONHA MAAS

DIAGNSTICO DE FALHAS MULTICAMADAS DE SISTEMAS

Dissertao submetida ao Programa

Maas, Daniel Gumiero Noronha

CDD: 621.3 20.ed.

Gostaria de agradecer sobre tudo a Deus por ter me dado foras

Figura 2.1 Exemplo de um Diagrama de Transio de Estados

Figura 4.4 Forma de Onda da Temperatura Durante os Ciclos

Figura 4.6 Sistema de Diagnstico Multicamadas para um Refrigerador

Figura 4.7 Autmato que Modela a Rotina Termosttica, GTC . . 99

Figura 4.13 Autmato resultante de GCompRoutine ||AlCompModel . . . 107

AlDe f Label . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figura 4.24 Diagnosticador para os Rels, GdL oad _x_Relay

Figura 4.25 Autmato que Modela o Compressor, GComp

Figura 4.26 Autmato Rotulador referente a Falha do Compressor, AlCompMotorModel . . . . . . . . . . . . . . . . . . . 123

Figura 4.32 Autmato GC _Map resultante de GC ||AlCompMotorModel 128

Figura 4.36 Autmato que modela a Resistncia de Degelo, GHeater 132

Figura 5.1 Diagrama de Classe do DAM . . . . . . . . . . . . . . 143

Figura 5.3 Formato da Lista de Transies Relativa aos Eventos 145

Figura 5.5 Exemplo de Implementao da Lista de Eventos . . . 147

Tabela 4.1Tabela de Eventos para o Diagnosticador da Rotina do

Tabela 4.4Mapeamento de Sensor para o Modelo do Compressor

Tabela 4.5Mapeamento de Sensor para Resistncia de Degelo . . 135

LISTA DE ABREVIATURAS E SIGLAS

American National Standards Institute

Application Programming Interface

Diagnoser Automata Model

Integrated Development Environment

Integrated Discrete-Event Systems

Liquid Crystal Display

Massachusetts Institute of Technology

Negative Temperature Coefficiente

Sistema a Eventos Discretos

Sistema de Recuperao de Falhas

Conjunto de eventos observveis, o

Conjunto de eventos no-observveis, uo

Conjunto de eventos de falha, f uo

Linguagem gerada por um autmato

Prefixo Fechamento de uma sequncia s

Comprimento de uma sequncia t

Continuao da linguagem L aps uma sequncia s

Conjunto de todas as sequncias de L que terminam

Operador de remoo de eventos de um conjunto

Projeo inversa de elementos de o em 2

Diagnosticador centralizado para o autmato G

Autmato rotulador de falhas

Fundamentos tericos de diagnose de falhas em SEDs . . . 35

Sistemas a Eventos Discretos . . . . . . . . . . . . . . . . 35

Linguagens e Autmatos Determinsticos de Estados Finitos 36

Autmatos Determinsticos de Estados Finitos . . . 40

Operaes com Autmatos . . . . . . . . . . . . . 43

SEDs Parcialmente Observados . . . . . . . . . . . . . . . 50

Diagnose Descentralizada com Coordenao . . . . . . . . 66

2.10 Concluses do Captulo . . . . . . . . . . . . . . . . . . . 70

Proposta de Arquitetura Multicamadas para o Diagnstico