IMPLEMENTAÇÃO DE UM DIAGNOSTICADOR DE FALHA A EVENTOS
DISCRETOS PARA UMA PLANTA DE MANUFATURA CONECTADA AOS
PONTOS DE MEDIÇÃO POR UMA REDE SUJEITA A ATRASOS NA
COMUNICAÇÃO DE EVENTOS
Yuri Gonçalves Ribeiro
Projeto de Graduação apresentado ao Curso
de Engenharia Elétrica da Escola Politécnica,
Universidade Federal do Rio de Janeiro, como
parte dos requisitos necessários à obtenção do
título de Engenheiro.
Orientadores: João Carlos dos Santos Basilio
Gustavo da Silva Viana
Rio de Janeiro
Setembro de 2018
IMPLEMENTAÇÃO DE UM DIAGNOSTICADOR DE FALHA A EVENTOS
DISCRETOS PARA UMA PLANTA DE MANUFATURA CONECTADA AOS
PONTOS DE MEDIÇÃO POR UMA REDE SUJEITA A ATRASOS NA
COMUNICAÇÃO DE EVENTOS
Yuri Gonçalves Ribeiro
PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO
CURSO DE ENGENHARIA ELÉTRICA DA ESCOLA POLITÉCNICA
DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE
DOS REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE
ENGENHEIRO ELETRICISTA.
Examinado por:
Prof. Gustavo da Silva Viana, D.Sc.
Prof. Marcos Vinícius Silva Alves, D.Sc.
Prof. Marcos Vicente de Brito Moreira, D.Sc.
RIO DE JANEIRO, RJ � BRASIL
SETEMBRO DE 2018
Gonçalves Ribeiro, Yuri
Implementação de um Diagnosticador de Falha a
Eventos Discretos para uma Planta de Manufatura
Conectada aos Pontos de Medição por uma Rede Sujeita
a Atrasos na Comunicação de Eventos/Yuri Gonçalves
Ribeiro. � Rio de Janeiro: UFRJ/ Escola Politécnica, 2018.
XIII, 120 p.: il.; 29, 7cm.Orientadores: João Carlos dos Santos Basilio
Gustavo da Silva Viana
Projeto de Graduação � UFRJ/ Escola Politécnica/
Curso de Engenharia Elétrica, 2018.
Referências Bibliográ�cas: p. 102 � 103.
1. Sistemas a Eventos Discretos. 2. Diagnose de Falha.
3. Atraso na Comunicação. I. Basilio, João Carlos dos
Santos et al. II. Universidade Federal do Rio de Janeiro,
Escola Politécnica, Curso de Engenharia Elétrica. III.
Implementação de um Diagnosticador de Falha a Eventos
Discretos para uma Planta de Manufatura Conectada aos
Pontos de Medição por uma Rede Sujeita a Atrasos na
Comunicação de Eventos.
iii
Agradecimentos
Gostaria de agradecer aos meu avôs, avós e demais familiares por todo apoio,
carinho, dedicação e orientações.
Aos meus amigos da faculdade, que tornaram o longo caminho da graduação
muito enriquecedor.
Aos professores, que foram essenciais em mostrar como é feito a ciência e estimu-
lar o pensamento crítico e resolução de problemas, em especial meu orientador João
Carlos dos Santos Basilio, meu coorientador Gustavo da Silva Viana e à professora
Lilian Kawakami Carvalho.
iv
Resumo do Projeto de Graduação apresentado à Escola Politécnica/ UFRJ como
parte dos requisitos necessários para a obtenção do grau de Engenheiro Eletricista.
IMPLEMENTAÇÃO DE UM DIAGNOSTICADOR DE FALHA A EVENTOS
DISCRETOS PARA UMA PLANTA DE MANUFATURA CONECTADA AOS
PONTOS DE MEDIÇÃO POR UMA REDE SUJEITA A ATRASOS NA
COMUNICAÇÃO DE EVENTOS
Yuri Gonçalves Ribeiro
Setembro/2018
Orientadores: João Carlos dos Santos Basilio
Gustavo da Silva Viana
Curso: Engenharia Elétrica
Neste trabalho, um sistema de diagnose de falhas para um planta mecatrônica
robusto a atrasos na comunicação de eventos entre locais de medição e diagnosti-
cadores locais é projetado e implementado. O controlador da planta é projetado a
partir de uma rede de Petri interpretada para controle (RPIC), que é, então, conver-
tida para linguagem Ladder e implementada em um controlador lógico programável.
A partir da RPIC, é desenvolvido um autômato que modela o comportamento da
planta baseado nas leituras dos sensores, medidos os tempos mínimos entre suas
transições e calculados os diagnosticadores robustos e não robustos a atrasos. A
implementação do autômato que modela o comportamento do sistema com falha é
feita em Ladder e os diagnosticadores são implementados em linguagem de controle
estruturada. Após implementados, foram analisados os comportamentos e e�ciência
dos diagnosticadores para diferentes tempos de atrasos nos canais de comunicação.
v
Abstract of Undergraduate Project presented to POLI/UFRJ as a partial ful�llment
of the requirements for the degree of Engineer.
IMPLEMENTATION OF A DISCRETE EVENT FAILURE DIAGNOSER FOR
A MANUFACTURING PLANT CONNECTED TO MEASUREMENTS POINTS
BY A NETWORK SUBJECT TO DELAYS IN EVENT COMMUNICATION
Yuri Gonçalves Ribeiro
September/2018
Advisors: João Carlos dos Santos Basilio
Gustavo da Silva Viana
Course: Electrical Engineering
In this work, a fault diagnosis system for a mechatronic plant that is robust
to delays in the communication of events between measurement sites and local di-
agnosers is designed and implemented. The plant controller has been designed by
using a control interpreted Petri net (CIPN), and then converted to Ladder language
and implemented in a programmable logic controller. From the CIPN, an automa-
ton that models the behavior of the plant based on the sensors readings has been
developed, the minimun time between its transitions are measured and the robust
and nonrobust diagnosers calculated. The implementation of the automaton that
models the system behavior in the presence of faults has been carried onto Ladder
and the diagnosers in structured control language. After implemented, their behav-
iors and e�ciency to diagnosis failures in a networked discrete event system with
timing structure has been analyzed for di�erent delay times in the communication
channels.
vi
Sumário
Lista de Figuras ix
Lista de Tabelas xiii
1 Introdução 1
2 Sistemas a Eventos Discretos 4
2.1 De�nição de Sistemas a Eventos Discretos . . . . . . . . . . . . . . . 4
2.2 De�nições de Linguagens e Notações . . . . . . . . . . . . . . . . . . 5
2.2.1 Operações com Linguagens . . . . . . . . . . . . . . . . . . . . 5
2.3 Autômatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Linguagem Gerada e Marcada por Autômatos . . . . . . . . . 9
2.3.2 Operações com Autômatos . . . . . . . . . . . . . . . . . . . . 10
2.3.3 Autômato com Conjunto de Eventos Parcialmente Observável 13
2.4 Diagnose de Falhas em Sistemas a Eventos Discretos . . . . . . . . . 15
2.4.1 Diagnose de Falhas Centralizadas . . . . . . . . . . . . . . . . 15
2.4.2 Diagnose de Falhas Descentralizadas . . . . . . . . . . . . . . 18
2.4.3 Teste de (Co)Diagnosticabilidade Utilizando o Autômato GSCC 21
2.5 Rede de Petri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.1 Grafo de uma rede de Petri . . . . . . . . . . . . . . . . . . . 24
2.5.2 Marcação de uma rede de Petri . . . . . . . . . . . . . . . . . 25
2.5.3 Dinâmica de uma rede de Petri . . . . . . . . . . . . . . . . . 26
2.5.4 Rede de Petri rotulada . . . . . . . . . . . . . . . . . . . . . . 27
2.5.5 Rede de Petri Estendida . . . . . . . . . . . . . . . . . . . . . 28
2.5.6 Rede de Petri interpretada para controle (RPIC) . . . . . . . 28
3 Problema de Codiagnosticabilidade em Rede Sujeita a Atraso de
Comunicação 32
3.1 Arquitetura do Problema . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Modelo Não Temporizado de um NDESWTS Sujeito a Atrasos na
Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Codiagnosticabilidade de um NDESWTS . . . . . . . . . . . . . . . . 40
vii
3.3.1 Teste de Codiagnosticabilidade de um NDESWTS . . . . . . . 43
4 Planta Mecatrônica Cube Assembly 46
4.1 Controlador Lógico Programável . . . . . . . . . . . . . . . . . . . . . 47
4.1.1 Funcionamento do CLP . . . . . . . . . . . . . . . . . . . . . 47
4.1.2 Linguagem Ladder . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.3 Structured Control Language - SCL . . . . . . . . . . . . . . . 50
4.1.4 Diagrama Ladder a partir de uma RPIC . . . . . . . . . . . . 52
4.1.5 SCL a partir de um Autômato . . . . . . . . . . . . . . . . . . 54
4.2 Módulo 1 - Seleção de Peças . . . . . . . . . . . . . . . . . . . . . . . 56
5 Implementação do Diagnosticador em Rede 59
5.1 Desenvolvimento da RPIC . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Desenvolvimento do Autômato . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Análise da Diagnosticabilidade de L(G) . . . . . . . . . . . . . . . . . 65
5.4 Con�guração Individual dos CLPs no TIA . . . . . . . . . . . . . . . 65
5.5 Conversão de RPIC para Ladder e sua Implementação no CLP . . . . 69
5.6 Implementação de G, em Ladder, e Gd, em SCL . . . . . . . . . . . . 71
5.7 Medição dos Tempos Mínimos de Disparo das Transições do Autômato 72
5.8 Cálculo dos Diagnosticadores Robustos a Atrasos . . . . . . . . . . . 77
5.9 Conexão em Rede dos CLPs . . . . . . . . . . . . . . . . . . . . . . . 81
5.10 Implementação dos Diagnosticadores no CLP S7-1200 . . . . . . . . . 87
5.11 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.12 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6 Conclusões 100
Referências Bibliográ�cas 102
A Pacote DELAY escrito em Python 104
B Códigos em Python Utilizados na Implementação 112
viii
Lista de Figuras
2.1 Diagrama de transição de estados do autômatoG de�nido no Exemplo
2.4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Em (i), encontra-se o autômato G, em (ii) Ac(G), em (iii) CoAc(G)
e, em (iv), Trim(G). . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Exemplo da composição paralelo (iii) e produto (iv) dos autômatos
mostrados em (i) e (ii). . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Autômato G e seu observador, de acordo com o Exemplo 2.7. . . . . . 15
2.5 Autômato diagnosticador do Exemplo 2.8. . . . . . . . . . . . . . . . 18
2.6 Autômato diagnosticador com ciclo indeterminado do Exemplo 2.9. . 18
2.7 Estrutura de um sistema coordenado de diagnose de falha descentra-
lizado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.8 Autômatos diagnosticadores do Exemplo 2.10. . . . . . . . . . . . . . 21
2.9 Autômatos diagnosticadores do Exemplo 2.10. . . . . . . . . . . . . . 21
2.10 Autômatos Gscc do Exemplo 2.12 para o caso diagnosticável. . . . . . 23
2.11 Autômatos Gscc do Exemplo 2.12 para o caso não diagnosticável. . . . 24
2.12 Rede de Petri do Exemplo 2.13. . . . . . . . . . . . . . . . . . . . . . 25
2.13 Rede de Petri marcada do Exemplo 2.14. . . . . . . . . . . . . . . . . 26
2.14 Rede de Petri marcada do Exemplo 2.15. . . . . . . . . . . . . . . . . 26
2.15 Rede de Petri marcada do Exemplo 2.16. . . . . . . . . . . . . . . . . 27
2.16 Rede de Petri rotulada do Exemplo 2.17. . . . . . . . . . . . . . . . . 28
2.17 Rede de Petri estendida do Exemplo 2.18. . . . . . . . . . . . . . . . 29
2.18 Diagrama mostrando o �uxo de dados entre o ambiente externo, o
controlador (RPIC) e a unidade de processamento de dados. . . . . . 30
2.19 Representação grá�ca dos elementos de uma RPIC. . . . . . . . . . . 31
2.20 Exemplo de uma RPIC utilizada para acionar duas lâmpadas. . . . . 31
3.1 Arquitetura do problema de codiagnose de falhas em rede. . . . . . . 33
3.2 NDESWTS = (G, tmin, T ) do exemplo 3.1. Esta �gura foi retirada
de [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 Linha do tempo para a sequência abcn em G e possíveis observações
em LD1 do exemplo 3.1. Esta �gura foi retirada de [1]. . . . . . . . . 35
ix
3.4 Linha do tempo para a sequência bacn em G e possíveis observações
em LD1 do exemplo 3.1. Esta �gura foi retirada de [1]. . . . . . . . . 35
3.5 Autômato G1 do Exemplo 3.2. . . . . . . . . . . . . . . . . . . . . . . 41
3.6 Autômato GNETscc = Gscc1 = Gd1||Gl1 do Exemplo 3.2. . . . . . . . . . 44
4.1 Três metades de cubos disponíveis: da esquerda para a direita são
mostradas as peças de metal, plástico branco e plástico preto. Na
�leira de cima as metades de cubo encontram-se com a concavidade
voltada para baixo, e na �leira abaixo com a concavidade voltada
para cima. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Contato normalmente aberto (a) e contato normalmente fechado (b). 48
4.3 Contato tipo P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4 Bobina simples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 Temporizadores TON (a) e TOF (b). . . . . . . . . . . . . . . . . . . 50
4.6 Exemplo de uma RPIC utilizada para acionar duas lâmpadas. . . . . 52
4.7 Módulo de inicialização do Exemplo 4.6. . . . . . . . . . . . . . . . . 53
4.8 Módulo de eventos do Exemplo 4.6. . . . . . . . . . . . . . . . . . . . 53
4.9 Módulo de condições para o disparo do Exemplo 4.6. . . . . . . . . . 53
4.10 Módulo da dinâmica do Exemplo 4.6. . . . . . . . . . . . . . . . . . . 54
4.11 Módulo das Ações do Exemplo 4.6. . . . . . . . . . . . . . . . . . . . 54
4.12 Autômato utilizado no exemplo 4.7. . . . . . . . . . . . . . . . . . . . 55
4.13 Módulo 1 da planta mecatrônica, responsável pela seleção de peças
por meio de sensores. Conta com 2 armazéns verticais, um painel de
operações, esteira e um conjunto de sensores posicionados sobre ela. . 56
5.1 Estrutura de diagnóstico de falha em rede implementada. . . . . . . . 60
5.2 RPIC utilizada para modelar o controlador do módulo 1 da planta
mecatrônica. As cores representam os diferentes caminhos que podem
ser seguidos pela rede. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Autômato obtido a partir da RPIC contendo somente eventos da
planta mecatrônica e considerando uma possível falha no sensor óp-
tico por re�exão (cor ↑). A legenda dos eventos encontra-se na Tabela
5.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.4 Diagnosticador Gd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Adicionando novo dispositivo no TIA. . . . . . . . . . . . . . . . . . . 67
5.6 Device overview do CLP S7-300 ao �m de sua con�guração. . . . . . 68
5.7 Con�guração do IP e Máscara de sub-rede do PC. . . . . . . . . . . . 68
5.8 Tag table utilizadas no CLP S7-300. . . . . . . . . . . . . . . . . . . . 69
5.9 Function utilizadas para implementar a RPIC no CLP S7-300. . . . . 70
5.10 Parte do módulo de inicialização implementado no CLP S7-300. . . . 70
x
5.11 Parte do módulo de eventos implementado no CLP S7-300. . . . . . . 70
5.12 Array contendo 3 elementos do tipo bool. . . . . . . . . . . . . . . . . 71
5.13 Parte do autômato representada em Ladder. . . . . . . . . . . . . . . 72
5.14 Autômato G com transições numeradas. . . . . . . . . . . . . . . . . 73
5.15 B loco TIME_TCK utilizado para marcar tempo no CLP S7-300. . . 73
5.16 Function SubtrairTime utilizada para subtrair duas variáveis do tipo
Time, guardar os tempos mínimos medidos e atualizar a variável
"MS".TempoAnterior. . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.17 B loco Ladder que executa a Function SubtrairTime. . . . . . . . . . . 75
5.18 Lógica implementada no Ladder para medir os tempos mínimos entre
transições. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.19 Exemplo dos tempos mínimos medidos em um dos testes realizados
na planta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.20 Autômato G com os tempos mínimos, em milissegundos, entre as
transições. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.21 Estrutura em rede implementada. . . . . . . . . . . . . . . . . . . . . 78
5.22 Autômato G1S2obtido com o DESLab. . . . . . . . . . . . . . . . . . 79
5.23 Autômato Gd1,S2obtido com o DESLab. . . . . . . . . . . . . . . . . 80
5.24 Topologia de rede em estrela implementada. O terminal (PC) e os
CLPs S7-1200 e S7-300 se comunicam através do switch CSM-1277. . 81
5.25 Aba Topology view no software TIA após conexão dos CLPs. . . . . . 82
5.26 De�nindo uma table no TIA. . . . . . . . . . . . . . . . . . . . . . . . 82
5.27 Representação do bloco ATT no TIA. . . . . . . . . . . . . . . . . . . 83
5.28 Representação do bloco FIFO no TIA. . . . . . . . . . . . . . . . . . 83
5.29 Representação do bloco PUT no TIA. . . . . . . . . . . . . . . . . . 84
5.30 Con�guração dos parâmetros de conexão do bloco PUT no TIA. . . . 85
5.31 "Clock" de 50 ms feito com Temporizador TON. . . . . . . . . . . . . 85
5.32 Adição do bloco ATT ao Ladder do autômato G. . . . . . . . . . . . 86
5.33 Bloco FIFO implementado no Ladder. . . . . . . . . . . . . . . . . . 86
5.34 Data block responsável por receber informações no diagnosticador local. 87
5.35 Bloco PUT responsável por enviar informações ao diagnosticador local. 88
5.36 Identi�car evento de acordo com o número inteiro recebido. . . . . . . 88
5.37 Utilização do bloco TP para simular atraso no evento cor ↑ (parte 1de 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.38 Utilização do bloco TP para simular atraso no evento cor ↑ (parte 1de 2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.39 Utilização do bloco MOVE e entradas %I0.0 e %I0.1 para selecionar
o tempo de atraso simulado. . . . . . . . . . . . . . . . . . . . . . . . 90
xi
5.40 Exemplo de watch table utilizada para visualizar a situação dos diag-
nosticadores em relação à ocorrência do evento de falha. . . . . . . . 90
5.41 D iagnóstico de falhas para o caso sem atraso e sem falha no sensor
de cor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.42 D iagnóstico de falhas para o caso com atraso de 3300 ms e sem falha
no sensor de cor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.43 D iagnóstico de falhas para o caso com atraso de 3300 ms e com falha
no sensor de cor (parte 1). . . . . . . . . . . . . . . . . . . . . . . . . 94
5.44 D iagnóstico de falhas para o caso com atraso de 3300 ms e com falha
no sensor de cor (parte 2). . . . . . . . . . . . . . . . . . . . . . . . . 94
5.45 D iagnóstico de falhas para o caso com atraso de 3300 ms e com falha
no sensor de cor (parte 3). . . . . . . . . . . . . . . . . . . . . . . . . 94
5.46 D iagnóstico de falhas para o caso com atraso de 3300 ms e com falha
no sensor de cor (parte 4). . . . . . . . . . . . . . . . . . . . . . . . . 95
5.47 D iagnóstico de falhas para o caso com atraso de 7500 ms e sem falha
no sensor de cor (parte 1). . . . . . . . . . . . . . . . . . . . . . . . . 95
5.48 D iagnóstico de falhas para o caso com atraso de 7500 ms e sem falha
no sensor de cor (parte 2). . . . . . . . . . . . . . . . . . . . . . . . . 96
5.49 D iagnóstico de falhas para o caso com atraso de 7500 ms e com falha
no sensor de cor (parte 1). . . . . . . . . . . . . . . . . . . . . . . . . 96
5.50 D iagnóstico de falhas para o caso com atraso de 7500 ms e com falha
no sensor de cor (parte 2). . . . . . . . . . . . . . . . . . . . . . . . . 97
5.51 D iagnóstico de falhas para o caso com atraso de 7500 ms e com falha
no sensor de cor (parte 3). . . . . . . . . . . . . . . . . . . . . . . . . 97
5.52 D iagnóstico de falhas para o caso com atraso de 7500 ms e com falha
no sensor de cor (parte 4). . . . . . . . . . . . . . . . . . . . . . . . . 98
5.53 Resultado do ensaio E7. . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.54 Table utilizada para acompanhar a evolução dos estados do autômato
G mostrado na Figura 5.3. . . . . . . . . . . . . . . . . . . . . . . . . 99
xii
Lista de Tabelas
5.1 Legendas dos eventos associados aos sensores da Rede de Petri mos-
trada na Figura 5.2. Entre parênteses encontra-se a abreviatura uti-
lizada nas transições dos autômatos. . . . . . . . . . . . . . . . . . . 61
5.2 Legendas das ações associadas aos lugares da Rede de Petri mostrada
na Figura 5.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3 Relação entre os números inteiros e os eventos do autômato. . . . . . 85
5.4 Dados a respeito da diagnosticabilidade e atrasos máximos de projeto. 91
5.5 Dados de projeto dos diagnosticadores que serão submetidos aos tes-
tes. Vale ressaltar que Gd implementado no S7-300 não está sujeito a
atrasos de comunicação. No S7-1200, todos os diagnosticadores estão
sujeitos aos atrasos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.6 Dados a respeito dos ensaios que os diagnosticadores serão submetidos. 91
xiii
Capítulo 1
Introdução
Os sistemas que possuem espaço de estados discreto e têm a evolução dirigida por
eventos são chamados de sistemas a eventos discretos (SEDs). Nesses sistemas, os
eventos são caracterizados por uma ocorrência instantânea, tal como a mudança de
estado de um sensor ou o apertar de um botão por um operador [2]. Para modelar
SEDs, os formalismos matemáticos frequentemente utilizados são autômatos e redes
de Petri. Dentre os eventos considerados, existem os chamados eventos de falha, os
quais podem levar o sistema a um comportamento indesejado, sem, contudo, inter-
romper o seu funcionamento de imediato. Esse tipo de evento é considerado não
observável, caso contrário a sua ocorrência poderia ser instantaneamente diagnosti-
cada.
O diagnóstico da ocorrência de eventos de falhas em SEDs representa um im-
portante tema de pesquisa, que vem sendo bastante explorado em razão de sua
potencialidade para aplicação em sistemas industriais e por ter produzido, ultima-
mente, resultados signi�cativos [3]. Informalmente, diz-se que um evento de falha
é diagnosticável se a sua ocorrência puder ser detectada após a ocorrência de um
número limitado de eventos observáveis. Na literatura, a questão da diagnosticabi-
lidade é abordada utilizando-se autômatos diagnosticadores ou veri�cadores tanto
para as arquiteturas centralizadas quanto para as descentralizadas.
Ultimamente, sistemas de automação têm �cado cada vez mais independentes da
interação humana e cada vez mais integrados e descentralizados. A integração dos
sistemas pode ser obtida pela conexão em rede de seus componentes, de modo que
eles interajam objetivando executar determinadas tarefas, e tem sido cada vez mais
demandada, visto que plantas industriais modernas podem ser grandes e �sicamente
distribuídas, sendo desejável, de certa forma, que seus componentes operem de forma
sincronizada.
Muitos trabalhos na área de diagnóstico de falhas em SEDs supõem que a infor-
mação recebida pelos diagnosticadores não sofre atrasos de comunicação, como os
diagnosticadores centralizado e descentralizado apresentados em [4] e [5], respecti-
1
vamente. Contudo, devido à complexidade das plantas industriais, diagnosticadores
são comumente implementados utilizando a arquitetura descentralizada em conjunto
com redes de comunicação que, inevitavelmente, estão sujeitas a atrasos na trans-
missão de dados.
Para lidar com o problema da codiagnosticabilidade de sistemas a eventos discre-
tos temporizados em rede (NDESWTS, do inglês Networked Discrete Event Systems
With Timing Structure) sujeitos a atrasos e perdas de observação de eventos entre
os locais de medição (MS, do inglês Measurement Site) e os diagnosticadores locais
(LD, do inglês Local Diagnoser), utiliza-se a teoria e algoritmos apresentados em
[1], [6] e [7].
Em NDESWTS, o modelo temporizado representa o comportamento do sistema
dinâmico da planta com base no conhecimento a priori do tempo de disparo mínimo
para cada transição da planta e dos atrasos máximos nos canais de comunicação que
ligam MS a LD. Converte-se, então, esse modelo temporizado em um novo modelo
não temporizado e, com base no modelo não temporizado, podem ser veri�cadas
condições necessárias e su�cientes para a codiagnosticabilidade de NDESWTS, uti-
lizando tanto diagnosticadores quanto veri�cadores. A proposta deste trabalho é
testar esse método em uma planta real, simulando diferentes tempos de atrasos,
de modo que seja possível estabelecer comparações entre a e�cácia do diagnóstico
de falha utilizando diagnosticadores robustos e não robustos a atrasos. Para esse
�m, é utilizada a planta mecatrônica do Laboratório de Controle e Automação da
Universidade Federal do Rio de Janeiro.
A modelagem do controlador, considerando-se apenas o comportamento normal
da planta, é feita utilizando-se Redes de Petri Interpretadas para Controle (RPIC),
e o comportamento normal e de falha do sistema controlado são modelados por um
autômato, chamado de G, que evolui de acordo com a ocorrência de eventos associ-
ados ao sensores da planta. Em seguida, a RPIC e o autômato G são convertidos
em diagramas Ladder e, então, implementados em um controlador lógico programá-
vel (CLP) da Siemens. Feito isso, são medidos os tempos mínimos para ocorrência
das transições desse autômato e, ao se estabelecer um tempo máximo de atraso na
comunicação, os diagnosticadores robustos a atrasos são gerados, em linguagem de
controle estruturada (SCL, do inglês Structured Control Language), a partir de um
código escrito em linguagem Python. Em seguida, os CLPs utilizados para simular
os locais de medição e o diagnosticador local são conectados em rede e diferentes
tempos de atrasos na comunicação dos eventos observáveis são simulados para que
seja possível observar o comportamento dos diagnosticadores nessas situações.
De forma similar, (BLANCO [8], 2017) implementa um diagnosticador robusto
a atrasos a partir da teoria desenvolvida em [9]. A principal diferença entre os
métodos implementados em [8] e neste trabalho consiste no meio utilizado para
2
quanti�car o atraso: em [6], ele é quanti�cado pelo tempo, ao passo que, em [9], ele
é quanti�cado pelo número máximo de eventos que podem ocorrer antes do evento
que está atrasado ser comunicado com sucesso ao LD.
Este trabalho está dividido da seguinte forma: no capitulo 2, são apresentados
os fundamentos teóricos; no capítulo 3, é formulado o problema da codiagnosti-
cabilidade em rede sujeita a atrasos de comunicação; no capítulo 4, são passados
fundamentos básicos a respeito do funcionamento do CLP e da planta mecatrônica;
no capítulo 5, é detalhada a forma como se deu a implementação dos diagnosti-
cadores e analisados os seus comportamentos para diferentes tempos de atraso na
comunicação dos eventos; por �m, no capítulo 6, é apresentada a conclusão deste
trabalho.
3
Capítulo 2
Sistemas a Eventos Discretos
Neste capítulo são apresentados os fundamentos teóricos em sistemas a eventos dis-
cretos necessários à compreensão e elaboração deste trabalho. Para tanto, este
capítulo está estruturado como segue: na seção 2.1, é apresentada a de�nição de
sistemas a eventos discretos. Na seção 2.2, são apresentados as de�nições de lingua-
gens e as notações utilizadas. Nas seções 2.3 e 2.4 são abordados os fundamentos
de autômatos e da diagnose de falhas, respectivamente. Por �m, na seção 2.5, são
abordados os fundamentos das Redes de Petri.
2.1 De�nição de Sistemas a Eventos Discretos
Sistemas são, de uma forma geral, componentes combinados pela natureza ou pelo
ser humano que interagem para executar uma função que não seria possível com
apenas um dos componentes individualmente [2]. Os sistemas a serem considerados
neste trabalho são conhecidos como sistemas a eventos discretos (SEDs). Tais sis-
temas percebem ocorrências do mundo externo através de estímulos, denominados
eventos, que podem ser identi�cados como uma ação especí�ca (alguém aperta um
botão, por exemplo), uma ocorrência espontânea (um sistema sai do ar sem motivos
claros, por exemplo) ou o resultado de vários condições que são satisfeitas ao mesmo
tempo (um tanque transborda, por exemplo).
Em geral, a ocorrência de um evento causa uma mudança interna no sistema, que
pode ou não se manifestar a um observador externo, e que são caracterizadas por
serem instantâneas, ou seja, ao perceber a ocorrência de um evento, o sistema reage
imediatamente e se acomoda em tempo nulo a um novo estado, no qual permanece
até que ocorra um novo evento. Dessa forma, é necessário que ocorram eventos para
que o sistema evolua.
Como a ocorrência de eventos pode depender de fatores externos ao sistema, que
podem ser imprevisíveis, um SED pode ser de�nido como um sistema cujo espaço de
estados é discreto e que evolui com a ocorrência de eventos em intervalos de tempo
4
em geral irregulares e desconhecidos. Por analogia, o conjunto discreto de eventos
de um SED é dito ser seu alfabeto, as sequências de eventos formam as palavras e
o conjunto de todas as palavras é dito ser a linguagem do sistema.
Em razão de equações diferenciais convencionais não serem adequadas para des-
crever SEDs, foram desenvolvidos formalismos matemáticos capazes de representar
corretamente sua evolução. Apesar do comportamento de um SED poder ser des-
crito pela sua linguagem, esta nem sempre é uma forma prática de se especi�car um
desempenho desejado de se lidar. Em outras palavras, é necessário o uso de estru-
turas compactas capazes de de�nir linguagens e de serem manipuladas de forma a
possibilitar a realização de operações bem de�nidas, objetivando construir, mani-
pular e analisar linguagens arbitrariamente complexas. Neste trabalho, utilizam-se
dois formalismos largamente utilizados para descrever SEDs: autômatos e redes de
Petri. As redes de Petri são utilizadas para o controle da planta, e os autômatos
para a diagnose de falhas.
2.2 De�nições de Linguagens e Notações
Neste trabalho, o conjunto de eventos de um SED será denotado por Σ e um evento
genérico de Σ será denotado por σ. O comprimento de uma palavra s, denotado por
||s||, é o número de eventos contidos nela, levando em conta múltiplas ocorrências de
um mesmo evento. Uma palavra vazia, ou seja, sem eventos, é denotada por ε e seu
comprimento, por convenção, é zero. A de�nição formal de linguagem é apresentada
como em [2].
De�nição 2.1 (Linguagem) A linguagem L, de�nida sobre um conjunto de even-
tos Σ, é um conjunto de palavras de comprimento �nito formadas a partir dos even-
tos em Σ.
Exemplo 2.1 Seja Σ = {a, b, c} um conjunto de eventos. Duas possíveis linguagens
formadas com eventos de Σ, denotadas por L1 e L2, são L1 = {ε, a, ab, bc} e L2 =
{Todas as palavras de comprimento igual a 3 terminando com o evento b}.
Vale ressaltar que linguagens são conjuntos e, portanto, todas as operações aplicáveis
a conjuntos também são aplicáveis às linguagens.
2.2.1 Operações com Linguagens
A principal operação relacionada à construção de palavras a partir de um con-
junto de eventos Σ e, por conseguinte, relacionada à construção de linguagens, é a
concatenação. Considere, por exemplo, a palavra abg, formada com os eventos de
5
Σ = {a, b, g}. A palavra abg pode ser formada pela concatenação da palavra ab com
o evento g. Note que a palavra ab é a concatenação dos eventos a e b. A palavra
vazia ε é o elemento identidade da operação de concatenação, ou seja, σε = εσ = σ,
sendo σ um evento genérico. O conjunto de todas as possíveis palavras de compri-
mento �nito formadas por elementos de Σ, incluindo a sequência vazia ε, é denotado
por Σ∗. Essa operação ∗ é chamada de fecho de Kleene. Uma linguagem de�nida
sobre um conjunto de eventos Σ é um subconjunto de Σ∗ e, em particular, ∅, Σ e
Σ∗ são linguagens.
A concatenação e o fecho de Kleene também podem ser de�nidos para linguagens,
como mostrado a seguir.
De�nição 2.2 (Concatenação) Sejam as linguagens L1, L2 ⊆ Σ∗. Então, a
concatenação L1L2 é de�nida da seguinte forma:
L1L2 = {s = s1s2 : (s1 ∈ L1) e (s2 ∈ L2)}.
Uma palavra s estará contida em L1L2 se ela for formada pela concatenação da
palavra s1 ∈ L1 e s2 ∈ L2.
De�nição 2.3 (Fecho de Kleene) O fecho de Kleene de uma linguagem L ⊆ Σ∗,
denotado por L∗, é de�nido como:
L∗ = {ε} ∪ L ∪ LL ∪ LLL ∪ ...
Um elemento de L∗ é formado pela concatenação dos elementos de L. Por de�nição,
a palavra vazia ε é também um elemento de L∗.
Outra operação importante que pode ser aplicada às linguagens é o fecho de
pre�xo. Antes de apresentar esta operação, é necessário de�nir pre�xo, subsequência
e su�xo de uma palavra s. Seja s = tuv, com t, u, v ∈ Σ∗. Então, t é um pre�xo, u
uma subsequência e t um su�xo de s. Observe que ε e s são pre�xos, subsequências
e pre�xos de s. Além disso, é usada a notação s/t (lê-se s após t) para denotar o
su�xo de s após o pre�xo t. Se t não for um pre�xo de s, então s/t não é de�nida.
A de�nição formal de fecho de pre�xo é apresentada a seguir.
De�nição 2.4 (Fecho do Pre�xo) O fecho do pre�xo de uma linguagem L ⊆ Σ∗,
denotado por L, é de�nido como:
L = {s ∈ Σ∗ : (∃t ∈ Σ∗)[st ∈ L]}.
De acordo com a de�nição, o fecho de pre�xo de uma linguagem L é o conjunto de
todos os pre�xos de todas as palavras de L. Por de�nição, L ⊆ L. Uma linguagem
6
L é dita ser pre�xo fechada se L = L, isto é, se todos os pre�xos de todas as palavras
de L também são elementos de L.
Exemplo 2.2 Sejam L1 = {a, b, ab, aab, abab} e L2 = {c} duas linguagens e Σ =
{a, b, c} o conjunto de eventos, temos que:
L1L2 = {ac, bc, abc, aabc, ababc}
L1 = {ε, a, b, ab, aa, aab, aba, abab}
L∗2 = {ε, c, cc, ccc, ...}
Outra importante operação é a projeção natural, de�nida a seguir.
De�nição 2.5 (Projeção) A projeção natural P : Σ∗l → Σ∗s, sendo Σs ⊂ Σl, é
de�nida recursivamente como segue:
P (ε) = ε,
P (σ) =
{σ, se σ ∈ Σs,
ε, se σ ∈ Σl\Σs
,
P (sσ) = P (s)P (σ), para todo s ∈ Σ∗l , σ ∈ Σl,
na qual \ denota a operação de diferença de conjuntos.
Por de�nição, a projeção natural apaga todos os eventos σ ∈ Σl\Σs das palavras
s ∈ Σ∗l . A operação de projeção inversa é de�nida a seguir.
De�nição 2.6 (Projeção Inversa) A projeção inversa P−1 : Σ∗s → 2Σ∗l é de�nida
como segue:
P−1(t) = {s ∈ Σ∗l : P (s) = t}.
Note que, de acordo com a de�nição 2.6, para um dada palavra t, formada por
eventos de Σs, a projeção inversa P−1(t) produz um conjunto com todas as palavras
possíveis de serem construídas com os eventos de Σl cujas projeções são iguais a
t. As operações de projeção e projeção inversa podem ser estendidas a linguagens.
Para tanto, é necessário que se apliquem essas operações a todas as palavras que
pertençam à linguagem.
7
Exemplo 2.3 Seja Σl = {a, b, c, d}, Σs = {c, d} e a linguagem L =
{ε, a, b, c, d, ab, abc, abcd, dccb} ∈ Σ∗l . Considere a projeção P : Σ∗l → Σ∗i e a projeção
inversa P−1 : Σ∗s → 2Σ∗l . Temos que:
P (L) = {ε, c, d, cd, dcc}
P ({ε, acbddc}) = {ε, cddc}
P−1({ε}) = {a, b}∗
P−1({cd}) = {a, b}∗{cd}{a, b}∗
A seguir, é apresentada uma breve revisão da teoria de autômatos.
2.3 Autômatos
Um autômato é um dispositivo capaz de representar linguagens de acordo com regras
bem de�nidas [2]. A de�nição formal de autômato é apresentada a seguir.
De�nição 2.7 (Autômato) Um autômato determinístico, denotado por G, é uma
sêxtupla
G = (X,Σ, f,Γ, x0, Xm),
na qual X é o conjunto de estados, Σ é o conjunto de eventos, f : X × Σ → X é
a função de transição de estados, Γ : X → 2Σ é a função de eventos ativos, x0 é o
estado inicial e Xm é o conjunto de estados marcados.
A evolução de um autômato pode ser determinada pela sua função de transição.
Suponha que um autômato esteja inicialmente no estado xi e que, quando ocorre
um evento σ, o sistema mude instantaneamente para o estado xi+1. Essa evolução
é descrita pela função de transição da seguinte forma: f(xi, σ) = xi+1. A função de
eventos ativos é o conjunto de todos os eventos σ para os quais f(x, σ) está de�nida;
então, para que f(xi, σ) = xi+1 seja de�nida, é necessário que σ ∈ Γ(xi).
Um autômato pode ser representado gra�camente por um grafo orientado cha-
mado de diagrama de transição de estados. Os estados dos autômatos são represen-
tados por círculos, formando os vértices do grafo, e as transições são representadas
por arcos orientados conectando os estados e rotulados com os eventos de Σ que
causam a transição de estados. Para representar o estado inicial do autômato, é in-
serido um um arco, que não possui um estado de origem, chegando a ele. O exemplo
de um autômato é apresentado a seguir.
8
x1 x3x2σ2σ1
σ1 σ3
Figura 2.1: Diagrama de transição de estados do autômato G de�nido no Exemplo2.4.
Exemplo 2.4 Seja G um autômato cujo diagrama de transição de estados é mos-
trado na Figura 2.1. O conjunto de estados de G é dado por X = {x1, x2, x3}, e seuconjunto de eventos é dado por Σ = {σ1, σ2, σ3}. A função de eventos ativos é de�-
nida como: Γ(x1) = {σ1}, Γ(x2) = {σ1, σ2} e Γ(x3) = {σ3}. A função de transição
é de�nida como: f(x1, σ1) = x2, f(x2, σ1) = x2, f(x2, σ2) = x3, f(x3, σ3) = x3. O
estado inicial de G é x1, e o conjunto de estados marcados é Xm = {x3}.
Neste trabalho, um caminho de um autômato G é denotado como a sequência
(x1, σ1, x2, ..., xn−1, σn−1, xn), no qual σi ∈ Σ, f(xi, σi) = xi+1, para i = 1, 2, ..., n−1.
Um caminho é dito cíclico quando x1 = xn.
A seguir são de�nidas as linguagens geradas e marcadas por um autômato.
2.3.1 Linguagem Gerada e Marcada por Autômatos
A conexão entre autômatos e linguagens pode ser feita inspecionando-se o diagrama
de transição de estados de um autômato. Todos os caminhos possíveis de serem
seguidos, partindo do estado inicial até um estado marcado ou não, dão origem aos
conceitos de linguagem gerada e marcada por um autômato.
De�nição 2.8 (Linguagem Gerada e Marcada) A linguagem gerada por um
autômato G = (X,Σ, f,Γ, x0, Xm) é de�nida como:
L(G) = {s ∈ Σ∗ : f(x0, s) é de�nida},
e a sua linguagem marcada é de�nida como:
Lm(G) = {s ∈ Σ∗ : f(x0, s) ∈ Xm}.
Na De�nição 2.8, a função de transição de estados é estendida, isto é, f : X×Σ∗ → Σ.
A linguagem gerada por G, L(G), é formada por todos os caminhos possíveis de
serem seguidos no diagrama de transição de estados, partindo do estado inicial.
Já a linguagem marcada, Lm(G), é um subconjunto de L(G) formado por todas as
palavras s tais que f(x0, s) ∈ Xm, ou seja, todas as sequência que levam a um estado
9
marcado no diagrama de transição de estados, a partir do estado inicial. É possível
que mais de um autômato represente a mesma linguagem, sendo ditos equivalentes
quando eles geram e marcam a mesma linguagem. Formalmente, dois autômatos G1
e G2 são ditos iguais se L(G1) = L(G2) e Lm(G1) = Lm(G2).
Nem sempre um autômato consegue chegar a um estado marcado, em decorrência
de possíveis bloqueios ao longo de um determinado caminho. Existem dois tipos de
bloqueios: de�nitivo e vivo. No bloqueio de�nitivo, o sistema chega a um estado
não marcado no qual não existem eventos que causem uma transição, ou seja, o
sistema não sairá desse estado. No bloqueio vivo, o sistema transita por um grupo
de estados não marcados que formam um ciclo do qual não é possível sair e atingir
um estado marcado. Pela de�nição, o sistema terá bloqueios quando o fecho de
pre�xo da linguagem marcada for um subconjunto próprio da linguagem gerada,
isto é, Lm(G) ⊂ L(G). Quando Γ(x) 6= ∅ para todo x ∈ X, a linguagem gerada por
G = (X,Σ, f,Γ, x0, Xm) é dita ser viva.
2.3.2 Operações com Autômatos
Existem basicamente dois grupos de operações que podem ser aplicadas aos autô-
matos: unárias e de composição [2]. As operações unárias são aquelas que alteram
o diagrama de transição de estados do autômato sem alterar o conjunto de eventos
Σ. As operações de composição são aquelas usadas para obter um novo autômato
a partir de dois ou mais autômatos. Em geral, operações de composição são execu-
tadas com o objetivo de construir um modelo completo do sistema a partir de seus
componentes, que operam simultaneamente. Nesta seção, são de�nidas as seguintes
operações unárias: parte accessível, parte coacessível e trim. Também são de�nidas
as seguintes operações de composição: produto e paralelo.
Operações Unárias
As operações unárias parte acessível, parte coacessível e trim são de�nidas a seguir.
De�nição 2.9 (Parte Acessível) A parte acessível de um autômato G =
(X,Σ, f,Γ, x0, Xm), denotada por Ac(G), é de�nida como:
Ac(G) = (Xac,Σ, fac, x0, Xac,m),
tal que Xac = {x ∈ X : (∃s ∈ Σ∗)[f(x0, s) = x]}, Xac,m = Xm ∩ Xac e fac =
f |Xac×Σ→Xac.
A notação f |Xac×Σ→Xac signi�ca que a função de transição de estados fac é restrita
aos estados de Xac. Tomar a parte acessível de um autômato G consiste em retirar
10
a b
c
1 3 4
5
c
2
d
a
c
1 3
5
c
2
d
a b
c
1 3 4
5
a
c
1 3
5
(i) (ii) (iii) (iv)
Figura 2.2: Em (i), encontra-se o autômato G, em (ii) Ac(G), em (iii) CoAc(G) e,em (iv), Trim(G).
todos os estados, e as transições relacionadas a eles, que não são alcançáveis a partir
do estado inicial x0, resultando no autômato Ac(G). Como os estados a serem
retirados não são atingidos pela linguagem gerada e marcada pelo autômato G, as
linguagens permanecem inalteradas.
De�nição 2.10 (Parte Coacessível) A parte coacessível de um autômato G =
(X,Σ, f,Γ, x0, Xm), denotada por CoAc(G), é de�nida como:
CoAc(G) = (Xcoac,Σ, fcoac, x0,coac, Xcoac,m),
tal que Xcoac = {x ∈ X : (∃s ∈ Σ∗)[f(x, s) ∈ Xm]} e fcoac = f |Xcoac×Σ→Xcoac.
Um estado x ∈ X é dito ser coacessível se há um caminho entre x e um estado
marcado. A operação parte coacessível retira de G todos os estados que não são
coacessíveis, ou seja, todos os estados a partir dos quais não é possível alcançar
um estado marcado. Esta operação pode causar alterações na linguagem gerada
mas não na linguagem marcada pelo autômato. Além disso, pode-se dizer que esta
operação retira eventuais bloqueios do sistema.
De�nição 2.11 (Operação Trim) Um autômato que é tanto coacessível quanto
acessível é dito ser trim. A operação Trim é de�nida como:
Trim(G) = Ac[CoAc(G)] = CoAc[Ac(G)]
Exemplo 2.5 A Figura 2.2 mostra em (i) o autômato G, em (ii) a sua parte aces-
sível, em (iii) sua parte coacessível e, em (iv), sua parte trim.
Operações de Composição
A operação produto, denotada por ×, e a operação paralelo, denotada por ||, tam-
bém são chamadas de composição completamente síncrona e composição síncrona,
respectivamente. As operações de produto e paralelo de autômatos são de�nidas a
seguir.
11
De�nição 2.12 (Produto) O produto de dois autômatos G1 =
(X1,Σ1, f1,Γ1, x01, Xm1) e G2 = (X2,Σ2, f2,Γ2, x02, Xm2) é de�nido como:
G1 ×G2 = Ac(X1 ×X2,Σ1 ∪ Σ2, f1×2,Γ1×2, (x01, x02), Xm1 ×Xm2),
na qual
Γ1×2(x1, x2) = Γ(x1) ∩ Γ2(x2)
e
f1×2((x1, x2), σ) =
{(f1(x1, σ), f2(x2, σ)), se σ ∈ Γ1(x1) ∩ Γ2(x2),
não de�nida, caso contrário.
A operação produto retorna um autômato cuja linguagem gerada e marcada é a
interseção das linguagens geradas e marcadas pelos autômatos utilizados na compo-
sição. Para que ocorram transições, os autômatos devem estar sempre sincronizados
com eventos em comum. Se os autômatos não possuírem eventos em comum, então
a linguagem gerada é {ε}.A composição paralela é mais abrangente que o produto, por permitir que eventos
individuais de cada autômato possam ser executados. Essa característica é muito
importante, uma vez que permite a modelagem de sistemas complexos por meio de
componentes individuais menores que contém eventos responsáveis pelo seu próprio
funcionamento e pela interação entre sistemas.
De�nição 2.13 (Paralelo) O paralelo de dois autômatos G1 =
(X1,Σ1, f1,Γ1, x01, Xm1) e G2 = (X2,Σ2, f2,Γ2, x02, Xm2) é de�nido como:
G1||G2 = Ac(X1 ×X2,Σ1 ∪ Σ2, f1||2,Γ1||2, (x01, x02), Xm1 ×Xm2),
na qual
Γ1||2(x1, x2) = [Γ1(x1) ∩ Γ2(x2)] ∪ [Γ1(x1)\Σ2] ∪ [Γ2(x2)\Σ1]
e
f1||2((x1, x2), σ) =
(f1(x1, σ), f2(x2, σ)), se σ ∈ Γ1(x1) ∩ Γ2(x2),
(f1(x1, σ), x2) se σ ∈ Γ1(x1)\Σ2
(x1, f2(x2, σ)) se σ ∈ Γ2(x2)\Σ1
não de�nido caso contrário
.
Caso o conjunto de eventos seja comum a ambos os autômatos, a composição paralela
se comporta como o produto. No caso de eventos privados, isto é, eventos que
pertençam a (Σ1\Σ2)∪(Σ2\Σ1), é permitida a sua execução sempre que for possível.
Dessa forma, a composição paralela sincroniza o comportamento em comum entre
os componentes, sincronizando seus eventos em comum e permitindo a execução de
eventos privados sempre que possível.
12
Figura 2.3: Exemplo da composição paralelo (iii) e produto (iv) dos autômatosmostrados em (i) e (ii).
Exemplo 2.6 Sejam G1 e G2 os autômatos (i) e (ii) mostrados na Figura 2.3, com
conjuntos de eventos Σ1 = {b1, e} e Σ2 = {a1, b1, e}, respectivamente. A composição
paralelo e produto entre G1 e G2 são mostradas em (iii) e (iv), respectivamente.
2.3.3 Autômato com Conjunto de Eventos Parcialmente Ob-
servável
O conjunto de eventos de um autômato pode ser particionado como Σ = Σo∪Σuo,
na qual Σo é o conjunto de eventos observáveis e Σuo é o conjunto de eventos não
observáveis. Um evento é observável quando sua ocorrência pode ser registrada
por um observador externo devido, geralmente, a mudanças nos sinais de sensores.
Os eventos não observáveis são aqueles cuja ocorrência não pode ser observada por
sensores (incluindo os eventos de falha) ou não podem ser observados devido à
natureza distribuída do sistema.
O comportamento dinâmico de um autômato determinístico com conjunto de
eventos parcialmente observável pode ser descrito por um autômato determinístico,
denominado observador, com conjunto de eventos formado pelos eventos observáveis
do autômato original. Os estados do observador são conjuntos contendo todos os
estados em que o sistema pode estar após a observação de uma sequência de eventos
observáveis. Antes de apresentar a de�nição do observador, é apresentado o conceito
de alcance não observável de um estado x ∈ X, denotado por UR(x), a seguir.
De�nição 2.14 (Alcance não observável) O alcance não observável de um es-
tado x ∈ X é de�nido como:
13
UR(x) = {y ∈ X : (∀t ∈ Σ∗uo)[f(x, t) = y]}.
O alcance não observável pode, também, ser de�nido para um conjunto de estados
B ∈ 2X como segue:
UR(B) =⋃x∈B
UR(x)
O alcance não observável de um estado x é um conjunto contendo todos os estados
alcançáveis, a partir de x, por transições rotuladas com eventos não observáveis. A
de�nição do observador de um autômato G é apresentada a seguir:
De�nição 2.15 (Autômato Observador) O observador de um autômato G =
(X,Σo∪Σuo, f,Γ, x0, Xm), denotado por Obs(G), é de�nido como segue:
Obs(G) = (Xobs,Σo, fobs, x0,obs, Xm,obs),
sendo Xobs ⊆ 2X . A obtenção dos parâmetros do observador é feita como apresen-
tado no Algoritmo 2.1.
Para construir o observador de um autômato G, o Algoritmo 2.1 pode ser utilizado.
Algoritmo 2.1 (Construção do Observador)
Entrada: Autômato G = (X,Σ, f,Γ, x0, Xm) e o conjunto de eventos observá-
veis Σo, sendo Σ = Σo∪Σuo.
Saída: Autômato observador Obs(G) = (Xobs,Σo, fobs, x0,obs, Xm,obs).
Passo 1: De�na x0obs = UR(x0). Faça Xobs = {x0obs} e Xobs = Xobs.
Passo 2: Faça Xobs = Xobs e Xobs = ∅.
Passo 3: Para cada B ∈ Xobs faça:
Passo 3.1: Γobs(B) = (⋃x∈B Γ(x)) ∩ Σo,
Passo 3.2: Para cada σ ∈ Γobs(B), fobs(B, σ) = UR({x ∈ X : (∃y ∈ B)[x =
f(y, σ)]}),
Passo 3.3: Faça Xobs = Xobs ∪ fobs(B, σ).
Passo 4: Faça Xobs = Xobs ∪ Xobs.
14
Passo 5: Repita os passos 2 a 4 até que toda a parte acessível do Obs(G) seja
construída.
A partir do Algoritmo 2.1, observa-se que a linguagem gerada pelo Obs(G) é a
projeção da linguagem gerada por G sobre o conjunto de eventos observáveis, ou
seja, L[Obs(G)] = Po[L(G)], sendo Po : Σ∗ → Σ∗o. Maiores detalhes a respeito do
algoritmo de construção do observador podem ser encontrados em [2].
Exemplo 2.7 Seja G o autômato (i) com eventos parcialmente observáveis mos-
trado na Figura 2.4, sendo Σo = {a1, b1} e Σuo = {e} os conjuntos de eventos
observáveis e não observáveis, respectivamente. O observador de G é mostrado em
(ii).
{x1} {x2, x3} {x3}b1 a1
e
b1 a1x1 x2 x3
Figura 2.4: Autômato G e seu observador, de acordo com o Exemplo 2.7.
2.4 Diagnose de Falhas em Sistemas a Eventos Dis-
cretos
Em muitos casos, quando o modelo do sistema apresenta eventos não observáveis,
estamos interessados em determinar quando um desses eventos ocorreu, em virtude
de tais eventos poderem representar falhas do sistema. As falhas consideradas neste
trabalho são eventos não observáveis capazes de gerar alterações não desejadas no
comportamento do sistema, não sendo possível que um sensor a detecte, caso con-
trário sua ocorrência seria identi�cada imediatamente.
Para modelar a falha, pode-se utilizar um evento não observável em um autô-
mato parcialmente observável. A teoria de diagnose de falhas permite veri�car se a
ocorrência de uma falha pode ser detectada ou não e, quando possível, é dito que
um sistema é diagnosticável em relação à projeção Po : Σ∗ → Σ∗o e ao evento de
falha.
2.4.1 Diagnose de Falhas Centralizadas
Seja Σf = {σf} ⊆ Σuo o conjunto de eventos de falha de um autômato G, e assuma
que a ocorrência de σf deva ser diagnosticada. Seja Ψ(Σf ) o conjunto de todas as
15
palavras de L que terminem com o evento de falha σf . Com um pequeno abuso
de notação, utiliza-se Σf ∈ s para denotar que s ∩ Ψ(Σf ) 6= ∅, sendo s o pre�xo
fechamento de s. Logo, s ∈ L é uma palavra que contém o evento de falha σf se
Σf ∈ s. A seguir, é apresentada a de�nição formal de diagnosticabilidade.
De�nição 2.16 (Diagnosticabilidade) Uma linguagem viva e pre�xo fechada L
é dita ser diagnosticável em relação a Po : Σ∗ → Σ∗o e Σf se
(∃n ∈ N)(∀s ∈ Ψ(Σf ))(∀t ∈ L/s, |t| ≥ n)⇒ (∀ω ∈ P−1o [Po(st)] ∩ L)[Σf ∈ ω].
De acordo com a De�nição 2.16, L é diagnosticável em relação a Po e Σf se, e
somente se, para todas as palavras st, sendo t de tamanho arbitrariamente longo
após a ocorrência de um evento de falha, Σf pertença a todas as palavras w ∈ L
cujas projeções Po(ω) = Po(st). Então, se L é diagnosticável, é sempre possível
identi�car a ocorrência de um evento de falha após um número �nito de observações
de eventos.
Um dispositivo capaz de detectar a ocorrência de eventos de falha e veri�car a
diagnosticabilidade de L é o diagnosticador. Sua construção é baseada no autômato
Gl computado a partir do modelo da planta G, sendo Gl obtido pela rotulação dos
estados de G de acordo com as palavras geradas pelo sistema, de tal forma que, se
uma palavra contém o evento de falha σf , então o estado é rotulado com Y , caso
contrário é rotulado com N . A de�nição formal do autômato diagnosticador Gd é
apresentada a seguir.
De�nição 2.17 (Autômato diagnosticador) O autômato diagnosticador Gd ob-
tido através do autômato G, em relação ao conjunto de eventos de falha Σf e ao
conjunto de eventos observáveis Σo, é dado por:
Gd = (Xd,Σo, fd,Γd, x0,d)
Sendo Xd ⊆ 2X×{N,Y }. A obtenção dos parâmetros do diagnosticador é feita como
apresentado no Algoritmo 2.2.
Para a construção do autômato autômato diagnosticador Gd a partir de Gl, é
apresentado o algoritmo a seguir:
Algoritmo 2.2 (Construção do Diagnosticador)
Entrada: Autômato G = (X,Σ, f,Γ, x0, Xm) e o conjunto de eventos observá-
veis Σo.
Saída: Autômato diagnosticador Gd = (Xd,Σo, fd,Γd, x0,d).
16
Passo 1: De�na o autômato rotulador como Al = (Xl,Σl, fl,Γl, x0,l), sendo
Xl = {N, Y }, Σl = {σf}, fl(N, σf ) = fl(Y, σf ) = F , Γl(N) = Γl(Y ) = {σf} e
x0,l = N .
Passo 2: Compute o autômato Gl = G||Al.
Passo 3: Compute o autômato diagnosticador Gd = Obs(Gl).
Sendo x ∈ X, os estados de Gl são do tipo xl = (x,N), se o estado xl for
alcançado por uma sequência que não contenha o evento de falha, e xl = (x, Y )
se a palavra contiver o evento de falha. A linguagem gerada por Gd é a projeção
natural Po : Σ∗ → Σ∗o da linguagem gerada de G, ou seja, L(Gd) = Po(L). Como
Gd = Obs(Gl), os estados atingidos por Gd são estimativas do estado de Gl após a
ocorrência de uma sequência de eventos.
Se Gd atinge um estado rotulado somente com Y , a falha com certeza ocorreu e
foi diagnosticada. Um estado de Gd rotulado somente com N indica que a falha não
ocorreu. Estados de Gd rotulados com N e Y , são chamados de estados incertos,
indicando que sequências de eventos com e sem o evento de falha e com a mesma
projeção natural foram executadas pelo sistema.
A análise de diagnosticabilidade do sistema utilizando o diagnosticador exige a
busca por ciclos indeterminados em Gd. Ciclos indeterminados são ciclos formados
por estados incertos em Gd, os quais são associados com pelo menos dois ciclos em
Gl, um que contenha somente estados rotulados com N e outro somente com Y .
A existência de ciclos indeterminados implica na violação da diagnosticabilidade
do sistema. Vale ressaltar, porém, que a presença de ciclos incertos (ou seja, for-
mados por estados incertos) em Gd não signi�ca, necessariamente, a violação da
diagnosticabilidade.
Neste trabalho são utilizadas outras técnicas para análise de diagnosticabilidade,
as quais são mostradas ao �m desta seção. O método para veri�cação de diagnos-
ticabilidade utilizando somente o diagnosticador e busca por ciclos indeterminados
não é, pois, utilizado.
Exemplo 2.8 Seja G o autômato mostrado em (a) da Figura 2.5, com Σo = {a1, c1}e Σf = {σf}, e Al o autômato rotulador mostrado em (b). O autômato diagnosti-
cador Gd = Obs(G||Al) é mostrado em (c). Nota-se que quando o evento c1 ocorre
sem antes ter ocorrido a1, o diagnosticador está certo de que ocorreu a falha, pois
seu estado é todo rotulado com Y .
Exemplo 2.9 Seja G o autômato mostrado em (a) na Figura 2.6, com Σo =
{a1, b1, c1} e Σf = {σf}. O autômato diagnosticador Gd obtido a partir de G é
17
a1x1 x2
(a)
σf
c1{x1N, x2Y }
{x2N} {x2Y }
a1 c1
c1 c1
(c)
N Y
(b)
σf
σf
Figura 2.5: Autômato diagnosticador do Exemplo 2.8.
mostrado em (b). Nota-se que há um ciclo indeterminado em Gd, formado pelos
estados {x2N, x4Y } e {x3N, x5Y }, em razão da linguagem gerada por G ser não
diagnosticável. Observa-se, no entanto, que o diagnosticador é capaz de alcançar
um estado certo de que ocorreu a falha, {x6Y }, se for observada a sequência b1a1a1,
por exemplo.
(a)
x1
x2 x4
x3 x5
a1 a1c1 c1
σf
b1
a1
{x1N}
{x2N, x4Y }b1
c1
{x3N, x5Y }a1
{x6Y }a1
(b)
x6a1
a1
Figura 2.6: Autômato diagnosticador com ciclo indeterminado do Exemplo 2.9.
2.4.2 Diagnose de Falhas Descentralizadas
Existem muitos sistemas cujas leituras de sensores não são centralizadas, mas sim
distribuídas em diversos sites, como, por exemplo, redes de comunicação, grandes
indústrias, o sistema elétrico de potência, etc. Os sites são nós de processamento de
informações nos quais leituras de determinados sensores conectados ao sistema são
reportadas. Cada site tem por função monitorar e diagnosticar o sistema a partir
dessas leituras.
Uma das arquiteturas descentralizadas propostas na literatura, considera o caso
em que locais Si, i = 1, 2, 3, ..., Ns, observam o comportamento do sistema, baseado
nas informações que chegam a eles. Associado a cada local de medição Si está
um conjunto de eventos observáveis Σoi ⊂ Σo, sendo todos os eventos σn ∈ Σ\Σoi
18
Sistema
S1 S2 SNs...
Coordenador
Σo1 Σo2ΣoNsObservacoes Locais
Diagnostico Local
Informacao a respeito da falha
Figura 2.7: Estrutura de um sistema coordenado de diagnose de falha descentrali-zado.
considerados não observáveis em Si. Assume-se que ∪Nsi=1Σoi = Σo. Cada site Si tem
um diagnosticador próprio Diagi(G), também chamado de Gdi , baseado no modelo
global do sistema G e em suas observações locais Σoi . O objetivo é de que pelo
menos um dos diagnosticadores locais diagnostique a ocorrência da falha a partir da
linguagem gerada pelo sistema.
Na arquitetura descentralizada, mostrada na Figura 2.7, cada local Si observa
os eventos σ ∈ Σoi informados pelo sistema, essa informação é processada e então
diagnosticadores comunicam seu diagnóstico a respeito da falha ao coordenador. O
coordenador processa as informações recebidas de acordo com uma regra preestabe-
lecida, e toma uma decisão a respeito da ocorrência ou não da falha.
Por nem sempre ser possível diagnosticar a ocorrência de uma falha, o conceito de
diagnosticabilidade no contexto das arquiteturas descentralizadas, também chamado
de codiagnosticabilidade, é formalizado a seguir.
De�nição 2.18 (Diagnosticabilidade descentralizada: Codiagnosticabili-
dade) Seja L uma linguagem viva e pre�xo fechada. Suponha que existam Ns locais
de observação. A linguagem L é dita ser codiagnosticável em relação às projeções
Poi : Σ∗ → Σ∗oi(i ∈ INs = {1, 2, ..., Ns}) e Σf se e somente se
(∃n ∈ N)(∀s ∈ Ψ(Σf ))(∀t ∈ L/s, |t| ≥ n)⇒ (∃i ∈ INs)(∀w ∈ P−1oi
(Poi(st))∩L)[Σf ∈ w].
A De�nição 2.18 é uma generalização da De�nição 2.16 para o caso de Ns > 1
locais de observação. Quando Ns se reduz a 1, o caso descentralizado torna-se cen-
tralizado. Implícito na De�nição 2.18 está o fato de que os diagnosticadores locais,
quando analisados individualmente, violam a diagnosticabilidade, porquê, em caso
contrário, não haveria a necessidade de se utilizar uma estrutura descentralizada.
A violação da codiagnosticabilidade ocorre quando todos Ns diagnosticadores lo-
19
cais entram, simultaneamente, em ciclos indeterminados, após a ocorrência de uma
sequência de eventos contendo o evento de falha.
Assumindo que o sistema sob análise é diagnosticável a partir de seu diagnos-
ticador centralizado (caso contrário, ele não poderia ser codiagnosticável) e que o
autômato que modela o sistema não contenha ciclos de eventos não observáveis, um
procedimento capaz de veri�car a codiagnosticabilidade é baseado no autômato de
teste, denominado Gt, que é obtido da seguinte maneira:
Gt = [ ||Nsi=1Gdi ] ||Gd, (2.1)
na qual Gdi = (Xdi ,Σoi , fdi ,Γdi , x0di) denota os diagnosticadores locais para os
sites Si, i = 1, 2, ..., Ns e Gd = (Xd,Σo, fd,Γd, x0d), sendo Σo = ∪Nsi=1Σoi , denota o
diagnosticador centralizado. Os estados xt de Gt têm a seguinte estrutura: xt =
(xd1 , xd2 , ..., xdNs, xd), sendo xdi ∈ Xdi e xd ∈ Xd. Observe, no entanto, que o teste
de codiagnosticabilidade utilizando o autômato Gt não é uma generalização do teste
de diagnosticabilidade, visto que, quando Ns = 1, Gt = Gd1||Gd = Gd||Gd é obtido
executando-se uma operação paralela desnecessária.
As de�nições de estados incertos e ciclos indeterminados são estendidas para
análise de codiagnosticabilidade como segue:
De�nição 2.19 (Estados certos e incertos em Gt) Um estado xt de Gt está
certo de que ocorreu a falha quando xd é rotulado com Y e xdi é rotulado somente
com Y para algum i ∈ {1, 2, ..., Ns}. Um estado de xt de Gt é incerto quando xd é
certo e xdi é incerto para todos i ∈ {1, 2, ..., Ns}.
De�nição 2.20 (Ciclo indeterminado em Gt) Um ciclo em Gt é indeterminado
se todos os ciclos correspondentes em Gdi, i ∈ {1, 2, ..., Ns} são indeterminados.
Com base na de�nição 2.20, o seguinte teorema, que fornece as condições neces-
sárias e su�cientes para a codiagnosticabilidade, pode ser enunciado:
Teorema 2.1 Uma linguagem viva e pre�xo fechada L, é codiagnosticável em rela-
ção às projeções Poi : Σ∗ → Σ∗oi , i = 1, 2, ..., Ns e Σf = {σf}, se e somente se, Gt
não possui ciclos indeterminados.
Os Exemplo 2.10 e 2.11 ilustram sistemas de codiagnose de falha.
Exemplo 2.10 Seja G o autômato mostrado em (a) na Figura 2.8, com Σo =
{a1, b1, c1} e Σf = {σf}. Em (b) é mostrado um diagnosticador com Σo1 = {a1, b1}e em (c) outro com Σo2 = {a1, c1}. Observa-se que, quando a falha ocorre, um
dos diagnosticadores entra em um estado certo de que ocorreu a falha. Quando
analisados isoladamente, os diagnosticadores violam a diagnosticabilidade, em razão
de possuírem ciclos indeterminados.
20
Figura 2.8: Autômatos diagnosticadores do Exemplo 2.10.
Exemplo 2.11 Seja G o autômato mostrado em (a) na Figura 2.9, com Σo =
{a1, b1, c1} e Σf = {σf}. Em (b) é mostrado um diagnosticador com Σo1 = {a1, c1}e em (c) outro com Σo2 = {b1, c1}. Observa-se que ambos diagnosticadores percorremciclos indeterminados ao mesmo tempo, não sendo capazes de diagnosticar a falha,
se ocorrer a sequência σfb1a1cn1 , sendo n de tamanho arbitrariamente grande, por
exemplo.
(a)
x1
x2
x3
b1
σf
{x1N, x2Y, x3Y }
{x4N, x5N, x5Y }a1
(b)
a1
c1x5a1
c1
x4
b1{x5N, x5Y }c1
{x1N, x4N, x2Y }
{x5N, x3Y, x5Y }b1
(c)
c1
{x5N, x5Y }c1
Figura 2.9: Autômatos diagnosticadores do Exemplo 2.10.
2.4.3 Teste de (Co)Diagnosticabilidade Utilizando o Autô-
mato GSCC
Nesta seção é apresentado um algoritmo capaz de determinar se um autômato
é (co)diagnosticável, baseada em uma nova condição necessária e su�ciente para
(co)diagnosticabilidade. O autômato diagnosticador de teste Gscc é baseado no
autômato diagnosticador, porém os requisitos de linguagem viva e não existência
de ciclos de estados conectados somente via eventos não observáveis não mais são
21
requeridas, e a busca por ciclos indeterminados (complexidade pior que exponencial
no número de transições do autômato) é substituída pela busca por componentes
fortemente conexos (complexidade linear no número de transições do autômato).
Além disso, a veri�cação da diagnosticabilidade passa a ser um caso particular do
teste de codiagnosticabilidade.
Seja G o autômato que modela a planta, o autômato GNsscc utilizado para o teste
de codiagnosticabilidade é obtido da seguinte forma:
GNsscc = (||Ns
i=1Gdi)||Gl (2.2)
no qual Gl = G||Al, sendo Al o autômato rotulador, Gdi o autômato diagnos-
ticador local do site Si e Ns o número de sites. Observe que no caso centralizado,
quando Ns = 1, Gscc é calculado da seguinte forma:
G1scc = Gd1 ||Gl = Gd||Gl = Gscc (2.3)
A linguagem gerada por GNsscc e Gscc é igual à linguagem gerada por Gl e à
linguagem gerada por G, ou seja, L(GNsscc) = L(Gscc) = L(Gl) = L(G).
Para análise da diagnosticabilidade utilizando Gscc, é necessário introduzir o
conceito de componentes fortemente conexas cuja de�nição é mostrada a seguir.
De�nição 2.21 (Componentes fortemente conexas) [1] Uma componente for-
temente conexa de um autômato G = (X,Σ, f,Γ, x0, Xm) é um conjunto máximo de
estados Xscc ⊆ X tal que para todo par de estados u, v ∈ Xscc, existe um caminho
formados por eventos de Σ de u para v e de v para u, ou seja, todo estado u, v ∈ Xscc
é alcançável um a partir do outro.
O seguinte teorema, que fornece uma condição necessária e su�ciente para uma
linguagem ser dita codiagnosticável, é apresentado a seguir:
Teorema 2.2 [1] A linguagem L gerada pelo autômato G é diagnosticável em
relação às projeções Poi : Σ∗ → Σ∗oi, i = 1, 2, ..., Ns e Σf = {σf} se, e so-
mente se, GNsscc não possui componentes fortemente conexas formada por estados
(x1d1, x1
d2, ..., x1
dNs, x1
l ), (x2d1, x2
d2, ..., x2
dNs, x2
l ), ..., (xmd1 , xmd2, ..., xmdNs
, xml ), de tal forma
que, ∀j ∈ {1, 2, ...,m}, xjdi , i = 1, 2, ..., Ns, é incerto e xjl é um estado rotulado com
Y, certo de que ocorreu a falha.
Com base neste teorema, é proposto o seguinte algoritmo capaz de determinar
se a linguagem gerada por um autômato é ou não diagnosticável em relação às
projeções Poi , i = 1, 2, ..., Ns e ao conjunto de falhas Σf = {σf}.
22
Algoritmo 2.3 (Veri�cação de codiagnosticabilidade com Gscc)
Entrada: Autômato G = (X,Σ, f,Γ, x0, Xm), Poi, i = 1, 2, ..., Ns e Σf = {σf}Saída: Decisão a respeito da codiagnosticabilidade: Sim ou Não.
Passo 1: Compute o autômato GNsscc = (||Ns
i=1Gdi)||Gl
Passo 2: Busque todas as componentes fortemente conexas de GNsscc
Passo 3: Veri�que se existe pelo menos uma componente fortemente
conexa formada por estados (x1d1, x1
d2, ..., x1
dNs, x1
l ), (x2d1, x2
d2, ..., x2
dNs, x2
l ), ...,
(xmd1 , xmd2, ..., xmdNs
, xml ), de tal forma que, ∀j ∈ {1, 2, ...,m}, xjdi , i = 1, 2, ..., Ns, é
incerto e xjl é um estado rotulado com Y, certo de que ocorreu a falha.
Passo 4: Se a resposta ao Passo 3 for sim, então a linguagem L é não co-
diagnosticável em relação às projeções Poi, i = 1, 2, ..., Ns e Σf = {σf}. Caso
contrário, L é codiagnosticável.
O algoritmo 2.3 também pode ser utilizado para Ns = 1, ou seja, para veri�cação
de diagnosticabilidade centralizada.
Exemplo 2.12 Os autômatos mostrados nas Figuras 2.10 e 2.11 são os Gscc calcu-
lados a partir dos autômatos mostrados nas Figuras 2.5 e 2.6, respectivamente. Nos
autômatos Gscc os estados incertos estão marcados. Podemos observar que na Fi-
gura 2.10 não há componentes fortemente conexas formadas por estados marcados,
ou seja, é diagnosticável. Na Figura 2.11, há uma componente fortemente conexa
formada pelos estados marcados ({x5Y, x3N}, (x5, Y )) e ({x4Y, x2N}, (x4, Y )), ou
seja, é não diagnosticável.
({x2Y }, (x2 , Y ))
({x1N, x2Y }, (x2 , Y )) ({x2N}, (x2 , N))
({x1N, x2Y }, (x1 , N))
σf
c1
c1
a1
c1
Figura 2.10: Autômatos Gscc do Exemplo 2.12 para o caso diagnosticável.
23
({x4Y, x2N}, (x2 , N))
({x1N, x4Y, x2N}, (x2 , N))
({x1N, x4Y, x2N}, (x4 , Y ))
({x4Y, x2N}, (x4 , Y ))
({x5Y, x3N}, (x5 , Y ))
({x5Y, x3N}, (x3 , N))
({x6Y }, (x6 , Y ))
({x1N, x4Y, x2N}, (x1 , N))
a1
a1
a1 σf
c1a1
σf
b1
c1
a1
a1
Figura 2.11: Autômatos Gscc do Exemplo 2.12 para o caso não diagnosticável.
2.5 Rede de Petri
A rede de Petri é um formalismo matemático que pode ser visto como uma alter-
nativa à utilização de autômatos para modelar SEDs. As redes de Petri manipulam
eventos de acordo com regras bem de�nidas, além de possibilitar uma melhor visua-
lização de comportamentos como paralelismo e concorrência em sistemas complexos.
2.5.1 Grafo de uma rede de Petri
Numa rede de Petri, existem dois tipos de vértices: lugares e transições. Os arcos das
redes de Petri, aos quais podem ser atribuídos pesos, não podem conectar vértices
do mesmo tipo. A rede de Petri é, portanto, um grafo bipartido ponderado. Os
lugares são representados por círculos, e guardam informações a respeito do estado e
condições do sistema. As transições são representadas por barras, e estão associadas
aos eventos. Os arcos são representados por setas, e determinam as relações entre
transições e lugares. Lugares, transições e a relação entre eles são as informações
básicas que de�nem a estrutura de uma rede de Petri. A de�nição formal do grafo
de uma rede de Petri é apresentada em seguida.
De�nição 2.22 (Grafo de uma rede de Petri) Um grafo de uma rede de Petri,
também chamado de estrutura de uma rede de Petri, é uma quádrupla
(P, T, Pre, Post),
na qual P é o conjunto de estados, T é o conjunto de transições, Pre : (P ×T )→ Né a função que de�ne o peso do arco que liga um lugar pi ∈ P a uma transição
24
tj ∈ T e, por �m, Post : (T ×P )→ N é a função que de�ne o peso do arco que liga
uma transição tj ∈ T a um lugar pi ∈ P .
Sendo P = {p1, p2, ..., pu} e T = {t1, t2, ..., tv}, temos que |P | = u e |T | = v, na
qual |.| denota a cardinalidade de um conjunto. O conjunto de lugares de entrada
(transições de entrada) de uma transição tj ∈ T (lugar pi ∈ P ) é denotado por
I(tj) (I(pi)), e são formados pelos lugares pi ∈ P (transições tj ∈ T ) tais que
Pre(pi, tj) > 0 (Pos(tj, pi) > 0). De forma similar, o conjunto dos lugares de
saída (transições de saída) de uma transição tj ∈ T (lugar pi ∈ P ) é denotado por
O(tj) (O(pi)), e são formados pelos lugares pi ∈ P (transições tj ∈ T ) tais que
Pos(tj, pi) > 0 (Pre(pi, tj) > 0). A seguir, é mostrado um exemplo de rede de Petri.
Exemplo 2.13 Na Figura 2.12, é mostrada o grafo de uma rede de Petri com P =
{p1, p2}, T = {t1}, Pre(p1, t1) = 1, Post(t1, p2) = 2. Para essa rede temos que:
I(t1) = p1, I(p2) = t1, O(p1) = t1, O(t1) = p2.
p1 p2t1
2
Figura 2.12: Rede de Petri do Exemplo 2.13.
2.5.2 Marcação de uma rede de Petri
Ao ocorrer um evento, um elemento capaz de indicar quando uma transição pode
ser disparada ou não são as �chas, também chamadas de tokens, que são atribuídas
aos lugares. O número de tokens atribuídos a um lugar é dado por x(pi), sendo x :
P → N a função de marcação. A marcação de uma rede de Petri é representada pelo
vetor x = [x(p1)x(p2)...x(pu)]T , o qual é formado pelo número de tokens atribuídos
a cada lugar pi, para i = 1, 2, ..., u. Gra�camente, os tokens são representados por
círculos posicionados no interior dos lugares. A de�nição formal de rede de Petri é
apresentada a seguir.
De�nição 2.23 (Rede de Petri Marcada) Uma rede de Petri marcada, ou sim-
plesmente uma rede de Petri N , é uma quíntupla N = (P, T, Pre, Post, x0), na qual
(P, T, Pre, Post) é a estrutura de uma rede de Petri, e x0 é a função de marcação
inicial da rede de Petri.
Na rede de Petri, o vetor x representa o estado do sistema. Para cada novo
estado, a rede de Petri atinge uma nova marcação.
Exemplo 2.14 Na Figura 2.13, é mostrado o grafo da rede de Petri de�nida no
Exemplo 2.13 e com vetor de marcação x = [1 2]T .
25
p1 p2t1
2
Figura 2.13: Rede de Petri marcada do Exemplo 2.14.
Numa rede de Petri, uma transição tj é dita estar habilitada quando o número
de tokens atribuídos a cada um dos lugares de entrada de tj é maior ou igual ao
peso do arco que o conecta à transição. A de�nição formal de transição habilitada
é mostrada a seguir.
De�nição 2.24 (Transição habilitada) Uma transição tj ∈ T é dita estar habi-
litada quando
x(pi) ≥ Pre(pi, tj), para todo pi ∈ I(tj).
O Exemplo 2.15 ilustra o conceito de transição habilitada.
Exemplo 2.15 Na Figura 2.14, é mostrado o grafo de uma rede de Petri marcada
cuja transição t1 está habilitada, uma vez que x(p1) = 1 ≥ Pre(p1, t1) = 1 e x(p2) =
1 ≥ Pre(p2, t1) = 1, e t2 não está habilitada, em razão de x(p2) = 1 < Pre(p2, t2) =
2.
p1
p2 t1
p3 t2
2
Figura 2.14: Rede de Petri marcada do Exemplo 2.15.
2.5.3 Dinâmica de uma rede de Petri
Quando uma transição está habilitada em uma rede de Petri, ela pode disparar, ou
seja, pode ocorrer. A transição de estados numa rede de Petri ocorre quando uma
transição habilitada dispara. Se, para uma determinada marcação x, uma transição
tj dispara, a rede de Petri atinge uma nova marcação x dada por
x(pi) = x(pi)− Pre(pi, tj) + Post(tj, pi), para i = 1, 2, ..., u. (2.4)
De acordo com a Equação (2.4), se pi é um lugar de entrada da transição tj, e
tj dispara, pi perde um número de tokens igual ao peso do arco que o conecta a tj,
dado por Pre(pi, tj). Se pi é um lugar de saída da transição tj, o lugar ganha um
número de �chas igual ao peso do arco que conecta tj a pi, dado por Post(tj, pi). Se
26
o lugar pi for, ao mesmo tempo, um lugar de entrada e de saída da transição tj, piperde Pre(pi, tj) e ganha Post(tj, pi) �chas.
Exemplo 2.16 Suponha que a transição t1 da rede de Petri marcada mostrada na
Figura 2.14 tenha disparado e, na sequência, t2 também tenha disparado. A nova
marcação para essas duas situações são mostradas na Figura 2.15 em (a) e (b),
respectivamente.
p1
p2 t1
p3 t2
2 p1
p2 t1
p3 t2
2
(a) (b)
Figura 2.15: Rede de Petri marcada do Exemplo 2.16.
Um importante conceito relacionado à marcação de uma rede de Petri é o de rede
de Petri segura, cuja de�nição é apresentada a seguir.
De�nição 2.25 (Rede de Petri segura) Uma rede de Petri é dita segura se todos
os seus lugares possuírem, para qualquer marcação alcançável, no máximo uma �cha,
ou seja, x(pi) ≤ 1 para todo i = 1, 2, ..., u.
2.5.4 Rede de Petri rotulada
Para modelar SEDs utilizando redes de Petri, é necessário estabelecer uma corres-
pondência entre eventos e transições. Para tanto, associamos pelo menos um evento
a cada transição, fazendo com que seja possível a rede de Petri representar uma lin-
guagem. A função de rotulação é a responsável por associar um conjunto de eventos
a cada transição. A seguir, é apresentada a de�nição de rede de Petri rotulada.
De�nição 2.26 (Rede de Petri rotulada) Uma rede de Petri rotulada é uma
sétupla N = (P, T, Pre, Post, x0,Σ, l), na qual (P, T, Pre, Post) é o grafo da rede
de Petri, x0 é o vetor de marcação inicial, Σ é o conjunto de eventos utilizado para
rotular as transições, l : T → 2Σ é a função de rotulação de transição que associa
um subconjunto de Σ a uma transição pertencente a T.
Em uma rede de Petri rotulada, uma transição habilitada tj dispara quando um
dos eventos associado a tj ocorrem.
Exemplo 2.17 Na Figura 2.16, é mostrada uma rede de Petri rotulada. A transição
t1 está habilitada mas so disparará se o evento σ ∈ Σ ocorrer.
27
p1 t1 p1
σ
Figura 2.16: Rede de Petri rotulada do Exemplo 2.17.
2.5.5 Rede de Petri Estendida
Uma rede de Petri estendida contém um tipo especial de arco, conhecido como arco
inibidor. Um arco inibidor é um arco direcionado que conecta lugares a transições,
somente, e sua extremidade conectada às transições é representada por um pequeno
círculo. A de�nção de rede de Petri estendida é apresentada a seguir.
De�nição 2.27 (Rede de Petri rotulada estendida) Uma rede de Petri
rotulada estendida é uma óctupla N = (P, T, Pre, Post, In, x0,Σ, l), na qual
(P, T, Pre, Post, x0,Σ, l) é uma rede de Petri rotulada e In : (P × T ) → N é a
função dos arcos inibidores.
O arco inibidor adiciona uma nova regra de habilitação de transições à rede de
Petri. Se um lugar pi é conectado a uma transição tj por meio de um arco inibidor,
a transição tj só estará habilitada se o número de tokens em pi for menor que o peso
do arco inibidor que conecta pi a tj, dado por In(pi, tj). A regra para habilitação
de transições em uma rede de Petri estendida é mostrada a seguir.
De�nição 2.28 (Transição habilitada em uma rede de Petri estendida)
Numa rede de Petri estendida, uma transição tj ∈ T é dita estar habilitada se
x(pi) ≥ Pre(pi, tj) e x(pi) < In(pi, tj), para todo pi ∈ I(tj),
considerando-se que pi ∈ I(tj) se Pre(pi, tj) > 0 ou In(pi, tj) > 0.
Arcos inibidores são responsáveis apenas por habilitar ou desabilitar transições.
Se uma transição tj disparar, o número de �chas dos lugares pi, tais que In(pi, tj) >
0, permanece inalterado.
Exemplo 2.18 Na Figura 2.17, é mostrado em (a) uma rede de Petri estendida
cuja transição t1 não está habilitada em razão de x(p2) = In(p2, t1). Em (b), a
transição t1 está habilitada, visto que x(p2) < In(p2, t1). Ao disparar a transição t1
no caso (b), a nova marcação da rede é mostrada em (c).
2.5.6 Rede de Petri interpretada para controle (RPIC)
As redes de Petri interpretadas para controle (RPIC) têm uma estrutura que permite
a modelagem dos controladores de sistemas industriais, ao contrário das redes de
Petri até agora apresentadas, que possuem limitações nesse quesito.
28
p1t1
p1
σ
p2
p1t1
p1
σ
p2
2p1
t1p1
σ
p2
2
(a) (b) (c)
Figura 2.17: Rede de Petri estendida do Exemplo 2.18.
Numa RPIC, uma transição habilitada só dispara quando ocorre um evento e
condições predeterminadas forem verdadeiras. Isso quer dizer que, além da condição
para que uma transição esteja habilitada, uma RPIC considera condições externas
à rede. Os lugares passam a ter uma função além da representação das condições do
sistema ou das condições para disparo de transições, ou seja, quando determinado
lugar recebe uma �cha, alguma ação relacionada a esse lugar é realizada.
As transições nas RPICs podem ser temporizadas, ou seja, podem ser associ-
adas a atrasos de disparo. O conjunto de transições T pode ser particionado em
um conjunto de transições temporizadas TD e outro de transições não temporizadas
T0, ou seja, T = T0∪TD. As transições temporizadas são identi�cadas pelo atraso
dj indicado ao lado delas. Quando a transição se torna habilitada, é iniciada uma
contagem de tempo. Se o tempo pré-determinado é alcançado, a transição dispara.
Caso a transição se torne desabilitada antes do seu disparo, ou seja, antes do tem-
porizador alcançar o tempo �nal, a contagem é zerada. Uma de�nição formal de
RPIC é apresenta a seguir.
De�nição 2.29 (Rede de Petri interpretada para controle) [10] Uma rede de
Petri interpretada para controle é uma tupla
N = (P, T, Pre, Post, x0, In, C,E, lc, D, ld, A, lA), (2.5)
na qual (P, T, Pre, Post, x0, In) é uma rede de Petri estendida, C e E são os con-
juntos de condições e eventos associados às transições não temporizadas de T0 ⊆ T ,
respectivamente, lc : T0 → C ×E é a função que associa cada transição em T0 a um
evento de E e a uma condição de C, D denota o conjunto de atrasos associados às
transições temporizadas, ld : TD → D é a função de temporização que associa a cada
transição temporizada um tempo de atraso de D, A é o conjunto de ações impulsivas
associadas a lugares seguros de P , la : Ps → 2A é a função de rotulação que associa
um lugar a um subconjunto de A, sendo Ps ⊆ P o conjunto de lugares seguros.
De acordo com a De�nição 2.29, observa-se que as transições temporizadas não
possuem associações a condições ou eventos. As transições não temporizadas têm
29
Processamento de DadosComputacao de variaveis e condicoes
oi cpj
ej cej qi
RPIC
Controlador
AmbienteSistema controlado e operador
Figura 2.18: Diagrama mostrando o �uxo de dados entre o ambiente externo, ocontrolador (RPIC) e a unidade de processamento de dados.
sempre uma condição e evento associados a elas. As ações contínuas são executa-
das apenas enquanto os lugares ao qual estão vinculadas possuírem �chas. A ação
impulsional é executada apenas uma vez, quando o lugar ao qual está vinculada
recebe uma �cha, e continua a ser executada mesmo após este lugar perder a �-
cha. Possivelmente, haverá a necessidade de um outro lugar que interrompa a ação
impulsional anteriormente iniciada.
Para ilustrar o funcionamento de um sistema controlado por uma RPIC, é mos-
trado um diagrama na Figura 2.18 contendo setas que indicam a forma em que se
dá o �uxo de sinais e dados entre o controlador, a unidade de processamento de
dados e o ambiente físico externo. Nele, a RPIC recebe informações a respeito das
condições do ambiente cej e dos eventos externos ej, assim como envia sinais de saída
para o ambiente, que são representados pelas ações qi. O controlador envia ordens
de operação oi para o sistema de processamento de dados e recebe informações a
respeito das condições internas associadas aos dados processados cj.
No grafo de uma RPIC, as ações, eventos, condições e ordens de operação são
representados conforme mostrado na Figura 2.19. Observa-se que em (a), ao lado do
lugar pi, encontram-se a ação qi e a operação oi, e ao lado da transição tj encontram-
se o evento ej e a condição cj = cej .cpj . Nos casos em que a transição é temporizada,
ela é representada conforme a transição tj em (b), com um atraso dj de disparo.
Exemplo 2.19 A Figura 2.20 mostra uma RPIC que inicialmente aciona uma luz
branca enquanto o lugar p1 possui uma �cha. Ao pressionar um botão, a transição
t1 é disparada, removendo a �cha de p1 e adicionando uma �cha em p2, conse-
quentemente desligando a luz branca e acionando a luz azul. Após d1 = 1 minuto,
a transição temporizada t2 é disparada, removendo uma �cha de p2 e adicionando
uma �cha em p1, fazendo com que o sistema volte à sua posição inicial, com a luz
branca acionada e a azul desligada.
30
pi oi, qi
tj ej .cj
pi oi, qi
tj dj
(a) (b)
Figura 2.19: Representação grá�ca dos elementos de uma RPIC.
p1
p2
t1 t2botao d1 = 1 min
Acender luz branca
Acender luz azul
Figura 2.20: Exemplo de uma RPIC utilizada para acionar duas lâmpadas.
31
Capítulo 3
Problema de Codiagnosticabilidade
em Rede Sujeita a Atraso de
Comunicação
No problema clássico de diagnose de falhas, apresentado na Seção 2.4, considera-se
que não existam atrasos entre a ocorrência do evento e sua respectiva comunicação
ao diagnosticador. Porém, em sistemas de grande porte, os atrasos na comunicação
acabam sendo inevitáveis e devem ser levados em conta. A comunicação entre a
planta e os diagnosticadores locais é feita através de diversos canais, de forma que
um atraso na comunicação pode acarretar em trocas na ordem de observação dos
eventos, causando, no pior caso, uma perda na codiagnosticabilidade do sistema.
Neste capítulo, um breve resumo do problema da codiagnosticabilidade de sis-
temas a eventos discretos conectados em rede (NDESWTS, do inglês Networked
Discrete Event Systems With Timing Structure) sujeitos a atrasos de comunicação
�nitos, que foi desenvolvido em [1], é apresentado. Na seção 3.1 é mostrada a arqui-
tetura considerada no problema, na seção 3.2 apresenta-se uma forma de se obter
um modelo não temporizado de um NDESWTS sujeitos a atrasos na comunicação
e, por �m, na seção 3.3 é apresentada a de�nição de codiagnosticabilidade de um
NDESWTS.
3.1 Arquitetura do Problema
A arquitetura do problema considera uma planta distribuída formada por m locais
de medição MSj, j = 1, ...,m e Ns diagnosticadores locais LDi, i = 1, ..., Ns. Cada
MSj pode detectar os eventos ΣMSj⊂ Σo. Os eventos detectados por MSj podem
ser comunicados pelo canal chij para o diagnosticador local LDi. Cada canal chijapresenta um atraso máximo Tij ∈ R∗+, sendo R∗+ o conjunto dos números reais
32
MS1 MS2
Planta
LD1 LD2 LD3
ch11
Σo11
T11
ch21
Σo21
T21
ch22
Σo22
T22
ch32
Σo32
T32
Coordenador
Figura 3.1: Arquitetura do problema de codiagnose de falhas em rede.
positivos maiores que zero.
O conjunto de eventos comunicados a um diagnosticador local LDi através do
canal chij é Σoij ⊆ ΣMSj. Se não existe um canal de comunicação entre MSj e LDi,
então Σoij = ∅. O conjunto Σoi de eventos observáveis do diagnosticador LDi é dado
por
Σoi =m⋃j=1
Σoij , (3.1)
e o conjunto de eventos observáveis por todo o sistema é dado por
Σo =Ns⋃i=1
Σoi .
A Figura 3.1 mostra a arquitetura de um sistema de codiagnose de falhas em
rede sujeita a atrasos na comunicação, na qual existem 2 locais de medição (MS1
e MS2) e 3 diagnosticadores locais (LD1, LD2 e LD3). O local de medição MS1
comunica a ocorrência dos eventos Σo11 ⊆ ΣMS1 ao diagnosticador local LD1 através
do canal de comunicação ch11 com tempo máximo de atraso igual a T11. Para os
demais parâmetros presentes na �gura, a interpretação é similar.
Para esse modelo, supõe-se que:
A1. A linguagem L(G) é codiagnosticável em relação à projeção Poi, i = 1, ..., Ns,
e Σf , sendo G o autômato que modela a planta.
A2. Existe somente um canal de comunicação chij entre MSj e LDi comunicando
os eventos de Σoij .
A3. Cada canal chij é modelado por uma �la �rst-in �rst-out (FIFO) sujeita a um
33
conhecido máximo atraso �nito Tij ∈ R∗+ na comunicação.
A4. ΣMSi ∩ ΣMSj= ∅, i, j ∈ Im = {1, 2, ...,m}, i 6= j, ou seja diferentes locais de
medição não possuem eventos em comum.
Ao assumir A1, os casos de interesse �cam restritos aos sistemas que, a priori,
são codiagnosticáveis quando não são considerados atrasos na comunicação. A2
assume que a ocorrência de um evento observável seja transmitida por um único
canal a um determinado diagnosticador local, no entanto, pode haver outros canais
que transmitam o mesmo evento, só que para diferentes diagnosticadores locais. A3
assume que todos os atrasos são tempos medidos no domínio dos números reais,
�nitos e maiores que zero, além de assumir não haver a troca de observação de
eventos transmitidos pelo mesmo canal, já que este é modelado como uma �la FIFO.
A4 assume que dois diferentes locais de medição não observem a ocorrência do
mesmo evento.
Considerando que o sistema permaneça um tempo mínimo em cada estado antes
que uma nova transição ocorra, é necessária a de�nição de uma função que atribua
um tempo mínimo para a ocorrência de determinado evento, quando o sistema
encontra-se em um determinado estado. Para tanto, de�ne-se a função parcial tmin :
X × Σ→ R∗+, na qual tmin(x, σ) = τ , σ ∈ Γ(x), signi�ca que o tempo mínimo para
que o evento σ ocorra, contado a partir do momento que o sistema atinge o estado
x, é maior que τ . A de�nição formal de NDESWTS é apresentada a seguir.
De�nição 3.1 (NDESWTS)[1] Um sistema a eventos discretos em rede tem-
porizados NDESWTS, é uma tupla NDESWTS = (G, tmin, T ), na qual G =
(X,Σ, f,Γ, x0, Xm) é um autômato �nito, tmin : X ×Σ→ R∗+ é a função de tempos
mínimos e T : n × m é a matriz de atrasos máximos, cujos elementos Tij ∈ R∗+representam os atrasos máximos de cada canal chij se existirem canais de comuni-
cação entre os locais de medições MSj e os diagnosticadores locais LDi, e, caso não
exista, Tij =∞.
Exemplo 3.1 [1] Na Figura 3.2, é mostrado um sistema a eventos discretos em
rede temporizados NDESWTS = (G, tmin, T ) com a estrutura de atrasos em (a) e
o autômato G com a função tmin em (b). Em (a), existe um diagnosticador local
LD1 e dois locais de medição MS1 e MS2, os quais comunicam o evento {a} atravésdo canal ch11 com atraso máximo T11 = 2 unidades de tempo (u.t) e {b, c} atravésdo canal ch12 com atraso máximo T12 = 0.1 u.t, respectivamente, de forma que
T = [T11 T12] = [2 0.1]. Em (b), a função de tempo mínimo é de�nida como
tmin(x0, b) = tmin(x4, a) = tmin(x5, c) = tmin(x1, a) = tmin(x3, c) = 1, tmin(x2, b) = 3,
tmin(x0, σf ) = 0.1. As funções de tempo mínimo indicam o menor tempo possível
para o evento ocorrer depois que G entra em determinado estado, tmin(x1, a) = 1
34
LD1
MS1 MS2
Σo11 = {a}T11 = 2
Σo12 = {b, c}T12 = 0.1
x0
0.1/σf1/b
1/a
x4
x5
1/a
x1
x2
3/b
x31/c1/c
Figura 3.2: NDESWTS = (G, tmin, T ) do exemplo 3.1. Esta �gura foi retirada de[1].
T11
a
2 3.13
T12
tmin(x2, b)
as b bs
Figura 3.3: Linha do tempo para a sequência abcn em G e possíveis observações emLD1 do exemplo 3.1. Esta �gura foi retirada de [1].
indica, por exemplo, que após G entrar em x1, o evento a ocorre, no mínimo, após
1 u.t. Para distinguir a ocorrência dos eventos a,b e c dos que foram observados
pelo diagnosticador, as, bs, cs denotam a observação com sucesso dos eventos a, b, c,
respectivamente. Pela Figura 3.2, nota-se que pode ocorrer uma troca na ordem
de observações: a sequência bacn pode ser lida como bsascs, sem troca, ou bscsas,
com troca em razão de tmin(x5, c) = 1 ≤ T11 = 2, ou seja, devido ao atraso na
comunicação do evento a, o evento c ocorreu e foi comunicado antes do próprio
a. Para ilustrar as possíveis trocas, são mostradas duas linhas de tempo com a
ocorrência dos eventos e suas observações com sucesso pelo diagnosticador para as
sequências abcn e bacn, nas Figuras 3.3 e 3.4, respectivamente. Vale ressaltar que
não há atrasos entre os eventos b e c, em razão de serem transmitidos pelo mesmo
canal.
T11
a
T12
21
tmin(x5, c)
1.1 2.1
tmin(x5, c)
T12
c cs as, c cs
Figura 3.4: Linha do tempo para a sequência bacn em G e possíveis observações emLD1 do exemplo 3.1. Esta �gura foi retirada de [1].
35
3.2 Modelo Não Temporizado de um NDESWTS
Sujeito a Atrasos na Comunicação
O desenvolvimento de um modelo não temporizado de um NDESWTS que leve em
consideração todas as possíveis trocas de observação de eventos, requer a diferen-
ciação entre os eventos σ ∈ Σoij que estejam sendo transmitidos do local MSj ao
diagnosticador LDi, via chij, e o que esteja sendo observado por LDi. Para tanto,
cria-se um evento σsi que modela o sucesso da observação do evento σ pelo diag-
nosticador local LDi. O conjunto de eventos que foram observados com sucesso por
LDi é, então, dado por
ΣSoi
=m⋃j=1
ΣSoij, (3.2)
na qual
ΣSoij
= {σsi : σ ∈ Σoij}. (3.3)
O conjunto de eventos estendido de cada diagnosticador local, pode, então, ser
de�nido como segue:
Σi := Σ ∪ ΣSoi. (3.4)
Para capturar a ocorrência de eventos observáveis e suas possíveis ordens de
observação, utiliza-se o autômato Gi = (Xi,Σi, fi, xoi , ∅), que é formado a partir
de NDESWTS = (G, tmin, T ), e cujos estados possuem dois componentes: (i) o
primeiro componente corresponde ao estado x de G, e (ii) o segundo componente
corresponde aos eventos observáveis que ocorreram em G até alcançar o estado x
seguidos pelo tempo mínimo decorrido entre suas observações e que ainda estão
sendo transmitidos ao diagnosticador.
Seja, por exemplo, (x, a 1.1 b 0.5 c) um estado de Gi. Podemos a�rmar que
esse estado de Gi corresponde ao caso no qual o autômato G que modela o sistema
encontra-se no estado x após a execução de uma palavra s ∈ L(G) que contém,
nesta ordem, os eventos a, b e c, cujas observações ainda estão sendo transmitidas
ao diagnosticador local. Indo além, podemos a�rmar que o tempo mínimo entre a
ocorrência dos eventos a e b é de 1.1 unidade de tempo (u.t.) e entre b e c é de 0.5
u.t. Vale ressaltar que s pode ter outros eventos observáveis cuja transmissão foi
completada antes do sistema alcançar o estado x.
Antes de apresentar o algoritmo para construção de Gi, são desenvolvidas, re-
sumidamente, as de�nições utilizadas. Seja Ip = {1, 2, ..., p}, p ∈ N∗ e de�na
Qi := {q = q1q2...ql : ∀k ∈ Il, (qk ∈ Σoi) ou (qk ∈ R+)}, sendo i ∈ INS. Com
pequeno abuso de notação, diz-se que qp ∈ q se existe q′, q′′ ∈ Qi tal que uma
36
das seguintes condições seja verdadeira: (i)q = q′qpq′′, (ii)q = q′qp, (iii)q = qpq
′′,
(iv)q = qp. Observe que os elementos de Qi são palavras formadas por eventos de
Σoi e números em R+. A construção de Gi envolve manipulação de palavras e, para
este �m, são de�nidas as operações e funções apresentadas na de�nição 3.2.
De�nição 3.2 A seguir, são de�nidas as operações (a) link, (b) cut, (c) addition,
(d) removal, e as seguintes funções (e) measurement site index e (f) observable
event index.
(a) Link: A operação link é o mapeamento link : Qi ×Qi → Qi no qual, para
todo q = q1...ql e p = p1...pk pertencentes a Qi,
link(q, p) =
{q1...ql−1(ql + p1)p2...pk, se ql, p1 ∈ R+
q1...qlp1...pk, caso contrário. (3.5)
(b) Cut: A operação cut é o mapeamento cut : Qi → Qi no qual, para todo
q = q1...ql ∈ Qi,
cut(q) =
{qwqw+1...ql, se (∃w ≤ l)[(qw ∈ Σoi) ∧ (qj ∈ R+,∀j ∈ {1, ..., w − 1})]
0, se qj ∈ R+,∀j ∈ {1, 2, ..., l}.
(3.6)
(c) Addition: A operação addition é o mapeamento add : Qi ×X × Σ → Qi
no qual, para todo q = q1...ql ∈ Qi, x ∈ X e σ ∈ Σ,
add(q, x, σ) =
cut(link(q, tmin(x, σ)σ)), se(σ ∈ Σoi) ∧ (f(x, σ)!)
cut(link(q, tmin(x, σ))), se(σ ∈ Σuoi) ∧ (f(x, σ)!)
indefinido, caso contrário
. (3.7)
(d) Removal: A operação removal é o mapeamento rem : Qi × N∗ → Qi no
qual, para todo q = q1q2...ql ∈ Qi,
rem(q, k) =
cut(q2...ql), se (k = 1)
link(q1...qk−1, qk+1...ql), se (1 < k < l)
cut(q1...ql−1), se (k = l)
indefinido, caso contrário
. (3.8)
37
(e) Measurement site index: A função measurement site index é o mapea-
mento ms : Σoi → {1, 2, ...,m} no qual, para todo σ ∈ Σoi,
ms(σ) =
{j, se σ ∈ Σoij para algum i ∈ {1, ..., NS}
indefinido, caso contrário. (3.9)
(f) Observable event index: A função observable event index é o mapea-
mento Ioi : Qi × 2Σo → 2N∗no qual, para todo q = q1, ..., ql e para todo Σoi ∈ Σo
Ioi(q,Σoi) = {k ∈ 1, ..., l : qk ∈ Σoi}. (3.10)
De acordo com a de�nição 3.2, a operação link(q, p) serve para concatenar as pa-
lavras q e p. A função cut(q) remove de q o pre�xo formado apenas por números
antes do primeiro evento observável, ou, se q for composto apenas por números,
cut(q) muda o valor de q para 0. A função add(q, x, σ) adiciona elementos em q
dependendo de σ ser observável ou não. Se for observável, σ é adicionado junto com
o tempo mínimo de ativação e, caso σ seja não observável, apenas o tempo mínimo
de ativação é adicionado. A função rem(q, k) remove de q seu k-ésimo elemento. A
função ms(σ) retorna o índex j correspondente ao local MSj que detectou a ocor-
rência de σ. A função Ioi(q,Σoi) retorna o conjunto de índices dos eventos presentes
na palavra q que pertençam a Σoi .
A seguir, é apresentado o algoritmo desenvolvido em [1] e [7] para construção
do autômato Gi, que tem como ideia principal obter todas as possíveis ordens de
observação de eventos de LDi, em razão dos atrasos introduzidos pelos canais de
comunicação.
Algoritmo 3.1 (Construção do autômato Gi)
Entrada: NDESWTS = (G, tmin, T ) e Σoij , ∀j ∈ Im.Saída: Autômato Gi = (Xi,Σi, fi,Γi, x0i , ∅)
• Passo 1: De�na o estado inicial x0i = (x0, 0) e Xi = ∅.
• Passo2: Forme os conjuntos Σoi, ΣSoij, para todo j ∈ Im, de acordo com as
Equações (3.1) e (3.3), respectivamente. Forme os conjuntos ΣSoide acordo
com a Equação (3.2). Forme os conjuntos Σi de acordo com a Equação (3.4).
38
• Passo 3: Crie uma �la FIFO F . Adicione x0i a F .
• Passo 4: While F 6= ∅ faça:
� Passo 4.1: (x, q)← Head(F ) e Dequeue(F ).
� Passo 4.2: Xi ← Xi ∪ {(x, q)}.� Passo 4.3: Seja q = q1q2...ql e Il = {1, ..., l}. Forme os seguintes
conjuntos de índices:
∗ (a) Ioi = Ioi(q,Σoi), de acordo com a Equação (3.10).
∗ (b) It,r = Il\Ioi.
� Passo 4.4: For σ ∈ Γ(x):
∗ (a) Set FLAG = TRUE.
∗ (b) If Ioi 6= ∅ then:While (k ∈ Ioi) ∧ (FLAG = TRUE):
· (i) Compute
minet(qk) =
{∑(p∈It,r\Ik) qp, k < l
0, se k = l
}.
· (ii) Compute ρ = ms(qk), de acordo com a Equação (3.9).
· (iii) If minet(qk)+ tmin(x, σ) ≥ Tiρ then Set FLAG = FALSE.
∗ (c) If FLAG = TRUE then:
· Set xi = fi((x, q), σ) = (f(x, σ), add(q, x, σ)).
· Else xi não está de�nido.
∗ (d) If (xi /∈ Xi) ∧ (xi /∈ F ) ∧ xi!, then Enqueue(F, xi).
� Passo 4.5: For j ∈ Im:
∗ (a) Forme o conjunto Yj = {k ∈ Ioi : qk ∈ Σoij}.∗ (b) If Yj 6= ∅ then· (i) Compute v = min(Yj).
· (ii) Compute σsv = ψ(qv). A função ψi é de�nida como ψi : Σ∗oi →Σs∗oi, na qual ψi(ε) = ε, ψi(σ) = σsi e ψi(sσ) = ψi(s)ψi(σ), ∀s ∈
Σ∗oi e σ ∈ Σoi.
· (iii) De�na xi = fi((x, q), σsv) = (x, rem(q, v)).
39
· (iv) If (xi /∈ Xi) ∧ (xi /∈ F ), then enqueue(F, xi).
• Passo 5: De�na Γi(xi) = {σ ∈ Σi : fi(xi, σ)!}, ∀xi ∈ Xi.
O Algoritmo 3.1 começa de�nindo o estado inicial do autômato Gi, no qual
x0 é o estado inicial do autômato que modela a planta e o segundo componente,
0 (zero), signi�ca que não há eventos sendo transmitidos ao diagnosticador local
LDi no estado x0i . No passo 2, são formados os conjuntos de eventos observáveis
baseado na informação de entrada Σoij , ∀j ∈ Im. O passo 3 cria uma �la F, FIFO,
e adiciona o estado inicial x0i a ela. Já no passo 4, enquanto a �la F não está vazia,
o algoritmo entra em loop executando as seguintes instruções: remove o primeiro
elemento da �la e salva nas variáveis (x, q).; adiciona (x, q) ao conjunto de estados
de Xi; cria duas listas Ioi e It,r, na qual essa guarda os índices das posições dos
eventos observáveis em q e esta os tempos à direita deles. Para todos os eventos
ativos de x, o algoritmo compara os tempos mínimos para disparo de uma transição
com os tempos máximos de atrasos dos canais que estão transmitindo os eventos,
objetivando determinar se o evento em questão pode ser adicionado a q ou deve ser
observado pelo diagnosticador. O passo 4 é repetido até obter toda a parte acessível
de Gi. Por �m, no passo 5, é computado o conjunto de eventos ativos para todos
os estados de Gi. A explicação com maiores detalhes para esse algoritmo pode ser
encontrada em [1].
Exemplo 3.2 Para o sistema a eventos discretos em rede temporizados apresen-
tado no Exemplo 3.1, o autômato G1 obtido ao seguir os passos do Algoritmo 3.1
é mostrado na Figura 3.5. Podemos notar que a sequência abcn é observada pelo
diagnosticador local LD1 sem troca nas observações, ao passo que a sequência bacn
pode ser observada como bs1as1cns1 ou bs1cs1as1c
n−1s1 .
3.3 Codiagnosticabilidade de um NDESWTS
Visando obter todas as possíveis observações de uma palavra s ∈ L(G) por um
diagnosticador local LDi, é introduzida uma função que insere eventos em s que
sejam pertencentes a ΣSoi, baseada no máximo atraso de comunicação Tij, na função
de tempo mínimo tmin e no conjunto de eventos Σoij . Sejam as projeções
Pi : Σ∗i → Σ∗,
Pi,oij : Σ∗i → Σ∗oij ,
40
(x2 , {a})
(x5 , {a})
(x5 , {c})
(x3 , {0})
(x4 , {b})
(x0 , {0})
(x1 , {0})
(x4 , {0})
(x5 , {0})
(x3 , {b})
(x2 , {0})
(x5 , {a, 1, c})
(x5 , {a, 1})
(x3 , {c})
cs1
b
a
as1
bs1
a
as1 cs1
cs1
c
c b
as1
bs1
σf
c
as1
Figura 3.5: Autômato G1 do Exemplo 3.2.
Pi,sij : Σ∗i → Σs∗oij,
Pis : Σ∗i → Σs∗oi .
E seja wσ(l) o pre�xo de uma palavra w ∈ Σ∗i cujo último evento é a l-ésima
ocorrência de σ, e seja w(l)σs,i o pre�xo de w cujo último evento é a l-ésima ocorrência
de σsi , se σ(l)si ∈ w, ou w, se σ(l)
si /∈ w.
Exemplo 3.3 Seja Σ1 = {o, p, q, σf , os1 , qs1} e w = opos1oqqs1os1q. Temos que:
wo(2) = opos1o,
wo(1)s1
= opos1,
wq(2)s1
= opos1oqqs1os1q.
A seguir é de�nida a função de inserção, que é capaz de calcular o conjunto de pa-
lavras em Σ∗i associadas às possíveis observações de uma palavra s por determinado
diagnosticador local LDi.
41
De�nição 3.3 (Função de Inserção) A função de inserção associada ao diag-
nosticador local LDi e ao conjunto de eventos observáveis Σoij transmitidos pelo
canal chij sujeitos aos atrasos máximos Tij, é um mapeamento:
Xi : L(G)→ 2Σ∗i
s 7→ Xi(s),
na qual w ∈ Xi(s) se satisfaz as seguintes condições:
1 Pi(w) = s;
2 Para todo σ ∈ Σoij , e σ(l) ∈ w:
tmin(x0, Pi(wσ(l)si
))− tmin(x0, Pi(wσ(l))) < Tij;
3 Para todo σsi ∈ Σsoij, e σ
(l)si ∈ w:
σ(l) ∈ wσ(l)si
,
e
||Pi,σij(wσ(l))|| = ||Pi,sij(wσ(l)si
)||.
A extensão de Xi ao domínio 2L(G) é de�nida como Xi(L(G)) =⋃t∈L(G)Xi(t). A
condição 1 estabelece que eventos em Σoi não podem ser inseridos em s para formar
w, ou seja, somente w pode ser obtido a partir de s ao inserir eventos de Σsoi. A
condição 2 estabelece que o atraso máximo entre a ocorrência de um evento σ ∈ Σoij
e sua observação σsi ∈ Σsoij
não seja maior que o atraso máximo Tij. A condição 3
estabelece que a observação σsi de um evento σ aconteça somente após a ocorrência
de σ em uma palavra w, e que a observação de eventos transmitidos por um mesmo
canal de comunicação estejam na mesma ordem de suas ocorrências em s.
Exemplo 3.4 Considere o NDESWTS = (G, tmin, T ) mostrado na Figura 3.2 e
assuma que a palavra s1 = σfabcn, n ∈ N, tenha sido executada por G. Considere os
traços w1, w2, w3, w4 ∈ Σ∗1, sendo w1 = σfaabbsas(ccs)n, w2 = σfabasbs(ccs)
n, w3 =
σfaasbsb(ccs)n e w4 = σfaasbccsbs(ccs)
n−1. Este exemplo foi retirado de [1].
Para w1: P1(w1) = aabcn 6= s1, ou seja, viola a condição 1 da de�nição da
função de inserção.
Para w2: tmin(x0, P1(σfabas)) − tmin(x0, P1(σfa)) = tmin(x0, σfab) −tmin(x0, σfa) = (0.1 + 1 + 3) − (0.1 + 1) = 3 > T11 = 2, ou seja, w2 viola a
condição 2 da de�nição da função de inserção.
42
Para w3: b(1)s ∈ w3, mas b
(1) /∈ w3b(1)s
, ou seja, viola a condição 3 da de�nição da
função de inserção.
Para w4: Um evento c é observado antes de b, isso não pode ocorrer em razão
dos eventos b e c serem transmitidos pelo mesmo canal e isso pode ser veri�cado por
||P1,o12(σfaasb)|| = ||b|| = 1 6= ||P1,s12(σfaasbccsbs)|| = ||csbs|| = 2, ou seja, w4 viola
a condição 3 da de�nição da função de inserção.
O conjunto com todas as possíveis observações da palavra s1 é dado por X1(s1) =
{σfaasbbs(ccs)n}. E, como é de se esperar, a projeção em Σso1
de todas as palavras
em X1(s1) é P1s(X1(s1)) = s1s = asbscns .
Atrasos na comunicação são capazes de alterar a decisão do diagnosticador a
respeito da ocorrência de falhas, mostrando-se necessário o desenvolvimento de uma
nova de�nição de codiagnosticabilidade para NDESWTS que abranja essa possibi-
lidade.
De�nição 3.4 Uma linguagem L, gerada por G, é dita ser NDESWTS codiagnos-
ticável em relação a Xi, para i = 1, ..., Ns e Σf se:
(∃z ∈ N)(∀s ∈ Ψ(Σf ))(∀t ∈ L/s, ||t|| ≥ z)⇒
(∃i ∈ {1, ..., Ns})(∀ω ∈ P−1is (Pis(Xi(st))) ∩ L)(Σf ∈ ωi).
De acordo com a de�nição 3.4, a linguagem L não é codiagnosticável se existir
uma palavra s que contenha o evento de falha e uma palavra t de comprimento
arbitrariamente longo após a ocorrência da falha, de forma que existam observações
iguais de st e das palavras ωi com Σf /∈ ωi, para i = 1, ..., Ns. A perda de codiagnos-
ticabilidade pode ocorrer devido à troca de ordem e possíveis perdas de observação
de eventos que ocasionem observações ambíguas em todos os diagnosticadores locais.
3.3.1 Teste de Codiagnosticabilidade de um NDESWTS
A codiagnosticabilidade de um NDESWTS utilizando diagnosticadores pode ser
veri�cada executando-se o Algoritmo 3.2 apresentado em [1].
Algoritmo 3.2 (Teste de codiagnosticabilidade de um NDESWTS)
Entrada: Autômato Gi = (Xi,Σi, fi,Γi, xi0) para i = 1, ..., Ns.
Saída: Decisão a respeito da codiagnosticabilidade do NDESWTS: Codiagnos-
ticável ou Não.
• Passo 1: Compute o autômato Gscci = Gdi ||Gli, para i ∈ {1, ..., Ns}, sendoGdi = OBS(Gli ,Σ
soi
) e Gli = Gi||Al.
43
({11Y, 10Y }, (10, Y ))
({13Y, 12Y }, (13, Y ))
({2N, 3N, 6N}, (2, N))
({9Y, 8Y, 0N, 1N}, (8, Y ))
({9Y, 8Y, 0N, 1N}, (9, Y ))
({9Y, 8Y, 0N, 1N}, (0, N))
({2N, 3N, 6N}, (3, N))
({4N, 5N}, (4, N))
({4N, 5N}, (5, N))
({11Y, 10Y }, (11, Y ))
({7N}, (7, N))
({2N, 3N, 6N}, (6, N))
({9Y, 8Y, 0N, 1N}, (1, N))
({13Y, 12Y }, (12, Y ))
cs1
b
as1 as1
a
as1
cs1
σf
cs1
a
c
bs1
cb
c
bs1
as1
Figura 3.6: Autômato GNETscc = Gscc1 = Gd1||Gl1 do Exemplo 3.2.
• Passo 2: Marque todas as componentes fortemente conexas de Gscci, i ∈{1, ..., Ns}, formadas por estados (xdi , xli), de forma que xdi seja incerto (NY)
e xli seja um estado certo de que ocorreu a falha (Y).
• Passo 3: Compute o autômato GNETscc = ||Ns
i=1Gscci.
• Passo 4: Veri�car a existência de componentes fortemente conexos formados
por estados marcados em GNETscc . Caso existam, a linguagem L gerada pelo
autômato G é não NDESWTS codiagnosticável em relação a Xi, Pis, i =
1, ...Ns e Σf = {σf}. Caso contrário, L é NDESWTS codiagnosticável.
O Algoritmo 3.2 computa o autômato Gscci a partir dos diagnosticadores lo-
cais Gdi e Gli , marca as componentes incertas de Gscci , computa o autômato
GNETscc = ||(Ns)
i=1 Gscci e veri�ca se existem componentes fortemente conexas forma-
das por estados marcados. Caso existam, a linguagem L gerada pelo autômato G
é não NDESWTS codiagnosticável em relação a Xi, Pis, i = 1, ...Ns e Σf = {σf}.Caso contrário, L é NDESWTS codiagnosticável.
Exemplo 3.5 Na Figura 3.6, é mostrado o autômato GNETscc = Gscc1 =
OBS(G1||Al,Σso1
) calculado a partir do NDESWTS = (G, tmin, T ) do Exemplo
44
3.1. Os estados marcados em Gscc são incertos. Analisando a Figura 3.6, percebe-se
que não há componentes fortemente conexas formadas por estados marcados (incer-
tos), ou seja, a linguagem gerada por G é codiagnosticável em rede em relação a
X1, P1s e Σf = {σf}.
45
Capítulo 4
Planta Mecatrônica Cube Assembly
A planta mecatrônica educacional localizada no Laboratório de Controle e Automa-
ção da UFRJ, representa uma linha de montagem de cubos. Nela, são realizados
processos típicos de uma manufatura como seleção de material, transporte por es-
teiras, prensa pneumática, transporte de peça via braço robótico, armazenamento
automático de peças prontas, etc. A planta é composta de três módulos, sendo o
módulo (i) responsável pela seleção das peças por meio de sensores, o módulo (ii)
responsável por prensar as duas metades dos cubos e o módulo (iii) responsável por
armazenar as peças fabricadas. Além disso, existem três tipos de metades de cubo
disponíveis: metálica, plástica branca e plástica preta. As metades de cubo são
mostradas na Figura 4.1.
Figura 4.1: Três metades de cubos disponíveis: da esquerda para a direita sãomostradas as peças de metal, plástico branco e plástico preto. Na �leira de cima asmetades de cubo encontram-se com a concavidade voltada para baixo, e na �leiraabaixo com a concavidade voltada para cima.
O controle a eventos discretos é realizado pelo CLP Siemens S7-300 (CPU 314C
2PN/DP) que conta com um módulo (DI16/DO16X DC 24V) de 16 entradas e 16
saídas digitais, um módulo (DI32X DC 24V - modelo 321 1BL00 0AA0) contendo 32
46
entradas e digitais e um módulo (DO 16X DC 24V/0,5A - modelo 322 1BH01-0AA0)
com 16 saídas digitais. Vale ressaltar que as entradas e saídas digitais do CLP são
representadas por endereços mnemônicos, sendo as entradas representadas da forma
%Ix.y e as saídas por %Qx.y.
Neste capítulo, uma breve revisão a respeito dos CLPs, incluindo as linguagens
Ladder e SCL, e os métodos de conversão de RPIC para Ladder e de autômato para
SCL, são apresentados na seção 4.1. Na seção 4.2, são descritos os componentes do
módulo (i) da planta mecatrônica e a forma como eles operam. Os demais módulos
e componentes da planta mecatrônica não serão aqui descritos, em razão de não
terem sido utilizados neste trabalho.
4.1 Controlador Lógico Programável
O Controlador Lógico Programável (CLP) é um equipamento digital voltado para
aplicações industriais, e tem como principal característica a capacidade de armazenar
instruções em sua memória interna e executar funções especí�cas tais como lógica,
aritmética, temporização, etc. O CLP pode enviar sinais digitais e/ou analógicos
em suas saídas objetivando efetuar o controle de determinados processos a partir
dos sinais digitais e/ou analógicos que recebem em suas entradas.
Neste capítulo, apresenta-se na seção 4.1.1, um resumo do funcionamento dos
CLPs; na seção 4.1.2, são apresentados blocos frequentemente utilizados no Ladder
e suas funções; na seção 4.1.3, é apresentada a linguagem de controle estruturada
utilizada nos CLPs fabricados pela Siemens; na seção 4.1.4, é mostrado um método
para converter uma RPIC em Ladder e, por último, na seção 4.1.5, é mostrada uma
maneira de converter autômato em linguagem de controle estrutura.
4.1.1 Funcionamento do CLP
Basicamente, o controlador lógico programável opera seguindo uma combinação ló-
gica e sequencial que consiste em ler os registros de entrada, executar o programa
do usuário e, por �m, atualizar os registros de saída e as variáveis internas. Quando
todas as etapas são concluídas, um novo ciclo de varredura é iniciado. A duração de
cada ciclo de varredura é, em geral, da ordem de milissegundos. Dessa forma, o pro-
grama armazenado pelo usuário é executado em loop in�nito até que um comando
externo o faça parar.
Os CLPs oferecem suporte a até cinco linguagens de programação de�nidas pela
IEC 61131, são elas: Lista de Instruções (Instruction List - IL), texto estruturado
(Structured Text - ST), diagrama de bloco de funções (Function Block Diagram -
FBD), diagrama Ladder (Ladder Diagram - LD) e sequenciamento grá�co de funções
47
(Sequential Function Chart - SFC).
Neste trabalho utiliza-se a linguagem Ladder e a linguagem de controle estru-
turada (Structured Control Language - SCL). A linguagem SCL é suportada pelos
CLPs da Siemens e segue os padrões da linguagem ST de�nidos pela norma IEC
61131.
4.1.2 Linguagem Ladder
Atualmente o Ladder é um auxílio grá�co para programação de CLPs, sendo suas
funções lógicas representadas por contatos e bobinas de modo análogo a um esquema
elétrico. Essa linguagem é amplamente utilizada e está disponível na maioria dos
CLPs. A seguir são apresentados alguns dos elementos básicos da linguagem.
• Contatos NA e NF: O contato normalmente aberto (NA), encontra-se aberto
quando a variável booleana associada a ele possui valor 0, e fechado quando a variável
possui valor 1. O contato normalmente fechado (NF) opera de forma oposta ao
contato NA, ou seja, encontra-se fechado quando a variável booleana associada a ele
possui valor 0, e aberto quando a variável possui valor 1. Os contatos NA e NF são
mostrados na Figura 4.2 (a) e (b), respectivamente.
Figura 4.2: Contato normalmente aberto (a) e contato normalmente fechado (b).
• Contatos Tipo P: O contato tipo P, mostrado na Figura 4.3 (a), é utilizado para
detectar borda de subida, isto é, quando a variável booleana passa do valor lógico
0 para o valor lógico 1, o contato é fechado. Após o ciclo de varredura, o contato
volta a �car aberto até que uma nova borda de subida seja detectada.
Figura 4.3: Contato tipo P.
• Contatos Tipo N: O contato tipo N, mostrado na Figura 4.3 (b), opera de
forma similar ao contato tipo P. Ao detectar uma borda de descida, isto é, quando a
48
variável booleana passa do valor lógico 1 para o valor lógico 0, o contato é fechado.
Após o ciclo de varredura, o contato volta a �car aberto até que uma nova borda de
descida seja detectada.
• Bobina Simples: As bobinas são utilizadas para representar as saídas físicas do
CLP ou as variáveis da memória interna. As bobinas mais frequentemente utilizadas
são as bobinas simples, bobinas SET e bobinas RESET. A bobina simples, quando
acionada, faz o valor lógico da variável booleana, associada a uma saída do CLP ou
a determinada variável de memória, passar ao nível lógico 1. Caso a bobina simples
não seja acionada, a variável booleana permanece no valor lógico 0. A Figura 4.4
(a) mostra uma bobina simples.
Figura 4.4: Bobina simples.
• Bobina SET: A bobina SET, quando acionada, faz com que o valor lógico da
variável booleana, associada a uma saída digital do CLP ou a uma determinada
variável de memória, se torne 1. Esse valor permanece inalterado até que uma
bobina RESET, associada à mesma variável, seja acionada, levando, então, o valor
para 0. A Figura 4.4 (b) mostra uma bobina SET.
• Bobina RESET: A bobina RESET, quando acionada, faz com que o valor lógico
da variável booleana, associada a uma saída digital do CLP ou a uma determinada
variável de memória, torne-se 0. Esse valor permanece inalterado até que uma
bobina simples ou SET associada à mesma variável seja acionada, levando, então, o
valor para 1. A Figura 4.4 (c) mostra uma bobina RESET.
• Timer ON Delay - TON: Temporizadores são utilizados para gerar atrasos
prede�nidos. O temporizador TON, mostrado na Figura 4.5 (a), atrasa a atribuição
de valor 1 à saída Q por um tempo PT prede�nido. A contagem do tempo começa
quando o valor lógico na entrada IN passa de 0 para 1, e, quando ela atinge o valor
determinado em PT , Q é levado ao nível lógico 1 e permanece nesse estado enquanto
IN for mantido em nível lógico 1. Quando IN é desenergizado, a saída Q é levada
a 0 e o contador de tempo é zerado. O tempo decorrido durante a contagem que
está sendo realizada no momento pelo temporizador é armazenado na variável ET.
• Timer OFF Delay - TOF: O temporizador TOF, mostrado na Figura 4.5 (b),
atrasa a atribuição de valor 0 à saída Q por um tempo PT prede�nido. A contagem
do tempo começa quando o valor lógico na entrada IN passa de 1 para 0, e, quando
49
Figura 4.5: Temporizadores TON (a) e TOF (b).
ela atinge o valor determinado em PT , Q é levado ao nível lógico 0 e permanece
nesse estado enquanto IN for mantido em nível lógico 0. Quando IN é energizado,
a saída Q é levada ao nível 1 imediatamente e o contador de tempo é zerado. O
tempo decorrido durante a contagem que está sendo realizada no momento pelo
temporizador é armazenado na variável ET.
4.1.3 Structured Control Language - SCL
SCL é uma linguagem de programação textual de alto nível, baseada em PASCAL e
no padrão ST de�nido pela norma IEC 61131, e que tem por objetivo complementar
e estender a linguagem de programação Ladder. Em adição aos elementos de alto
nível, a linguagem também inclui elementos típicos de CLPs como entradas, saídas,
temporizadores, chamadas de blocos de funções, etc.
A seguir são apresentados os elementos básicos da linguagem que são utilizados
neste trabalho. Vale ressaltar que, neste capítulo, os exemplos são destinados a
apresentar as regras sintáticas da linguagem e não se atém às regras léxicas. O
manual de referência para a linguagem pode ser encontrado em [11].
• Atribuição de Valores às Variáveis: Um simples exemplo de atribuição de
valor a uma variável é mostrado no Exemplo 4.1.
Exemplo 4.1 Atribuir valor 10 à variável, do tipo INT, ALTURA:
ALTURA := 10;
• IF, ELSIF e ELSE: Um exemplo simples do uso do IF, ELSIF e ELSE para
validar expressões envolvendo variáveis booleanas é apresentado no Exemplo 4.2.
Exemplo 4.2 Crie uma estrutura utilizando IF, ELSIF e ELSE que obedeça às
seguintes regras: se VAR1 possui valor lógico igual 1 (TRUE) atribua valor 1 à
variável N; ser VAR1 e VAR2 possuem valores lógicos iguais a 0 (FALSE), atribua
valor 2 à variável N; e, caso os dois casos não ocorram, atribua valor 3 à variável N.
50
IF VAR1 THEN
N:=1;
ELSIF NOT VAR2 THEN
N:=2;
ELSE
N:=3;
END_IF;
• AND e OR: Os operadores lógicos AND e OR podem ser usados de forma
simples, como é mostrado nos Exemplos 4.3 e 4.4.
Exemplo 4.3 Se VAR1 e VAR2 possuírem valor lógico igual a 1, atribua o valor
5 à variável N.
IF VAR1 AND VAR2 THEN
N:=5;
END_IF;
Exemplo 4.4 Se VAR1 ou VAR2 possuírem valor lógico igual a 1, atribua o valor
7 à variável N.
IF VAR1 OR VAR2 THEN
N:=7;
END_IF;
• Laço FOR: Um exemplo simples de uso do FOR para acessar valores de um
ARRAY e alterar seus valores é mostrado no Exemplo 4.5.
Exemplo 4.5 Execute um Loop FOR para atribuir valores 1+<índex do elemento>
para os 11 primeiros elementos do vetor VALORES.
FOR Count := 0 TO 10 DO
VALORES[Count] := 1 + Count;
END_FOR;
51
p1
p2
t1 t2botao d1 = 1 min
Acender luz branca
Acender luz azul
Figura 4.6: Exemplo de uma RPIC utilizada para acionar duas lâmpadas.
4.1.4 Diagrama Ladder a partir de uma RPIC
Um método prático para implementar um diagrama Ladder em um CLP, a partir de
uma RPIC é proposto em [10]. Nesse método, a implementação é dividida em cinco
módulos: inicialização, eventos, condições para o disparo da transição, dinâmica e
ações.
O módulo de inicialização é responsável por distribuir as �chas para os lugares
apropriados de acordo com a marcação inicial da RPIC. Esse módulo é executado
apenas uma vez e durante o primeiro ciclo de varredura do programa.
Eventos, em geral, estão associados à borda de subida ou borda de descida dos
sinais dos sensores, e podem ser detectadas usando contatos do tipo P ou tipo N. De
uma forma geral, o módulo de eventos está associado à identi�cação da ocorrência
de eventos externos e sua posterior �tradução� em eventos internos ao CLP.
No módulo de condições para o disparo, são de�nidas as condições exigidas para
o disparo das transições. No módulo da dinâmica é feita a atualização da marcação
da RPIC após o disparo de determinada transição. Por �m, o módulo de ações é
destinado a associar bobinas de saída aos lugares que possuem ações contínuas ou
impulsivas.
Exemplo 4.6 A partir da RPIC apresentada na Figura 2.20, representada nova-
mente na Figura 4.6, utilizar o método proposto em [10] para obter a sua represen-
tação em diagrama Ladder.
• Módulo de inicialização: O módulo de inicialização é formado por bobinas
SET, objetivando adicionar �chas nos lugares inicialmente marcados, e, para
que esse módulo seja executado apenas uma vez, um contato normalmente
fechado é posto em série com todas as bobinas, incluindo a sua própria bobina,
como mostrado na Figura 4.7.
• Módulo de eventos: O módulo de eventos associa a borda de subida do
acionamento do Botão a uma variável de memória interna chamada botãoUP,
conforme mostrado na Figura 4.8.
52
Figura 4.7: Módulo de inicialização do Exemplo 4.6.
Figura 4.8: Módulo de eventos do Exemplo 4.6.
• Módulo de condições para o disparo: O módulo de condições para o
disparo tem por objetivo estabelecer as condições para o disparo de transições,
conforme mostrado na Figura 4.9. Observa-se que a transição t1 só irá disparar
se houver �cha em p1 e botãoUP for acionado, e a transição t2 será disparada
quando p2 completar 1 minuto com a �cha.
Figura 4.9: Módulo de condições para o disparo do Exemplo 4.6.
• Módulo da dinâmica: O módulo da dinâmica é responsável por atualizar o
estado da RPIC após o disparo de determinada transição, conforme mostrado
na Figura 4.10. Ao disparar t1, é retirada a �cha de p1 e adicionada uma �cha
a p2. Quando t2 dispara, p2 perde sua �cha, ao passo que p1 recebe uma �cha.
• Módulo das ações: O módulo das ações é responsável por executar as ações
associadas aos lugares, conforme mostrado na Figura 4.11. Se p1 possui �cha,
53
Figura 4.10: Módulo da dinâmica do Exemplo 4.6.
a bobina associada à luz branca deve permanecer acionada. De forma similar,
se p2 possui �cha, a bobina associada à luz azul deve permanecer acionada.
Figura 4.11: Módulo das Ações do Exemplo 4.6.
4.1.5 SCL a partir de um Autômato
Nesta seção vamos apresentar um algoritmo 4.1 para que, a partir do diagrama
de transição de estados de um autômato determinístico �nito, possamos obter sua
representação em linguagem SCL. Vale ressaltar que esse método é utilizado com o
intuito de seguir a evolução dos estados do sistema e não controlá-lo. Um método
parecido pode ser encontrado em [12], onde um conjunto de regras é apresentado com
vistas à implementação de supervisores modulares modelados por autômatos �nitos
utilizando texto estruturado (ST). O Exemplo 4.7 ilustra a utilização do Algoritmo
4.1. Vale ressaltar que durante a fase de implementação do código gerado, o endereço
de memória que guarda o estado inicial do autômato deve ser inicializada com valor
lógico igual a 1 no próprio CLP.
54
Algoritmo 4.1 (Obtenção do código SCL a partir de um autômato)
Entrada: Autômato G = (X,Σ, f,Γ, x0, Xm).
Saída: Código em SCL que representa o diagrama de transição de estados do
autômato G.
• Passo 1: De�na a variável code.
• Passo 2: Para cada estado xi ∈ X, e para cada um dos eventos σ ∈ Γ(xi), in-
cremente a variável code, responsável por guardar o código SCL que representa
o autômato G, com o seguinte código:
IF xi AND σ THEN
xi := 0;
f(xi, σ) := 1;
END_IF;
Exemplo 4.7 Considere o autômato mostrado na Figura 4.12. Utilizando o Algo-
ritmo 4.1 obtemos o seguinte código:
x1 x2
e1, e2
e1
Figura 4.12: Autômato utilizado no exemplo 4.7.
O código em SCl que representa o autômato é:
IF x1 AND e1 THEN
x1 := 0;
x2 := 1;
END_IF;
IF x2 AND e1 THEN
x2 := 0;
x1 := 1;
END_IF;
IF x2 AND e2 THEN
55
x2 := 0;
x1 := 1;
END_IF;
4.2 Módulo 1 - Seleção de Peças
Note que o módulo 1 da planta, mostrado na Figura 4.13, contém duas unidades
armazenadoras, um painel de operações, uma esteira rolante e cinco sensores, sendo
um capacitivo, um pneumático vertical, um óptico por re�exão, um indutivo e um
óptico por barreira. Além disso, cada armazém possui um pistão horizontal desti-
nado a empurrar peças para a esteira, um sensor para detectar quando o pistão está
recuado, outro para detectar quando está estendido e um outro para detectar se há
peça disponível no armazém. O sistema de acionamento dos atuadores conta ainda
com um relé de proteção que deve ser acionado para permitir seu funcionamento. A
seguir, os componentes do módulo (i) serão descritos em maiores detalhes, de forma
a permitir melhor compreensão do sistema.
Figura 4.13: Módulo 1 da planta mecatrônica, responsável pela seleção de peças pormeio de sensores. Conta com 2 armazéns verticais, um painel de operações, esteirae um conjunto de sensores posicionados sobre ela.
• Relé de segurança: para permitir o funcionamento dos atuadores e motores da
56
planta mecatrônica, o relé de segurança deve ser acionado via CLP, através da saída
%Q124.0.
• Painel de operação: a planta conta com um painel de operação que contém
quatro botoeiras retroiluminadas, uma chave seletora de duas posições, cinco chaves
seletoras liga/ desliga e um botão de emergência.5
As botoeiras Start, Stop, Quit e S6 estão associadas às entradas %I125.4,
%I125.3, %I125.2, %I125.1, respectivamente. Todas as botoeiras são normalmente
abertas, exceto a botoeira Stop, que é normalmente fechada. As lâmpadas verde,
vermelha, azul e branca estão associadas às saídas %Q124.4, %Q124.5, %Q124.6,
%Q124.7, respectivamente.
A chaves seletora de duas posições Hand/Auto, quando colocada no modo Hand
(Auto) energiza a entrada %I125.6 (%I125.5). Quando colocada na posição central,
ela permanece desligada.
As chaves liga/ desliga S1, S2, S3, S4 E S5 estão associadas às entradas %I124.2,
%I124.3, %I124.4, %I124.5 e %I124.7. Quando voltada para a esquerda, encontra-
se na posição OFF e, virada para direita, encontra-se na posição ON.
O botão de emergência, quando pressionado, desarma o relé de segurança da
planta, consequentemente impedindo o funcionamento dos motores e atuadores.
• Armazenadores MAG1 E MAG2: são os responsáveis pelo estoque de peças
na entrada no sistema. Cada armazém é uma torre vertical que guarda metades
de cubos, empilhados, e contam com um atuador pneumático para empurrar peças
na esteira e sensores para identi�car a presença de peças no armazém e a posição
(estendido ou recuado) do atuador pneumático.
Quando o valor na saída %Q4.5 (%Q4.7) é igual a 1, o atuador pneumático do
MAG1 (MAG2) estende, empurrando a peça em direção à esteira. Para recuar o
atuador pneumático do MAG1 (MAG2), deve-se levar a saída %Q4.4 (%Q4.6) ao
valor lógico 1.
O atuador conta com sensores que identi�cam se ele está completamente recuado
ou estendido. Quando %I0.5 (%I1.0) está em nível alto, signi�ca que o atuador de
MAG1 (MAG2) está completamente estendido, e se %I0.6 (%I1.1) estiver em nível
alto, signi�ca que o atuador de MAG1 (MAG2) está completamente recuado. Para
que o sistema opere de forma segura, é desejável que a esteira esteja desligada no
momento em que uma peça é empurrada em direção a ela.
Com o intuito de determinar se há peças no armazém, existe um sensor mecânico
de �m de curso, normalmente fechado, que fornece nível lógico 0 na saída quando há
2 ou mais peças no armazém. Se houver menos de duas peças em MAG1 (MAG2),
o nível lógico na entrada %I0.7 (%I1.2) será 1, e, caso haja duas ou mais peças, o
nível lógico será 0.
• Esteira rolante: tem por objetivo conduzir as peças fornecidas pelo armazém, até
57
uma de suas extremidades. Quando acionada para conduzir peças para a direita, as
metades de cubo passam por diversos sensores capazes de identi�car qual peça está
passando pela esteira e executar as ações devidas. Normalmente, quando acionada
para a esquerda, signi�ca que a peça, após passar pela análise de determinados
sensores, está sendo rejeitada - ou seja, foi enviada para o descarte. Enquanto o
sinal na bobina %Q4.0 (%Q4.1) é mantido em nível lógico 1, a esteira se movimenta
para a direita (esquerda). Se as duas bobinas permanecerem em nível lógico 0, a
esteira não se movimentará.
Enquanto uma peça é conduzida para a direita, ela passa pelos seguintes sensores,
em ordem: capacitivo, profundidade, óptico por re�exão, indutivo e óptico por
barreira.
• Sensor capacitivo: o sensor capacitivo é destinado à detecção da presença de
qualquer peça que passe pelo seu campo de atuação. Quando uma peça é detectada,
o sensor envia um sinal de nível lógico 1 à entrada %I0.1 até que a peça saia de seu
campo de atuação.
• Sensor de profundidade: o sensor de profundidade é utilizado para determinar
se um cubo encontra-se com a concavidade voltada pra cima ou para baixo. Quando
o atuador pneumático do sensor é estendido completamente, signi�ca que a peça está
com a concavidade voltada para cima. Caso contrário, infere-se que a peça esteja
com a concavidade voltada para baixo.
Quando a saída %Q4.2 recebe o valor lógico 1, o atuador pneumático é estendido.
Se o atuador chegar ao ponto máximo de excursão, a entrada %I0.2 recebe valor
lógico 1 e, caso contrário, a entrada %I0.2 é mantida em nível lógico zero. Para
recuar o atuador, atribui-se valor lógico 1 à saída %Q4.3. Vale ressaltar que o
atuador funciona de forma impulsiva.
• Sensor óptico por re�exão: o sensor óptico por re�exão é utilizado para
veri�car a cor da peça. Se a peça for branca ou metálica, a entrada %I0.3 recebe
valor lógico 1. Se a peça for preta, o valor lógico permanecerá 0.
• Sensor indutivo: o sensor indutivo detecta se a metade do cubo é de metal.
Se for de metal, o valor lógico na entrada %I0.4 será igual a 1. Se a peça for de
plástico, o valor lógico permanecerá em 0.
• Sensor óptico por barreira: o sensor óptico por barreira serve para detectar a
passagem de qualquer uma das peças pela esteira. Se o sensor detectar a passagem
de alguma peça, a entrada %I0.0 receberá valor lógico 1. Caso contrário, o valor
lógico permanecerá 0.
58
Capítulo 5
Implementação do Diagnosticador
em Rede
Este trabalho objetiva implementar três diagnosticadores robustos a atrasos na co-
municação de eventos, tendo como base um modelo a eventos discretos em rede
temporizados (NDESWTS) que será aqui desenvolvido. Cada um desses diagnos-
ticadores será calculado para diferentes tempos máximos de atrasos nos canais de
comunicação e implementados no CLP S7-1200. Após todos eles terem sido im-
plementados, os atrasos simulados nos canais de comunicação serão variados e os
comportamentos de cada um dos diagnosticadores serão analisados. Além disso, se-
rão implementados dois diagnosticadores não robustos a atrasos, estando um deles
sujeito aos atrasos simulados na comunicação de eventos e o outro não.
Neste trabalho, considera-se que a planta seja destinada à seleção de peças que
foram colocadas em ordem aleatória no armazém vertical MAG2 e que, a partir das
leituras dos sensores presentes na esteira, o sistema atue da seguinte forma: caso
a planta receba uma peça metálica com a concavidade voltada para cima, a peça
deve permanecer parada na extremidade direita da esteira aguardando sua retirada,
e caso seja detectado que a concavidade da peça esteja voltada para baixo, a peça
deve ser imediatamente mandada para o descarte (esteira se move para a esquerda).
Além disso, se a peça for de plástico preto com a concavidade voltada para cima,
também deve ser mandada para o descarte.
A implementação do diagnosticador será feita considerando-se uma estrutura
em rede conectando três locais de medição a um diagnosticador local, conforme
mostrado na Figura 5.1, objetivando diagnosticar uma falha no sensor óptico por
re�exão, também chamado de sensor de cor. O diagnosticador local foi implemen-
tado no CLP S7-1200 e os três locais de medição foram simulados no CLP S7-300.
Os atrasos nas transmissões dos eventos foram simulados no CLP S7-1200 após a
ocorrência do evento ter sido comunicada a ele com sucesso.
As etapas para a implementação do sistema com essas características foram:
59
MS1 MS3
Planta
LD1
ch11
Σo11
T11
ch12
Σo12
T12
ch13
Σo13
T13
MS2
Figura 5.1: Estrutura de diagnóstico de falha em rede implementada.
• Desenvolvimento de uma RPIC para modelar o controlador do sistema de
acordo com o que foi anteriormente especi�cado, tendo como base os sensores
e atuadores disponíveis na planta. O controlador modelado pela RPIC leva
em consideração apenas o comportamento normal da planta.
• Observando o sistema controlado, desenvolver um autômato com transições
rotuladas apenas por eventos associados aos sensores da planta. O autômato,
além de modelar a o comportamento normal, também deve modelar o com-
portamento pós-falha do sistema.
• Análise da diagnosticabilidade utilizando o autômato GNETscc tendo como base
o autômato G obtido no passo anterior.
• Con�guração individual dos CLPs no software Totally Integrated Automation
da Siemens.
• Conversão de RPIC para Ladder e sua implementação no CLP S7-300.
• Implementação de G, em Ladder, e Gd, em SCL, no CLP S7-300.
• Medição dos tempos mínimos entre as transições do autômato.
• Cálculo dos diagnosticadores robustos a atrasos.
• Conexão dos CLPs em rede de modo que os locais de medição (S7-300) enviem
informações para o diagnosticador local (S7-1200).
• Implementação dos diagnosticadores robustos e não robusto a atrasos no CLP
S7-1200.
• Análise dos resultados para diferentes tempos de atrasos simulados.
A seguir, todos os passos são explicados detalhadamente.
60
Tabela 5.1: Legendas dos eventos associados aos sensores da Rede de Petri mostradana Figura 5.2. Entre parênteses encontra-se a abreviatura utilizada nas transiçõesdos autômatos.
Eventos Signi�cado
start ↑ (start ↑) Borda de subida do botão start
fdc mag2 (fdc) Sensor de �m de curso do armazém MAG2sensor mag2 estendido (mag ↑) Atuador do MAG2 completamente estendidosensor mag2 recuado (mag ↓) Atuador do MAG2 completamente recuadosensor capacitivo ↑ (cap ↑) Borda de subida do sensor capacitivosensor capacitivo ↓ (cap ↓) Borda de descida do sensor capacitivosensor profundidade ↑ (prf ↑) Borda de subida do sensor de profundidadesensor cor ↑ (cor ↑) Borda de subida do sensor óptico por re�exãosensor indutivo ↑ (ind ↑) Borda de subida do sensor indutivosensor barreira ↑ (bar ↑) Borda de subida do sensor óptico por barreirasensor barreira ↓ (bar ↓) Borda de descida do sensor óptico por barreira
Tabela 5.2: Legendas das ações associadas aos lugares da Rede de Petri mostradana Figura 5.2.
Ações Signi�cado
Ligar LED Verde Ligar a iluminação do botão verdeEsteira Esq. Mover esteira para esquerdaEsteira Dir. Mover esteira para direitaRecuar mag1 Recuar atuador do armazém 1Estender mag2 Estender atuador do armazém 2Recuar mag2 Recuar atuador do armazém 2Estender prof Estender atuador do sensor de profundidadeRecuar prof Recuar atuador do sensor de profundidade
5.1 Desenvolvimento da RPIC
Para que o sistema execute as tarefas anteriormente descritas, o controlador a even-
tos discretos foi modelado pela RPIC mostrada na Figura 5.2, cuja legenda dos
eventos é encontrada na Tabela 5.1 e a legenda das ações na Tabela 5.2. Vamos,
agora, descrever a dinâmica da RPIC mostrada na Figura 5.2.
Inicialmente é colocada uma �cha em p0, e o LED verde é ligado, indicando que
o sistema está pronto para operar. Ao detectar a borda de subida do botão start, a
�cha passa para p1, que prontamente recua todos os atuadores e liga a esteira para a
esquerda por doze segundos, objetivando descartar possíveis peças que tenham sido
deixadas sobre ela. Feitas as etapas iniciais, p2 recebe uma �cha, fazendo com que o
sistema entre no ciclo fechado de seleção de peças. Se houver duas ou mais peças no
armazém MAG2, o sensor fdc mag2 estará em nível lógico 0 e, consequentemente,
fdc mag2 em nível lógico 1, causando o disparo da transição t3. Quando p3 recebe
�cha, o atuador de MAG2 é estendido e uma peça é empurrada para a esteira. Ao
perceber que o atuador está estendido, t4 é disparada e p4 recebe uma �cha. Em
p4, o atuador de MAG2 é recuado e, quando o sensor con�rma isso, t5 é disparada.
Neste ponto, o sistema conta com uma peça na esteira e está preparado para ligá-la
e efetuar a leitura dos demais sensores. Quando p5 recebe uma �cha, a esteira passa
61
t1
b
t2
p1
p0
t3
p2
t4
p3
t5
p4
t7
p6
t6
p5
Recuar prof*Recuar mag1*Recuar mag2*Esteira Esq.
start ↑
T=12 s
fdc mag2
Estender mag2*
sensor mag2 estendido
Recuar mag2*
sensor mag2 recuado
Esteira Dir.
sensor capacitivo ↑
T=1,6 s
t9
p8
t10
t11
p9
Estender prof*
T=500 ms
Recuar prof*
T=500 ms
sensor capacitivo ↓
T=6 s
p10
t12
sensor profundidade ↑
t13 T=500 ms
p11
t14
p12Esteira Dir.
sensor cor ↑
t15
p13
sensor indutivo ↑
t16
p14
sensor barreira ↑
p15
sensor barreira ↑ t18
p16
sensor barreira ↓t17
Recuar prof*
Esteira Esq. e Esteira Dir.
t19
p17Esteira Esq.
t20
p18
sensor barreira ↓
sensor capacitivo ↑
t21
Ligar LED verde
Esteira Dir.
Esteira Esq.
t8
Esteira Esq.
Esteira Dir.
Esteira Dir.
λ
p7
Esteira Esq.
Figura 5.2: RPIC utilizada para modelar o controlador do módulo 1 da plantamecatrônica. As cores representam os diferentes caminhos que podem ser seguidospela rede.
62
a se movimentar para direita. Ao perceber a presença de uma peça, é detectada uma
borda de subida no sensor capacitivo, causando o disparo da transição t6. O lugar p6
recebe uma �cha e mantém a esteira ligada por mais 1,6 segundo � tempo necessário
para que a peça �que posicionada corretamente abaixo do sensor de profundidade
� disparando a transição t7. Em p7, o sensor de profundidade recebe um sinal para
estender seu atuador. Sabendo que o sensor leva menos de 500 milissegundos (ms)
para estender completamente o atuador, espera-se esse tempo para detectar uma
possível borda de subida no sensor de profundidade e disparar t12, signi�cando que
a peça está com a concavidade voltada para cima. Caso o atuador não consiga
estender completamente dentro do tempo esperado, infere-se que a peça esteja com
a concavidade voltada para baixo e t8 é disparada. Se t8 dispara, signi�ca que a
peça deve ser rejeitada imediatamente, e p8 recebe uma �cha, fazendo com que o
atuador do sensor de profundidade recue. Após 500 ms, tempo su�ciente para que o
atuador tenha recuado completamente, a transição t9 dispara, p9 recebe uma �cha e
a esteira é ligada para a esquerda. Enquanto a peça está parada embaixo do sensor
de profundidade, o sensor capacitivo ainda permanece em nível lógico 1, então,
quando a peça recuar, será detectada uma borda de descida, disparando a transição
t10. Ao chegar em p10, o sistema aguarda 6 segundos, tempo su�ciente para que a
peça seja descartada, dispara t11 e p2 recebe uma �cha, recomeçando o ciclo. Caso
t12 dispare, o lugar p11 recebe uma �cha e envia um sinal para recuar o atuador do
sensor de profundidade. Após 500 ms, t13 dispara, p12 recebe uma �cha, e aciona
a esteira para a direita. Se a peça for prateada e o sensor óptico por re�exão (cor)
estiver operando corretamente, um sinal lógico alto será enviado ao controlador, e a
transição t14 dispara; caso o sensor de cor não dispare e seja detectada uma borda de
subida no sensor ótico por barreira, a transição t18 é disparada. Se t14 dispara, p13
recebe uma �cha e mantém a esteira movendo-se para a direita. Quando o sensor
indutivo envia um sinal lógico alto para o controlador, a transição t15 dispara, o
lugar p14 recebe uma �cha e mantém a esteira ligada no mesmo sentido. Ao detectar
uma borda de subida no sensor óptico por barreira, t16 dispara e p15 recebe uma
�cha. O sistema permanece em p15 até que a peça seja manualmente retirada e o
sensor óptico por barreira volte ao nível 0. Após detectar a borda de descida, t17
dispara e p2 recebe uma �cha, voltando, então, ao estado inicial. Enquanto a �cha
está em p12, também pode ocorrer o disparo da transição t18, a qual adiciona uma
�cha a p16, que tem por objetivo desligar a esteira � o disparo de t18 signi�ca que
a peça é plástica e de cor preta e deve ser rejeitada ou que o sensor de cor falhou
em identi�car a peça prateada. Automaticamente, ocorre a transição t19, visto que
λ é o evento sempre ocorrente. Quando p17 recebe uma �cha, a esteira começa a
se mover para a esquerda com o intuito de descartar a peça; ao sair da frente do
sensor óptico por barreira, o controlador percebe uma borda de descida e dispara
63
1 2 3 4 5 6
131415
789
12
16
start ↑
fdc mag ↑ mag ↓ cap ↑
cap ↓
prf ↑
fdc11
cor ↑
ind ↑bar ↑bar ↓
fdc
10
bar ↑
bar ↓cap ↑cap ↓fdc
ind ↑
σf, cor
17bar ↑
0
Figura 5.3: Autômato obtido a partir da RPIC contendo somente eventos da plantamecatrônica e considerando uma possível falha no sensor óptico por re�exão (cor ↑).A legenda dos eventos encontra-se na Tabela 5.1.
a transição t20, adicionado uma �cha em p18 até que seja detectada uma borda de
subida no sensor capacitivo, que irá disparar t21. Quando isso ocorre, p9 recebe
uma �cha e prossegue da mesma forma que anteriormente mencionado.
5.2 Desenvolvimento do Autômato
O autômato que modela o comportamento controlado da planta mecatrônica, deno-
tado por G, é mostrado na Figura 5.3. Podemos observar que o autômato modela o
comportamento normal e o de falha da planta mecatrônica.
Analisando a RPIC, percebemos que quando uma peça com a concavidade vol-
tada para cima é detectada e ocorre a falha na leitura do sensor óptico por re�exão,
a RPIC permanecerá parada no lugar p12 e sairá somente quando o sensor óptico
por barreira detectar a presença dessa peça. Quando isso ocorre, a transição t18
da RPIC dispara, fazendo com que a peça passe a ser rejeitada, ou seja, a RPIC
confunde as peças e rejeita uma peça que deveria ter sido aceita. Após a rejeição, a
RPIC opera normalmente como se não houvesse ocorrido a falha.
Já o autômato, inicialmente no estado 6, modela a ocorrência da falha no sensor
de cor por meio de um evento não observável σf, cor. Se o sensor indutivo informar
a passagem de uma peça metálica antes que a leitura do sensor de cor tenha sido
feita, o autômato vai para o estado 17. Quando no estado 17 e o sensor óptico
por barreira envia sinal lógico 1, o autômato passa para o estado 12 e prossegue
evoluindo normalmente.
64
5.3 Análise da Diagnosticabilidade de L(G)O conjunto de eventos do autômato G mostrado na Figura 5.3 é Σ = {start ↑, fdc,mag ↑, mag ↓, cap ↑, cap ↓, prf ↑, ind ↑, bar ↑, bar ↓, cor ↑, σcor}. Considera-se queo conjunto de eventos observáveis do diagnosticador é Σo = Σ\{σcor, cap ↑, cap ↓}.As observações devidas aos sensores capacitivos (cap ↑ e cap ↓) foram excluídas do
diagnosticador para tornar possível ilustrar a perda da robustez em função do atraso
na comunicação dos eventos.
Esta etapa visa analisar a diagnosticabilidade do autômato G em relação à falha
σcor e à projeção Po : Σ∗ → Σ∗o. Com esse intuito, utiliza-se um pacote desenvolvido
em Python para análise de SEDs modelados por autômato, chamado DESLab, tendo
como referência o tutorial desenvolvido em [13]. Esse pacote é capaz de realizar di-
versas operações com autômatos como paralelo e produto, calcular o observador,
diagnosticador, etc. Em especial, destaca-se a sua capacidade de desenhar o dia-
grama de transição de estados de autômatos.
O diagnosticador Gd = Diag(G) obtido utilizando o DESLab é mostrado na
Figura 5.4. Ainda utilizando o DESLab, veri�cou-se que a linguagem gerada por
G é diagnosticável. No Apêndice B, é mostrado o código B.1 implementado para
checar a diagnosticabilidade e desenhar Gd.
5.4 Con�guração Individual dos CLPs no TIA
Nesta etapa, os CLPs são con�gurados individualmente (no sentido de haver um
único cabo conectando o PC diretamente ao CLP) através do software Totally Inte-
grated Automation (TIA) versão 13.
Na tela inicial do software, pressiona-se o botão Create new project, em seguida
de�ne-se um nome para o projeto e, então, clica-se em Create.
Após a criação do projeto, passaremos à con�guração dos dispositivos utilizados:
selecione a opção project view, localizada no canto inferior esquerdo da tela, em
seguida clique em Add new device na barra lateral esquerda. Para adicionar o CLP
S7-300, deve-se navegar na lista de pastas até chegar ao dispositivo, seguindo o
caminho SIMATIC S7-300 → CPU → CPU314C-2 PN/DP → 6ES7 314-6EH04-
0AB0, conforme mostrado na Figura 5.5.
Após adicionar o CLP, os módulos extras de entradas e saídas digitais do CLP S7-
300 devem ser con�gurados. Para tanto, clica-se em Devices & network (localizado
abaixo de Add new device), seleciona-se o CLP S7-300 e depois a aba Device view. Na
lateral direita da tela, deve-se abrir a aba Hardware Catalog e selecionar os seguintes
módulos de expansão: DO16×24VDC/0.5A modelo 6ES7 322-1BH01-0AA0 e o
módulo DI32×24VDC modelo 6ES7 321-1BL00-0AA0. Feito isso, deve-se ajustar
65
{x0N}
{x7N}
{x1N}
{x12Y }
{x2N}
{x3Y }
{x4N, x5N, x11N}
{x10N}
{x17Y }
{x16Y, x6Y }
{x13N, x14N, x15N}
{x11Y, x5Y, x4Y }
{x9Y }
{x2Y }
{x8N}
{x6N, x16Y }
{x13Y, x15Y, x14Y }{x9N}
{x12N}
{x8Y }
{x7Y }
{x3N}
{x10Y }
fdc
ind ↑
mag ↑
bar ↑
bar ↑
ind ↑
mag ↑
fdc
prf ↑
mag ↓
fdc
bar ↓
prf ↑
bar ↑
fdc
start ↑
bar ↑
mag ↓
cor ↑
fdc
ind ↑
bar ↑bar ↓
fdc
bar ↓
bar ↓
fdc
ind ↑
cor ↑
Figura 5.4: Diagnosticador Gd.
66
Figura 5.5: Adicionando novo dispositivo no TIA.
a faixa de endereços de entradas e saídas do módulo DI 24/DO 16_1 que vem
acoplado ao CLP: na mesma aba Device View, clica-se em Device overview, e na
linha DI 24/DO 16_1 deve-se alterar o valor da coluna I address para 124...126 e
na coluna Q address para 124...125. Ao �m, o S7-300 deve estar con�gurado como
mostrado na Figura 5.6.
Agora, a comunicação entre CLP e PC deve ser realizada por uma rede Ethernet
utilizando o protocolo TCP/IP V4. Primeiramente, deve-se alterar o IP do compu-
tador, que neste trabalho será de�nido como 192.168.0.2. Para isso, acesse a central
de rede e compartilhamentos do Windows, clique em Alterar as con�gurações do
adaptador, em seguida clique com o botão direito do mouse sobre a conexão corres-
pondente à placa de rede utilizada para conexão CLP-PC, e selecione Propriedades.
Feito isso, clique duas vezes sobre Protocolo TCP/IP Versão 4 (TCP/IPv4), seleci-
one Usar o seguinte endereço de IP e entre com o IP 192.168.0.2 no campo Endereço
IP, e 255.255.255.0 no campo Máscara de sub-rede, conforme mostrado na Figura
5.7.
A seguir, o IP do CLP deve ser con�gurado: no TIA, clique com o botão direito
do mouse em cima de PLC1 [CPU 314C-2 PN/DP], selecione Properties, depois
PROFINET interface [X2] → Ethernet addresses, marque o campo Set IP address
in the project e preencha com o IP 192.168.0.1 e máscara de sub-rede 255.255.255.0,
depois clique em OK para fechar a janela. O próximo passo consiste em identi�car o
dispositivo físico que deve sofrer a alteração de IP. Para tanto, na tela principal do
67
Figura 5.6: Device overview do CLP S7-300 ao �m de sua con�guração.
Figura 5.7: Con�guração do IP e Máscara de sub-rede do PC.
68
Figura 5.8: Tag table utilizadas no CLP S7-300.
TIA, clique emOnline & Diagnostics (localizado no painel esquerdo, abaixo de PLC1
[CPU 314C-2 PN/DP]), selecione Functions, depois Assign IP address e clique
em Accessible devices. Feito isso, selecione PN/IE no campo Type of the PG/PC
interface, selecione a placa de rede utilizada e, em seguida, o dispositivo que se quer
clonar o endereço MAC e clique em Apply. Ao voltar para a tela anterior, preencha
o campo IP address e Subnet mask com os endereços anteriormente mencionados e
clique em Assign IP Address. O mesmo procedimento para con�gurar o CLP S7-300,
utilizando o TIA versão 11, pode ser encontrado em [14].
Para con�gurar o IP do CLP S7-1200, siga os mesmos passos anteriores, devendo-
se alterar o caminho para adicionar um novo dispositivo para SIMATIC S7-1200 →CPU → CPU1214C AC/DC/Rly→ 6ES7 214-1BE30-0XB0, com versão de �rmware
V2.2. Foi escolhido o IP 192.168.0.9 para o S7-1200 neste trabalho.
5.5 Conversão de RPIC para Ladder e sua Imple-
mentação no CLP
A partir da RPIC apresentada na Figura 5.2, a conversão para Ladder se deu por
meio do método apresentado na Seção 4.1.4. Nesta seção são apresentadas apenas
partes do diagrama Ladder implementado, em razão de sua grande extensão.
O primeiro passa para implementação consiste em de�nir as tags que serão utili-
zadas. Para isso, foram criados duas tag table, uma contendo as variáveis de entrada
e saída do CLP e outra contendo as variáveis guardadas na memória interna do CLP,
que são utilizadas no desenvolvimento da lógica do programa, conforme mostrado
na Figura 5.8. Para criar uma tag table, deve-se clicar duas vezes em Add new tag
table.
Uma vez de�nidas as tags, foram criados 5 blocos Function, um para cada módulo
do método de conversão de RPIC para Ladder, conforme mostrado na Figura 5.9.
Para criar um desses blocos, basta clicar em Add new block, selecionar Function,
linguagem LAD, opção Automatic ou Manual (se quiser de�nir um número para
o bloco manualmente), de�nir um nome e clicar em OK. Vale ressaltar que há
diferença entre Function Block e Function: O primeiro é um bloco de código que
69
Figura 5.9: Function utilizadas para implementar a RPIC no CLP S7-300.
Figura 5.10: Parte do módulo de inicialização implementado no CLP S7-300.
pode guardar os valores de suas variáveis permanentemente em um instance data
block associado a ele, de forma que eles �quem disponíveis mesmo após o bloco ter
sido executado; o segundo, é um bloco de código ou sub-rotina que não conta com
memória dedicada, de forma que, após sua execução, ele não guarda as variáveis
utilizadas. Neste trabalho, utiliza-se apenas Function.
O módulo de inicialização implementado é mostrado na Figura 5.10. Ao ser
executado pela primeira vez, o bloco aciona a bobina p0 e a bobina inicia, fazendo
com que o contato inicia abra. Com isso, o módulo de inicialização não mais fará
modi�cações no programa nos próximos ciclos de varredura.
O módulo de eventos associa a leitura dos sensores a variáveis guardadas na
memória interna do CLP, visando simpli�car a programação do restante dos módu-
los. Parte do módulo é mostrada na Figura 5.11, na qual uma variável na memória
interna do CLP é acionada quando uma borda de subida no sensor capacitivo for
detectada.
Figura 5.11: Parte do módulo de eventos implementado no CLP S7-300.
70
Figura 5.12: Array contendo 3 elementos do tipo bool.
Os demais módulos foram desenvolvidos seguindo o método anteriormente men-
cionado, não sendo necessárias maiores explicações. Após programados, os módulos
devem ser adicionados ao bloco Main para que sejam executados. Vale ressaltar que
a ordem de execução dos módulos importa, ou seja, devem seguir a ordem em que
foram apresentados no método: inicialização, eventos, condições, dinâmica e ações,
respectivamente.
5.6 Implementação de G, em Ladder, e Gd, em SCL
Na literatura, existem diversos métodos para converter redes de Petri e autômatos
em alguma das cinco linguagens normatizadas para CLPs. Uma forma alternativa de
converter o autômato para Ladder é criar um data block, de�nir um vetor contendo os
estados do autômato e criar, utilizando Ladder, uma estrutura que analise o estado
atual e, de acordo com a ocorrência dos eventos, atualize o estado do autômato.
Para criar um data block, deve-se clicar em Add new block, Data block, tipo Global
DB, de�nir um nome e clicar em OK. Feito isso, dentro do data block deve-se criar
um array do tipo bool com número de elementos igual à cardinalidade do conjunto
de estados do autômato. A Figura 5.12, mostra o exemplo de um array do tipo bool
com 3 elementos.
Parte da estrutura implementada no Ladder responsável pela evolução dos esta-
dos do autômato é apresentada na Figura 5.13: quando o estado "MS".estadosG[0]
possui valor lógico 1 e ocorre o evento "start_up", o estado "MS".estadosG[1] passa
para valor lógico 1 e "MS".estadosG[0] para 0. Nesse caso, "MS" se refere ao data
block no qual o vetor estadosG está guardado. Para os demais estados do autômato
deve-se proceder da mesma forma. Vale ressaltar que o estado inicial do autômato
deve ser inicializado com valor lógico 1, e uma das maneiras de se fazer isso é adici-
onar uma bobina SET ao módulo de inicialização da rede de Petri, de modo que p0
e "MS".estadosG[0] recebam valor lógico alto durante o primeiro ciclo de varredura
do CLP.
Para implementar o autômato diagnosticador, utiliza-se o método apresentado
na Seção 4.1.5 para obter sua representação em SCL. Aproveitando o Código B.1
e adicionando o Código B.2 a ele, o código SCL gerado que representa o autômato
�ca guardado em um arquivo de texto, que pode ser prontamente copiado e colado
71
Figura 5.13: Parte do autômato representada em Ladder.
para uma Function criada com a opção de linguagem de�nida como SCL.
Parte do código em linguagem SCL gerada ao executar o Código B.2 é mos-
trada no Código 5.1. Nele, quando "MS".estadosGd[0] tem valor lógico igual a 1
e ocorre o evento "start_up" o estado "MS".estadosGd[0] recebe valor lógico 0 e
"MS".estadosGd[1] valor 1. É importante ressaltar que, para simpli�car a imple-
mentação no CLP, os rótulos dos estados são renomeados com números inteiros, de
forma que o índex i de cada elemento do vetor "MS".estadosGd represente o estado
i do autômato com estados renomeado.
A informação de que a falha ocorreu é feita atribuindo-se valor lógico 1 à variá-
vel "MS".FalhaDiagG. No Código B.2, por exemplo, se "MS".estadosGd[12] tem
valor lógico 1 e ocorre o evento sensor_bar_up, sabe-se que o estado seguinte
("MS".estadosGd[13]) é certo de que ocorreu a falha e, então, "MS".FalhaDiagG
recebe valor lógico 1.
Código 5.1 (Parte do código em SCL do diagnosticador Gd)
IF "MS".estadosGd[0] AND "start_up" THEN
"MS".estadosGd[0] := 0;
"MS".estadosGd[1] := 1;
END_IF;
IF "MS".estadosGd[12] AND "sensor_bar_up" THEN
"MS".estadosGd[12] := 0;
"MS".estadosGd[13] := 1;
"MS".FalhaDiagG := 1;
END_IF;
5.7 Medição dos Tempos Mínimos de Disparo das
Transições do Autômato
Para medir os tempos mínimos de disparo das transições do autômato, primeira-
mente as transições foram numeradas, conforme Figura 5.14, em seguida foi de-
�nido o vetor TempoMinTransicoes para guardar esses tempos e duas variáveis do
72
1 2 3 4 5 6
131415
789
12
16
start ↑ (0)
fdc (1) mag ↑ (2) mag ↓ (3) cap ↑ (4)
cap ↓ (11)
prf ↑ (5)
fdc(12)11
cor ↑ (6)
ind ↑ (7)bar ↑ (8)bar ↓ (9)
fdc (10)
10
bar ↑ (13)
bar ↓ (14)cap ↑ (15)cap ↓ (16)fdc (17)
ind ↑ (18)
σf, cor
17bar ↑ (19)
0
Figura 5.14: Autômato G com transições numeradas.
Figura 5.15: B loco TIME_TCK utilizado para marcar tempo no CLP S7-300.
tipo Time no data block MS , uma contendo o momento atual (TempoAtual) e outra
o momento em que ocorreu a transição anterior (TempoAnterior).
Com o intuito de marcar o tempo em que uma transição ocorre, foi utilizado o
bloco TIME_TCK, que retorna o tempo do sistema do CLP. O tempo do sistema
nada mais é que um contador de tempo que conta de 0 ms até um máximo de
2147483647 ms, com escala de tempo e acurácia de 1ms, e para de contar somente
se o CLP for posto em modo STOP. Esse bloco está disponível no S7-300 na seção
Instructions → Extended Instructions → Date and time-of-day → Clock funcitons.
A Figura 5.15 mostra o bloco TIME_TCK, o qual atribui o valor atual do tempo
do sistema à variável "MS".TempoAtual quando o sinal lógico em sua entrada EN
for igual a 1.
Por ser necessária a realização da operação de subtração entre duas variáveis do
tipo Time, foi criada uma Function chamada de SubtrairTime, em razão de não ter
sido encontrado um bloco capaz de fazer essa operação na biblioteca do S7-300. O
código implementado encontra-se no Código 5.2 e a interface usada para programar
(onde são de�nidas as variáveis de entrada, saída, etc.) é mostrada na Figura 5.16.
Como as variáveis TempoAtual, TempoAnterior e Transicao foram de�nidas como
Input na interface de programação do bloco, sua representação em Ladder apresen-
tará essas três entradas mais uma responsável por habilitar a execução do bloco,
chamada de EN, conforme mostrado na Figura 5.17.
Quando o sinal em EN tiver valor lógico igual a 1 o Código 5.2 é execu-
73
tado. Ao ser executado, os tempos guardados nas variáveis "MS".TempoAtual e
"MS".TempoAnterior são passados como os parâmetros TempoAtual e TempoAn-
terior, respectivamente, e o número da transição a ser analisada é passada como o
parâmetro Transicao.
Os valores passados para TempoAtual e TempoAnterior são subtraídos e o resul-
tado é guardado na variável temporária TempoDecorrido, que foi de�nida na inter-
face de programação. Se o tempo decorrido calculado for menor que o tempo mínimo
em "MS".TempoMinTransicoes[#Transicao], então ele é guardado. Por �m, o bloco
atribui o tempo atual guardado em #TempoAtual à variável "MS".TempoAnterior.
Para o correto funcionamento do algoritmo, o vetor "MS".TempoMinTransicoes
deve ser inicializado com todos os seus elementos contendo tempos muito maiores
que os tempos mínimos de disparo das transições. Isso pode ser feito acessando o
data block em que o vetor está armazenado e de�nir os valores iniciais de todos os
elementos na coluna Start value como T#10m, por exemplo.
Para esclarecer possíveis confusões, as variáveis que foram de�nidas na inter-
face do bloco são representada precedidas por #, como as variáveis #TempoAtual,
#TempoAnterior e #TempoDecorrido. A representação das tags de�nidas no CLP
é feita utilizando aspas, como, por exemplo, “p0”. As variáveis globais de�nidas
em determinado data block são representadas pelo nome do data block entre aspas
seguido por ponto (.) e o nome da variável, como, por exemplo, "MS".TempoAtual.
Código 5.2 (Código SCL da função SubtrairTime)
#TempoDecorrido := #TempoAtual - #TempoAnterior;
IF #TempoDecorrido < "MS".TempoMinTransicoes[#Transicao] THEN
"MS".TempoMinTransicoes[#Transicao] := #TempoDecorrido;
END_IF;
"MS".TempoAnterior := #TempoAtual;
Sabendo como o vetor contendo os tempos mínimos entre as transições é atuali-
zado, parte da lógica implementada no Ladder é apresentada na Figura 5.18. Quando
"MS".estadosG[2] possui valor lógico 1 e o evento "sensor_mag2_est" ocorre, o
bloco TIME_TCK guarda o tempo do sistema atual na variável "MS".TempoAtual
e, então, é executado a função SubtrairTime, passando como argumento os valores
do tempo atual "MS".TempoAtual, o tempo em que ocorreu a transição anterior em
"MS".TempoAnterior e o número da transição que está ocorrendo no momento (2 ),
de acordo com o autômato 5.14. O resultado �nal obtido é mostrado na Figura 5.19
e o autômato com os tempos mínimos em 5.20
74
Figura 5.16: Function SubtrairTime utilizada para subtrair duas variáveisdo tipo Time, guardar os tempos mínimos medidos e atualizar a variável"MS".TempoAnterior.
Figura 5.17: B loco Ladder que executa a Function SubtrairTime.
75
Figura 5.18: Lógica implementada no Ladder para medir os tempos mínimos entretransições.
Figura 5.19: Exemplo dos tempos mínimos medidos em um dos testes realizados naplanta.
76
1 2 3 4 5 6
131415
789
12
16
start ↑ \0
fdc\13999 mag ↑ \372 mag ↓ \131 cap ↑ \528
cap ↓ \4513,
prf ↑ 1684
fdc\599911
cor ↑ \2604
ind ↑ \1107bar ↑ \2368bar ↓ \888
fdc\1
10
bar ↑ \6099
bar ↓ \99cap ↑ \5517cap ↓ \2360fdc\6000
ind ↑ \3828
σf, cor
17bar ↑ \2348
0
Figura 5.20: Autômato G com os tempos mínimos, em milissegundos, entre astransições.
5.8 Cálculo dos Diagnosticadores Robustos a Atra-
sos
Com o autômato temporizado em mãos (Figura 5.20) e de�nida a topologia da estru-
tura em rede implementada (Figura 5.1), agora são de�nidos os eventos observáveis
transmitidos por cada canal e os tempos máximos de atraso a que eles estão sujeitos.
Neste trabalho, os seguintes conjuntos de eventos observáveis foram utilizados:
ΣMS1 = Σo11 = {start ↑, fdc,mag ↑,mag ↓, prf ↑} (5.1)
ΣMS2 = Σo12 = {cor ↑} (5.2)
ΣMS3 = Σo13 = {ind ↑, bar ↑, bar ↓} (5.3)
Para o canal ch11 foi especi�cado o atraso máximo de 150ms. Para o canal
ch13 foi especi�cado o atraso máximo de 150ms. Para o canal ch12 foram de�ni-
dos diferentes tempos máximos de atrasos: 3500ms, 8000ms e 12000ms. Para esses
tempos de atrasos serão obtidos os modelos não temporizados G1 e, a partir deles,
serão calculados os diagnosticadores Gd1 . Os autômatos G1 e Gd1 calculados para
T11 = T13 = 150ms e T12 = 3500ms serão denotados por G1S2e Gd1,S2
, respectiva-
mente. Os autômatos G1 e Gd1 calculados para T11 = T13 = 150ms e T12 = 8000ms
serão denotados por G1S3e Gd1,S3
, respectivamente. Os autômatos G1 e Gd1 cal-
culados para T11 = T13 = 150ms e T12 = 12000ms serão denotados por G1S4e
Gd1,S4, respectivamente. A Figura 5.21 apresenta a estrutura a ser implementada,
os conjuntos de eventos observáveis e os tempos de atrasos considerados.
77
MS1 MS3
Planta
LD1
ch11
Σo11
T11
ch12
Σo12
T12
ch13
Σo13
T13
T11 = 150ms
T13 = 150ms
ΣMS1 = Σo11 = {start ↑, fdc,mag ↑, mag ↓, prf ↑}ΣMS2 = Σo12 = {cor ↑}ΣMS3 = Σo13 = {ind ↑, bar ↑, bar ↓}
T12 = 7500ms
MS2
T11 = 150ms
T13 = 150ms
T12 = 12000ms
G1S2 e Gd1,S2
T11 = 150ms
T13 = 150ms
T12 = 3500ms
G1S3 e Gd1,S3 G1S4 e Gd1,S4
Figura 5.21: Estrutura em rede implementada.
O diagnosticador robusto a atrasos foi obtido com a ajuda de um módulo cha-
mado DELAY, que foi escrito em linguagem Python por Marcos Vinícius da Silva
Alves enquanto aluno de doutorado do Laboratório de Controle e Automação do
Centro de Tecnologia da UFRJ. O módulo implementa o Algoritmo 3.1 para a cons-
trução do autômato G1 a partir do autômato G, do tempo mínimo para a ocorrência
das transições e do tempo máximo de atraso de cada canal de comunicação, e o có-
digo fonte desse módulo é mostrado no Apêndice A.
O Código B.3 foi utilizado para obter o autômato G1S2, sendo este mostrado na
Figura 5.22 e, ao utilizar o código B.4, que é baseado no Algoritmo 3.2, veri�cou-se
que a linguagem gerada por G1S2é diagnosticável em rede. Em seguida, a função
genAutSCLDiagRobusto (mostrada no Código B.5) que é capaz de gerar o código
em SCL do diagnosticador robusto a atrasos baseado no Algoritmo 4.1, é utilizada.
Para G1S3, Gd1,S3
, G1S4e Gd1,S4
os mesmos passos foram seguidos.
Nos casos de G1S3e G1S4
, o tempo de atraso muito grande em ch12 faz com que
a linguagem gerada por eles torne-se não diagnosticável em rede, visto que existem
componentes fortemente conexos marcados no autômato GNETscc obtido ao executar
o Algoritmo 3.2 para cada um deles. Isso signi�ca, na prática, que a falha pode
ocorrer e o diagnosticador nunca diagnosticar. Os autômatos G1S3, Gd1,S3
, G1S4e
Gd1,S4não serão aqui mostrados em razão de serem muito extensos.
78
(x17 , {ind ↑})
(x12 , {0})
(x3 , {mag ↑})
(x2 , {0})
(x17 , {0})
(x13 , {bar ↓})
(x1 , {start ↑})
(x0 , {0})
(x2 , {fdc})
(x1 , {0})
(x12 , {bar ↑})
(x13 , {0})
(x8 , {ind ↑})
(x9 , {0})
(x4 , {mag ↑, 131,mag ↓}) (x3 , {0})
(x4 , {0})
(x4 , {mag ↓})
(x2 , {bar ↓, 1})
(x8 , {cor ↑, 1107})
(x7 , {0})(x8 , {cor ↑, 1107, ind ↑})
(x16 , {0})
(x13 , {bar ↑, 99, bar ↓})(x9 , {bar ↑})
(x14 , {0})
(x15 , {0})
(x6 , {prf ↑})
(x5 , {0})
(x2 , {bar ↓, 1, fdc})
(x10 , {bar ↓})
(x9 , {cor ↑, 3475})
(x7 , {cor ↑})
(x6 , {0})
(x11 , {0})
(x8 , {0})(x9 , {cor ↑, 3475, bar ↑})
(x10 , {0})
bar ↑
cap ↓
mag ↑
fdc
bar ↑s1
bar ↓
ind ↑s1
fdc
bar ↑
fdc
prf ↑
bar ↓s1
start ↑
bar ↑
mag ↓
mag ↑s1
cap ↑
bar ↓s1
prf ↑s1
ind ↑s1
ind ↑
mag ↓s1
bar ↓
ind ↑s1
mag ↑s1
cor ↑s1
cor ↑s1
fdc
ind ↑
bar ↓
σcor
bar ↑s1
mag ↓
cor ↑s1
bar ↑
fdcs1
cor ↑s1
start ↑s1
bar ↑s1
bar ↓s1
bar ↓s1
bar ↑s1
cor ↑s1
cor ↑
fdc
cap ↓
cap ↑
ind ↑
fdcs1
Figura 5.22: Autômato G1S2obtido com o DESLab.
79
{21Y, 20Y }
{3Y, 10Y, 9Y, 8Y, 36Y }
{3N, 15N, 16N, 17N}
{37Y, 5Y, 4Y }
{35Y, 18Y, 30N, 31N, 12Y }
{0N, 1N}
{3Y, 17Y, 16Y, 15Y }
{20N, 21N}
{3N, 28N}
{7Y, 6Y }
{19Y, 33Y, 29Y, 18Y, 11Y, 34Y, 12Y }
{4N, 5N, 37N}
{13N, 14N}
{26Y, 25Y, 24Y }
{3Y, 28Y }
{10N, 3N, 36N, 8N, 9N}
{13Y, 14Y, 32N}
{27Y }
{23Y, 22Y }
{6N, 7N}
{27N}
{14Y, 13Y }
{22N, 23N}
{35Y, 18Y, 31Y, 30Y, 12Y }
{2N, 3N}
{19N, 12N, 11N, 18N, 34Y, 29N, 33Y }
{26N, 24N, 25N}
{32Y, 14Y, 13Y }
mag ↑s1
ind ↑s1
mag ↓s1
bar ↑s1
ind ↑s1
bar ↓s1
fdcs1
bar ↑s1
bar ↓s1 fdcs1
fdcs1
prf ↑s1
fdcs1
mag ↑s1
fdcs1
mag ↓s1
start ↑s1
ind ↑s1
ind ↑s1
bar ↑s1
fdcs1
bar ↑s1
bar ↓s1
cor ↑s1
bar ↓s1
bar ↓s1
bar ↑s1
cor ↑s1
fdcs1
bar ↓s1
cor ↑s1
cor ↑s1
fdcs1
bar ↓s1
fdcs1
cor ↑s1
bar ↓s1
prf ↑s1
bar ↑s1
cor ↑s1
Figura 5.23: Autômato Gd1,S2obtido com o DESLab.
80
PC CSM 1277 S7-300 S7-1200
Figura 5.24: Topologia de rede em estrela implementada. O terminal (PC) e osCLPs S7-1200 e S7-300 se comunicam através do switch CSM-1277.
5.9 Conexão em Rede dos CLPs
Visando estabelecer um meio de comunicação entre os CLPs que permita a troca de
dados entre o diagnosticador local e a planta, optou-se por implementar um sistema
de comunicação que utiliza o protocolo PROFINET (Process Field Network) [15]
através da camada física ethernet utilizando cabos de par trançados. A topologia de
rede utilizada é a estrela utilizando o switch CSM 1277, como mostrado na Figura
5.24.
A con�guração da rede no software TIA pode ser feita de forma simples. Com
o IP dos CLPs já con�gurados, conforme explicado na Seção 5.4, e supondo que o
sistema implementado até aqui tenha sido feito no CLP S7-300, deve-se adicionar o
CLP S7-1200 ao projeto e con�gurar seu IP nas propriedades do dispositivo.
Feito isso, deve-se clicar em Devices & networks na barra lateral esquerda do
TIA, abrir a aba Topology view e, em seguida, abrir a aba Hardware Catalog na
barra lateral direita. Na lista de dispositivos apresentada, deve-se buscar o switch
de nome CSM 1277 modelo 6GK7 277-1AA00-0AA0 na pasta Network components
→ Compact switch modules unmanaged → CSM 1277 e adicioná-lo ao projeto.
Voltando à aba Topology view, deve-se clicar com o botão esquerdo do mouse sobre
a porta de rede dos CLPs e arrastá-la até qualquer uma das portas do switch.
Feito isso, a uma rede PROFINET será automaticamente con�gurada. Após esse
procedimento, a aba Topology view deverá ter um aspecto semelhante ao mostrado
na Figura 5.25.
Com a rede devidamente con�gurada, deve-se criar uma �la FIFO para guardar
a informação de quais eventos ocorreram e enviá-los de forma ordenada ao diagnosti-
cador local. Uma maneira de se fazer isso, utilizando blocos disponíveis na biblioteca
do S7-300, é criar uma estrutura denominada table, que se comporta como uma �la,
e utilizar o bloco ATT para adicionar informação a ela, e o bloco FIFO para retirar
a informação mais antiga dela.
Para criar uma table, basta criar um data block do tipo global DB, de�nir o
primeiro elemento dele como o tamanho máximo da �la, o segundo como o número
de entradas existentes nela e, do terceiro elemento em diante, de�nir as variáveis na
qual serão armazenados os dados da �la. Na Figura 5.26, por exemplo, foi criado o
81
Figura 5.25: Aba Topology view no software TIA após conexão dos CLPs.
Figura 5.26: De�nindo uma table no TIA.
data block chamado de �laCH11 que contém em seu primeiro item a variável len do
tipo Int com valor inicial igual a 10, em seu segundo item contém a variável index
do tipo Int com valor inicial igual a 0, e as demais variávies i, i_1, ..., i_9 são todas
do tipo Int com valor inicial igual a 0. A variável len de�ne o tamanho máximo da
�la, index de�ne a quantidade de elementos existentes nela e i, i_1, ... , i_9 são
as 10 posições em que são guardadas as entradas da �la.
Para �nalizar a con�guração da table, deve-se clicar com o botão direito em cima
do data block e acessar suas propriedades. Em Attributes deve-se desmarcar a opção
Optimized block access, com o intuito de deixar os endereços de memória do bloco
�xos.
Com a �la devidamente con�gurada, o bloco ATT é utilizado para adicionar
valores a ela. A Figura 5.27, por exemplo, mostra um bloco ATT que adiciona o
valor 11 (do tipo Int) à próxima entrada da table de�nida no endereço%DB8.DBW0,
quando o valor na entrada EN for igual a 1. Após adicionar o elemento à table, o
bloco se encarrega de incrementar o número de entrada existentes nela em uma
unidade.
82
Figura 5.27: Representação do bloco ATT no TIA.
Figura 5.28: Representação do bloco FIFO no TIA.
O tamanho da �la deve ser escolhido de forma adequada, em razão do bloco
ATT não adicionar elementos à �la se ela estiver cheia, ou seja, haverá perda de
informação se ela for mal dimensionada.
Para retirar o valor que está presente a mais tempo na �la, utiliza-se o bloco
FIFO. A Figura 5.28, por exemplo, mostra um bloco FIFO que pega o valor mais
antigo da table localizada no endereço %DB8.DBW0 e o atribui à variável do tipo
Word especi�cada em RET_VAL, quando for detectada uma borda de subida em
EN. Feito isso, o bloco se encarrega de decrementar o número de elementos existentes
na table em uma unidade. Se a table estiver vazia quando FIFO for executado, o
valor em RET_VAL não se alterará.
Os blocos ATT e FIFO para implementação no Ladder podem ser encontrados
na pasta Table functions localizada na aba Instructions → Extended instructions do
CLP S7-300.
Para comunicar os eventos ao diagnosticador local, foi utilizado o bloco PUT,
mostrado na Figura 5.29,que é capaz de escrever valores em variáveis armazena-
das em data blocks de dispositivos remotos. Os valores locais são passados nos
parâmetros SD_1, SD_2, SD_3 e SD_4, os quais são escritos no CLP remoto,
respectivamente, nas variáveis ADDR_1, ADDR_2, ADDR_3 e ADDR_4. Os da-
dos são enviados quando a entrada EN possui valor lógico igual a 1 e uma borda
de subida é detectada em REQ. O parâmetro ID é preenchido automaticamente ao
con�gurar os parâmetros de conexão do bloco, que é feito ao clicar com o botão
esquerdo do mouse sobre o bloco PUT, abrir a aba Properties localizada na barra
inferior do programa, acessar a aba Con�guration e selecionar Connection parame-
ter. Nesse momento deve-se escolher o parâmetro Partner como o CLP S7-1200,
como é mostrado na Figura 5.30.
83
Figura 5.29: Representação do bloco PUT no TIA.
Os endereços nos quais o bloco irá escrever devem ser de�nidos utilizando a
representação absoluta de ponteiros do tipo Any, que são utilizados para apon-
tar o início de uma área de dados e especi�car seu tamanho. O ponteiro Any é
formado pelo identi�cador P# seguido do data block, ponto (.), área de memó-
ria, endereço dos dados, tipo e o número de elementos da área de dados, ou seja,
P#DataBlock.MemoryArea DataAddress Type Number. Já para apontar endereços
das áreas que serão lidas no CLP local, pode ser usada a representação simbólica dos
endereços, ou seja, usar os nomes das variáveis, das tags, etc, como, por exemplo,
"MinhaTag", "MinhaDB".minhaVar.
Na Figura 5.29, por exemplo, o evento "int_EventoFIFOCH11" é lido no CLP
local e enviado para o data block de número 18 (DB18 ), na área de memória acessada
por um data bit (DBX ), no endereço 0.0, do tipo Int e, como não se trata de um
array, o número de elementos é igual a 1. Vale ressaltar que o data block aonde
os dados serão escritos não deve ter a opção Optimized block access habilitada, em
razão de ser necessário que os endereços de memória se mantenham �xos.
Por �m, uma maneira rápida de se fazer um sinal de "clock"no CLP é apresentada
na Figura 5.31, na qual um temporizador TON energiza a bobina "clock50ms" após
contar 50 ms e, em seguida, o contato dela abre e desenergiza o temporizador e a
bobina que está em série, fazendo com que o temporizador volte a contar do zero.
Esse "clock"pode ser utilizado para energizar a entrada REQ do bloco PUT a cada
50ms, como mostrado na Figura 5.29.
Com a table e o bloco PUT devidamente con�gurados, a estrutura utilizada no
84
Figura 5.30: Con�guração dos parâmetros de conexão do bloco PUT no TIA.
Figura 5.31: "Clock" de 50 ms feito com Temporizador TON.
Ladder para enviar os eventos ao diagnosticador foi feita da seguinte forma:
Primeiramente, foram atribuídos números inteiros para informar a ocorrência
dos eventos, de acordo com a Tabela 5.1, que também mostra através em qual canal
de comunicação eles são enviados.
Para cada canal ch11, ch12 e ch13, foram criadas tables de nome �laCH11, �-
laCH12 e �laCH13, respectivamente. No Ladder implementado para representar o
autômato G no S7-300, foram adicionados blocos ATT de forma a atualizar a �la
de cada canal com os eventos que ocorreram, no momento em que uma transição
ocorre.
Tabela 5.3: Relação entre os números inteiros e os eventos do autômato.Eventos Número Inteiro Canal de comunicação
start ↑ 11 ch11
fdc 6 ch11
mag ↑ 5 ch11
mag ↓ 8 ch11
cap ↑ - Não Transmitidocap ↓ - Não Transmitidoprf ↑ 1 ch11
cor ↑ 9 ch12
ind ↑ 10 ch13
bar ↑ 4 ch13
bar ↓ 7 ch13
85
Figura 5.32: Adição do bloco ATT ao Ladder do autômato G.
Figura 5.33: Bloco FIFO implementado no Ladder.
Parte do Ladder implementado é mostrado na Figura 5.32, na qual, quando
o autômato encontra-se no estado 3 e ocorre o evento mag ↓, correspondente no
Ladder a "sensor_mag2_rec", o autômato enviará à table "�laCH11" o número 8.
A atuação dos demais blocos e bobinas seguem o mesmo roteiro já exposto acima.
A parte responsável por retirar um evento da �la e guardá-lo em uma variável
cujo valor será enviado ao CLP parceiro, é mostrada na Figura 5.33, na qual, quando
o sinal de "clock" representado por "clock50ms" estiver em nível lógico alto, o bloco
FIFO é executado. Quando isso ocorre, o bloco retira o evento mais antigo da
"�laCH11" e o atribui à variável "word_EventoFIFOCH11", do tipo Word, que,
então, passa pelo bloco MOVE e é guardada na variável "int_EventoFIFOCH11",
do tipo Int. Esse procedimento é repetido para as �las "�laCH12" e "�laCH13",
todas ativadas pelo mesmo "clock" de 50 ms.
Agora, deve ser con�gurado um data block, no CLP S7-1200, para receber as
informações enviadas. Para tanto, foi criado o data block com nome ReceberE-
ventos e número 18 (DB18). Foi desmarcada a opção Optimized block access em
suas propriedades, e de�nidas as variáveis receberEventoCH11, receberEventoCH12
e receberEventoCH13 do tipo Int, para receber os eventos enviados pelos canais de
comunicação ch11, ch12 e ch13, respectivamente. Também foi de�nida a variável
receberFalha_S7_300, do tipo Bool, para receber a informação de que o diagnosti-
cador sem atrasos implementado no S7-300 diagnosticou a ocorrência da falha, com
86
Figura 5.34: Data block responsável por receber informações no diagnosticadorlocal.
o intuito de concentrar as informações a respeito de ocorrência de falhas em um só
CLP. O data block implementado é mostrado na Figura 5.34.
No CLP S7-300, o bloco PUT agora pode ser con�gurado da forma apresen-
tada na Figura 5.35. Ele é responsável por enviar os valores guardados nas variá-
veis "int_EventoFIFOCH11", "int_EventoFIFOCH12", "int_EventoFIFOCH13"
e "MS".FalhaDiagG aos endereços do CLP S7-1200 P#DB18.DBX0.0 INT 1,
P#DB18.DBX2.0 INT 1, P#DB18.DBX4.0 INT 1 e P#DB18.DBX6.0 BOOL 1,
respectivamente. Esses endereços do CLP S7-1200 correspondem, respectivamente,
às variáveis receberEventoCH11, receberEventoCH12, receberEventoCH13 e receber-
Falha_S7_300 do data block nomeado de receberEventos.
5.10 Implementação dos Diagnosticadores no CLP
S7-1200
Nesta etapa, é mostrada a forma como se deu a implementação dos diagnosticadores
robustos a atrasos e de um diagnosticador não robusto a atrasos no CLP S7-1200.
A informação de qual evento ocorreu chega ao data block através de um número
inteiro, o qual, após identi�cado, energiza uma bobina que recebe o nome do evento,
de acordo com a Tabela 5.3. A Figura 5.36, por exemplo, mostra que se for recebido o
número 11, através do canal ch11, a bobina "A_start_up" será energizada, uma vez
que o número 11 representa o evento start ↑, conforme Tabela 5.3. Para os demais
eventos que não são submetidos a atrasos simulados, é feito o mesmo procedimento.
Para simular um atraso na recepção do evento cor ↑, é utilizado o bloco TP
para energizar a bobina "SensorCorAuxiliar" quando o canal ch12 transmite o nú-
mero 9, conforme mostrado na Figura 5.37. Passado o tempo de�nido na variável
"Tempo de Atraso ch12", a bobina "SensorCorAuxiliar" é desenergizada, o contato
tipo N, mostrado na Figura 5.38, é energizado e, consequentemente, a bobina A_-
sensor_cor_up também é energizada. Caso não seja desejado o atraso simulado, foi
adicionada o contato da entrada %I0.1 do S7-1200, que, quando energizada, desa-
87
Figura 5.35: Bloco PUT responsável por enviar informações ao diagnosticadorlocal.
Figura 5.36: Identi�car evento de acordo com o número inteiro recebido.
88
Figura 5.37: Utilização do bloco TP para simular atraso no evento cor ↑ (parte 1de 2).
Figura 5.38: Utilização do bloco TP para simular atraso no evento cor ↑ (parte 1de 2).
bilita o bloco TP e permite a energização da bobina "A_sensor_cor_up" de forma
idêntica aos eventos sem atrasos.
De forma a simpli�car a escolha do tempo em que deve ser atrasado o evento cor,
foram adicionados dois blocos MOVE que alteram o valor da variável "Tempo de
Atraso ch12" de acordo com a posição das chave %I0.0 e %I0.1, conforme mostrado
na Figura 5.39. Quando %I0.0 for ativada e %I0.1 estiver desenergizada, o atraso
passa para 7500 ms, e se %I0.0 for desligada o atraso será de 3300 ms. Se a entrada
%I0.1 for ativada, o atraso simulado será nulo, independente da posição de %I0.0.
A implementação dos diagnosticadores no CLP S7-1200 se deu de forma idên-
tica ao diagnosticador implementado no S7-300, mostrada na Seção 5.6, utilizando,
porém, os códigos obtidos na Seção 5.8.
Para visualizar a situação de todos os diagnosticadores em relação à ocorrência
de falhas, foi criada uma Watch table, ao abrir a pasta Watch and force tables,
localizada na barra lateral esquerda, e clicar em Add new watch table. Feito isso,
foram adicionadas linhas com o nome dos eventos a serem visualizados, conforme
89
Figura 5.39: Utilização do bloco MOVE e entradas %I0.0 e %I0.1 para selecionaro tempo de atraso simulado.
Figura 5.40: Exemplo de watch table utilizada para visualizar a situação dos diag-nosticadores em relação à ocorrência do evento de falha.
Figura 5.40, por exemplo. A colunaMonitor value mostra o valor atual das variáveis
de�nidas em Name, quando o TIA está em modo Online e a opção Monitor All da
watch table é ativada.
5.11 Análise dos Resultados
A Tabela 5.4 resume os dados importantes a respeito dos autômatos não temporiza-
dos calculados para diferentes tempos de atrasos máximos nos canais de comunica-
ção. Nessa tabela, atraso máximo de projeto se refere ao atraso máximo nos canais
de comunicação para os quais eles foram calculados.
A Tabela 5.5 resume os diagnosticadores que serão submetidos aos testes e em
qual CLP foram implementados. A linha 1 da Tabela 5.5 trata do diagnosticador
Gd não robusto a atrasos que foi implementado no CLP S7-300 e que, portanto,
não está sujeito aos atrasos de comunicação. A linha 2 da Tabela 5.5 trata do
diagnosticador Gd não robusto a atrasos que foi implementado no CLP S7-1200 e
que, portanto, está sujeito aos atrasos de comunicação. A linha 3 da Tabela 5.5 trata
90
Tabela 5.4: Dados a respeito da diagnosticabilidade e atrasos máximos de projeto.Autômato Atraso Máximo de Projeto Linguagem Gerada e Diagnosticabilidade
G Não robusto a atrasos L(G), DiagnosticávelG1S2
T12 = 3500ms, T11 = T13 = 150ms L(G1S2), Diagnosticável em rede
G1S3T12 = 8000ms, T11 = T13 = 150ms L(G1S3
), Não Diagnosticável em redeG1S4
T12 = 12000ms, T11 = T13 = 150ms L(G1S4), Não Diagnosticável em rede
Tabela 5.5: Dados de projeto dos diagnosticadores que serão submetidos aos tes-tes. Vale ressaltar que Gd implementado no S7-300 não está sujeito a atrasos decomunicação. No S7-1200, todos os diagnosticadores estão sujeitos aos atrasos.
Diagnosticador CLP
1 Gd S7-3002 Gd S7-12003 Gd1,S2
S7-12004 Gd1,S3
S7-12005 Gd1,S4
S7-1200
do diagnosticador robusto a atrasos Gd1,S2que foi implementado no CLP S7-1200
e que, portanto, está sujeito aos atrasos de comunicação. Para os diagnosticadores
Gd1,S3e Gd1,S4
a interpretação é similar.
Com relação à diagnosticabilidade das linguagens geradas pelos autômatos G,
G1S2, G1S3
e G1S4, a Tabela 5.4 resume os resultados já obtidos nas seções anteriores.
Podemos observar, novamente, que os elevados tempos máximos de atrasos utilizados
nos cálculos dos autômatos G1S3e G1S4
faz com que as linguagens geradas por eles
seja não diagnosticável em rede.
A Tabela 5.6 resume os ensaios aos quais todos os diagnosticadores serão sub-
metidos. De acordo com essa tabela, durante o ensaio E3, por exemplo, todos os
diagnosticadores implementados no CLP S7-1200 receberão os eventos observados
no canal ch11 com atraso T11,E = 0ms, no canal ch12 com atraso de T12,E = 3300ms
e no canal ch13 com atraso T13,E = 0ms e, para este ensaio, o sensor de cor está
operando sem falhar. Para simular a falha no sensor de cor, foi colocado, no Ladder,
um contato em série com a bobina responsável por informar a ocorrência do evento
cor ↑, de forma que, quando se deseja que o sensor de cor opere com falha, esse
contato permanece desligado e, caso contrário, o contato permanece ligado.
Tabela 5.6: Dados a respeito dos ensaios que os diagnosticadores serão submetidos.Ensaio T11,E (ms) T12,E (ms) T13,E (ms) Sensor de cor
1 E1 0 0 0 Sem Falha2 E2 0 0 0 Com Falha3 E3 0 3300 0 Sem Falha4 E4 0 3300 0 Com Falha5 E5 0 7500 0 Sem Falha6 E6 0 7500 0 Com Falha7 E7 0 9000 0 Falha e volta da falha inde�nidas vezes
91
Figura 5.41: D iagnóstico de falhas para o caso sem atraso e sem falha no sensor decor.
Ensaio E1
A operação sem falha no sensor de cor e com atraso T11,E = T12,E = T13,E = 0 nos
canais ch11, ch12 (variável "Tempo de Atraso ch12" possui valor igual a 0 ms) e
ch13, respectivamente, retornou os resultados mostrados na Figura 5.41. Podemos
observar que o diagnosticador Gd implementado no CLP S7-300, o qual não sofre
com atrasos na comunicação em nenhum dos ensaios, diagnosticou corretamente
que a falha não ocorreu, uma vez que a variável "obs_diag1".FalhaDiagG_S7_300
possui valor igual a "FALSE".
O Diagnosticador Gd implementado no CLP S7-1200, e os diagnosticadores
robustos a atrasos Gd1,S2, Gd1,S3
e Gd1,S4também diagnosticaram corretamente
a não ocorrência da falha, uma vez que as variáveis "obs_diag1".FalhaDiagG,
"obs_diag1".FalhaROBUSTOS2, "obs_diag1".FalhaROBUSTOS3 e "obs_-
diag1".FalhaROBUSTOS4 possuem valores iguais a FALSE, respectivamente.
Ensaio E2
Para o caso em que a ocorre a falha no sensor de cor e os atrasos impostos são nulos
em todos os canais de comunicação, os resultados de todos os diagnosticadores a res-
peito da ocorrência da falha foram corretos. Vale ressaltar que as linguagens geradas
por G1S3e G1S4
são não diagnosticáveis em rede e, mesmo assim, os diagnosticadores
Gd1,S3e Gd1,S4
diagnosticam corretamente a ocorrência da falha.
Ensaio E3
No ensaio E3, o tempo de atraso imposto ao canal ch12 é de T12,E = 3300ms e
o sensor de cor opera sem falhar. Os resultados obtidos são mostrados na Figura
5.42. Podemos ver que o diagnosticador Gd implementado no S7-300 diagnosticou
corretamente a não ocorrência de falha, uma vez que ele não sofre com atrasos de
comunicação, como já mencionando anteriormente. Em contrapartida, o diagnos-
ticador Gd implementado no S7-1200 diagnosticou de forma incorreta a ocorrência
92
Figura 5.42: D iagnóstico de falhas para o caso com atraso de 3300 ms e sem falhano sensor de cor.
da falha, em razão do tempo de atraso na comunicação de eventos do canal ch12
ser grande o su�ciente para que ocorra trocas na ordem de observação dos even-
tos. Os diagnosticadores robustos a atrasos Gd1,S2, Gd1,S3
e Gd1,S4, diagnosticaram
corretamente a não ocorrência da falha. Vale lembrar que o tempo de atraso im-
posto ao canal ch12 (T12,E = 3300ms) é menor que os tempos máximos de atrasos
utilizados nos cálculos de Gd1,S2(T12 = 3500ms), Gd1,S3
(T12 = 8000ms) e Gd1,S4
(T12 = 12000ms) e, portanto, todos os diagnosticadores estavam operando dentro
das condições para os quais foram calculados.
Ensaio E4
No ensaio E4, o tempo de atraso imposto ao canal ch12 é de T12,E = 3300ms e o
sensor de cor opera com falha. Os resultados obtidos são mostrados, sequencial-
mente, nas Figuras 5.43, 5.44, 5.45 e 5.46. Podemos observar, primeiramente, que
os diagnosticadores não robustos a atrasos Gd implementados no S7-300 e S7-1200
diagnosticam a ocorrência da falha, como pode ser visto na Figura 5.43. Em seguida
o diagnosticador Gd1,S2diagnostica a falha (Figura 5.44 ), seguido do diagnostica-
dor Gd1,S3(Figura 5.45 ) e, por último, o diagnosticador Gd1,S4
diagnostica a falha
(Figura 5.46).
A variável, "obs_diag1.Tempo" serve como referência temporal para determinar
a sequência cronológica em que as imagens com os resultados foram capturadas
e, com isso, um efeito interessante dos diagnosticadores robustos a atrasos pode
ser notado com clareza: quanto maior o tempo de atraso T12 para o qual ele foi
calculado, maior é o tempo que ele demora para ter certeza de que a falha no sensor
de cor ocorreu.
Vale ressaltar que o tempo de atraso imposto ao canal ch12 (T12,E = 3300ms)
é menor que os tempos máximos de atrasos utilizados nos cálculos de Gd1,S2
(T12 = 3500ms), Gd1,S3(T12 = 8000ms) e Gd1,S4
(T12 = 12000ms) e, portanto,
todos esses diagnosticadores estavam operando dentro das condições para os quais
foram calculados.
93
Cabe lembrar que as linguagens geradas por G1S3e G1S4
são não diagnosticáveis
em rede e, mesmo assim, os diagnosticadores Gd1,S3e Gd1,S4
diagnosticam correta-
mente a ocorrência da falha.
Figura 5.43: D iagnóstico de falhas para o caso com atraso de 3300 ms e com falhano sensor de cor (parte 1).
Figura 5.44: D iagnóstico de falhas para o caso com atraso de 3300 ms e com falhano sensor de cor (parte 2).
Figura 5.45: D iagnóstico de falhas para o caso com atraso de 3300 ms e com falhano sensor de cor (parte 3).
Ensaio E5
No ensaio E5, o tempo de atraso imposto ao canal ch12 é de T12,E = 7500ms e o sen-
sor de cor opera sem falhar. Os resultados obtidos são mostrados, sequencialmente,
nas Figuras 5.47 e 5.48.
94
Figura 5.46: D iagnóstico de falhas para o caso com atraso de 3300 ms e com falhano sensor de cor (parte 4).
Primeiramente, podemos ver que o diagnosticador Gd implementado no S7-1200
diagnosticou de forma incorreta a ocorrência da falha (Figura 5.47), em razão do
tempo de atraso na comunicação de eventos do canal ch12 ser grande o su�ciente para
que ocorra trocas na ordem de observação dos eventos. Em seguida, o diagnosticador
robusto Gd1,S2também diagnostica de forma incorreta a ocorrência da falha (Figura
5.48), em razão do tempo de atraso T12,E = 7500ms imposto ao canal ch12 ser maior
que o tempo máximo de atraso para o qual Gd1,S2foi calculado (T12 = 3500ms).
Os demais diagnosticadores diagnosticaram corretamente a não ocorrência da
falha: Gd implementado no S7-300 não está sujeito aos atrasos, Gd1,S3e Gd1,S4
estão
sujeitos a atrasos T12,E = 7500ms que é menor que o atrasos máximos para os quais
foram calculados (T12 = 8000ms e T12 = 12000ms, respectivamente), ou seja, todos
eles operam dentro das condições para os quais foram projetados.
Figura 5.47: D iagnóstico de falhas para o caso com atraso de 7500 ms e sem falhano sensor de cor (parte 1).
Ensaio E6
No ensaio E6, o tempo de atraso imposto ao canal ch12 é de T12,E = 7500ms e o sen-
sor de cor opera com falha. Os resultados obtidos são mostrados, sequencialmente,
nas Figuras 5.49, 5.50, 5.51 e 5.52.
Podemos observar, primeiramente, que os diagnosticadores não robustos a atra-
sos Gd implementados no S7-300 e S7-1200 diagnosticam a ocorrência da falha, como
95
Figura 5.48: D iagnóstico de falhas para o caso com atraso de 7500 ms e sem falhano sensor de cor (parte 2).
pode ser visto na Figura 5.49.
Em seguida o diagnosticador Gd1,S2diagnostica a falha (Figura 5.50), seguido do
diagnosticador Gd1,S3(Figura 5.51) e, por último, o diagnosticador Gd1,S4
diagnostica
a falha (Figura 5.52).
A variável, "obs_diag1.Tempo" serve como referência temporal para determinar
a sequência cronológica em que as imagens com os resultados foram capturadas e,
com isso, o efeito causado pelos tempos de atraso T12 crescentes para os quais Gd1,S2,
Gd1,S3e Gd1,S4
foram calculados, resulta em maior demora para que ele tenha certeza
que a falha ocorreu e diagnosticá-la.
Vale ressaltar que o tempo de atraso imposto ao canal ch12 (T12,E = 7500ms)
é menor que os tempos máximos de atrasos utilizados nos cálculos de Gd1,S3
(T12 = 8000ms) e Gd1,S4(T12 = 12000ms) e, portanto, esses diagnosticadores es-
tavam operando dentro das condições para os quais foram calculados. Já para os
diagnosticador robusto Gd1,S3, o tempo de atraso imposto ao canal de comunicação é
maior que o tempo máximo de atrasos para o qual ele foi calculado (T12 = 3500ms)
e, mesmo assim, podemos observar que ele diagnostica corretamente a ocorrência da
falha.
Cabe lembrar que as linguagens geradas por G1S3e G1S4
são não diagnosticáveis
em rede e, mesmo assim, os diagnosticadores Gd1,S3e Gd1,S4
diagnosticam correta-
mente a ocorrência da falha.
Figura 5.49: D iagnóstico de falhas para o caso com atraso de 7500 ms e com falhano sensor de cor (parte 1).
96
Figura 5.50: D iagnóstico de falhas para o caso com atraso de 7500 ms e com falhano sensor de cor (parte 2).
Figura 5.51: D iagnóstico de falhas para o caso com atraso de 7500 ms e com falhano sensor de cor (parte 3).
Ensaio E7
No ensaio E7, o tempo de atraso imposto ao canal ch12 é de T12,E = 9000ms e o
sensor de cor pode falhar em alguns momentos e não falhar em outros. O resultado
obtido é mostrado na Figura 5.53.
Este ensaio ocorreu da seguinte forma: foram colocadas somente peças de metal
com a concavidade voltada para cima no armazém e, em seguida, o sistema foi
iniciado com o sensor de cor habilitado. Quando a primeira peça de metal chegou
ao �m da esteira, lá ela �cou parada até ser retirada. Após ter sido retirada, o sensor
de cor foi desabilitado e o sistema prosseguiu evoluindo normalmente. Quando a
próxima peça de metal chegou ao �m da esteira, a esteira parou e, logo em seguida,
começou a se mover em sentido contrário (esquerda), e, neste momento, o sensor de
cor foi novamente habilitado - vale ressaltar que a esteira se mover para a esquerda
signi�ca que a peça de metal, que deveria ter sido aceita, estava, na verdade, sendo
rejeitada. Logo após o processo de rejeição ter sido completado, o sensor de cor foi
novamente habilitado. Neste ponto, o sistema voltou à situação inicial, como se não
tivesse ocorrido nenhuma falha.
A explicação para este comportamento está no fato de que quando o sensor falha,
a peça chega ao �nal da esteira (direita) e, logo em seguida, é iniciado o processo de
descarte (esteira se move para a esquerda). Agora, com a peça movendo-se para a
esquerda, ela passa mais uma vez pelo sensor de cor, que neste momento encontra-se
97
Figura 5.52: D iagnóstico de falhas para o caso com atraso de 7500 ms e com falhano sensor de cor (parte 4).
habilitado (sem falha), e, com isso, o diagnosticador percebe a ocorrência do evento
cor ↑ e a interpreta como se tivesse recebido um evento atrasado.
Figura 5.53: Resultado do ensaio E7.
5.12 Considerações Finais
Nesta seção são apresentadas duas considerações a respeito da implementação deste
trabalho: a primeira, trata-se de uma forma mais e�ciente de usar a memória do
CLP para representar os autômatos; a segunda, mostra uma forma de visualizar a
sequência de estados percorridos na RPIC ou autômato.
Representação dos autômatos com apenas uma variável para guardar o
estado atual
Conforme mencionado em [4], o diagnosticador pode ser representado de uma forma
mais e�ciente que a forma na qual foi implementado neste trabalho, no quesito
memória utilizada. Em vez de representar os estado do autômato por vetores de
comprimento igual à cardinalidade do seu conjuntos de estados, bastaria guardar o
estado atual do autômato em uma variável do tipo Int, como feito, por exemplo, no
Exemplo 5.1.
98
Exemplo 5.1 Suponha que um autômato deixa o estado 1 e atinge o estado 2
quando ocorre o evento σ, e que o estado atual é guardado na variável do tipo Int
chamada de "MS".EstadoAtual. A representação em SCL desse autômato é:
IF "MS".EstadoAtual = 1 AND σ THEN
"MS".EstadoAtual := 2;
ENF_IF;
Visualização dos estados percorridos na RPIC ou autômato
Como forma de validar se a evolução de estados está ocorrendo conforme projetado,
uma forma de acompanhar os estados visitados é criar uma table de tamanho su�ci-
entemente grande para guardar essa informação e, se for preciso, utilizar um bloco
FIFO para atualizar a �la com uma frequência adequada. No Ladder, a implemen-
tação pode ser feita de forma semelhante à da Figura 5.32 para os autômatos. Na
Figura 5.54, por exemplo, foi criada uma �la para acompanhar os estados visitados
pelo autômato G (Figura 5.3), ao ser colocada na esteira da planta mecatrônica
uma peça de metal com a concavidade voltada para cima e, em seguida, uma peça
metálica com a concavidade para baixo. Como se pode observar, a sequência de
estados visitados é 0 − 1 − 2 − 3 − 4 − 5 − 6 − 7 − 8 − 9 − 10 − 2 e, em seguida,
3− 4− 5− 11− 2, conforme esperado.
Figura 5.54: Table utilizada para acompanhar a evolução dos estados do autômatoG mostrado na Figura 5.3.
99
Capítulo 6
Conclusões
Os principais objetivos deste trabalho são a implementação de um sistema de di-
agnose de falhas em sistemas a eventos discretos temporizados em rede sujeito a
atrasos na comunicação dos eventos e a análise do comportamento e efetividade dos
diagnosticadores frente a diferente tempos de atrasos na comunicação.
Após os diagnosticadores robustos [1], terem sido implementados, veri�cou-se,
na prática, a efetividade dos mesmos quando operam nas condições para as quais
foram projetados. Para efeito de comparação, também foram implementados diag-
nosticadores não robustos a atrasos [4], estando um deles sujeito a atrasos e o outro
não.
Quando o sensor de cor operava com falha, os diagnosticadores não robustos
eram os primeiros a diagnosticar a ocorrência da falha e, em seguida, os diagnos-
ticadores robustos diagnosticavam, demorando mais quanto maior fosse o tempo
máximo de atraso no canal ch12 para os quais foram calculados. Vale ressaltar que,
mesmo sendo as linguagens geradas por G1S3e G1S4
não diagnosticáveis em rede,
os diagnosticadores robustos Gd1,S3e Gd1,S4
em algum momento diagnosticaram a
ocorrência da falha nos ensaios E1 a E6.
Quando o sensor de cor operava sem falha, o diagnosticador não robusto e que
não estava sujeito a falha sempre diagnosticava corretamente a não ocorrência da
falha. Já o diagnosticador não robusto e sujeito a atrasos, diagnosticou a ocorrência
de falha de forma errada em todos os ensaios, em razão dos tempos de atrasos serem
su�cientes para que houvesse troca de observações entre os eventos cor ↑ e ind ↑.Em relação aos diagnosticadores robustos, se o atraso no canal de comunicação fosse
maior que o atraso máximo para o qual eles foram calculados, eles estavam sujeitos a
errar o diagnóstico a respeito da ocorrência da falha. Caso o atraso máximo no canal
de comunicação fosse menor que o atraso máximo para os quais foram calculados,
eles diagnosticavam corretamente a não ocorrência da falha.
A situação em que o sensor falha e volta a funcionar foi analisada no ensaio E7.
Nos diagnosticadores robustos não diagnosticáveis em rede Gd1,S3e Gd1,S4
, pudemos
100
observar que o atraso na observação do sensor de cor fez com que os diagnosticadores
percorressem um caminho tal que �cassem sempre em dúvida se a falha ocorreu ou
não.
Como trabalho futuro, pode-se desenvolver um método para cálculo do tempo
máximo de atraso nos canais de comunicações de forma a não permitir que os diag-
nosticadores robustos deixem de ser codiagnosticáveis em rede.
101
Referências Bibliográ�cas
[1] VIANA, G. S. Codiagnosability of Networked Discrete Event Systems with Ti-
ming Structure. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil,
2018.
[2] CASSANDRAS, C. G., LAFORTUNE, S. Introduction to Discrete Event Sys-
tems. 2 ed. New York, NY, USA, Springer, 2008.
[3] ZAYTOON, J., LAFORTUNE, S. �Overview of fault diagnosis methods for
Discrete Event Systems�, Annual Reviews in Control, v. 37, n. 2, pp. 308
� 320, 2013.
[4] SAMPATH, M., SENGUPTA, R., LAFORTUNE, S., et al. �Diagnosability of
discrete-event systems�, IEEE Transactions on Automatic Control, v. 40,
n. 9, pp. 1555�1575, Sep 1995.
[5] DEBOUK, R., LAFORTUNE, S., TENEKETZIS, D. �Coordinated decentralized
protocols for failure diagnosis of discrete event systems�. In: Systems,
Man, and Cybernetics, 1998. 1998 IEEE International Conference on,
v. 3, pp. 3010�3011 vol.3, Oct 1998.
[6] VIANA, G. S., ALVES, M. S., BASILIO, J. C. �Codiagnosability of timed
networked discrete-event systems subject to event communication delays
and intermittent loss of observation�. In: 2017 IEEE 56th Annual Confe-
rence on Decision and Control (CDC), pp. 4211�4216, Dec 2017.
[7] ALVES, M. V. S. Supervisory Control of Networked Discrete Event Systems
With Timing Structure. Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro,
RJ, Brasil, 2017.
[8] BLANCO, J. Implementação de um Sistema de Diagnose Descentralizada Ro-
busta a Atrasos nos Canais de Comunicação. Projeto de graduação, Uni-
versidade Federal do Rio de Janeiro, Rio de Janeiro, RJ, Brasil, 2017.
[9] NUNES, C. E. V., MOREIRA, M. V., ALVES, M. V. S., et al. �Network co-
diagnosability of Discrete-Event Systems subject to event communication
102
delays�. In: 2016 13th International Workshop on Discrete Event Systems
(WODES), pp. 217�223, May 2016.
[10] MOREIRA, M., BASILIO, J. �Bridging the Gap Between Design and Imple-
mentation of Discrete-Event Controllers�, v. 11, pp. 48�65, 01 2014.
[11] Structured Control Language (SCL) for S7-300/S7-400 Programming. Si-
emens. Acessado em 31 de maio de 2018. [Online]. Disponível em
https://cache.industry.siemens.com/dl/files/188/1137188/att_
27471/v1/SCLV4_e.pdf.
[12] BASILE, F., CHIACCHIO, P. �On the Implementation of Supervised Con-
trol of Discrete Event Systems�, IEEE Transactions on Control Systems
Technology, v. 15, n. 4, pp. 725�739, July 2007.
[13] COUTINHO, L. E. A. A. Um Tutorial para o Programa Cientí�co Computa-
cional DESLab. Projeto de graduação, Universidade Federal do Rio de
Janeiro, Rio de Janeiro, RJ, Brasil, 2014.
[14] LANCELLOTE JUNIOR, F. Automação De Uma Planta Mecatrônica Mo-
delada por uma Rede de Petri Interpretada Para Controle. Projeto de
graduação, Universidade Federal do Rio de Janeiro, Rio de Janeiro, RJ,
Brasil, 2014.
[15] OLIVEIRA, V. Protocolo de Comunicação PROFINET para Redes de Auto-
mação. Projeto de graduação, Universidade Federal do Rio de Janeiro,
Rio de Janeiro, RJ, Brasil, 2016.
103
1 # -*- coding: utf-8 -*-2 """3 Created on Mon Dec 05 04:30:55 20164 5 @author: Marcos V S Alves6 """7 8 from deslab import *9 #from Queue import *
10 from collections import deque11 12 ######################################################################################
#######################################13 14 """15 EXAMPLE16 17 s0, s1, s2, s2l, s3, s4, s5, s6, a, b, c, u, n = syms ('0 1 2 2^l 3 4 5 6 a b c u n')18 19 G_X = [ s0, s1, s2, s3, s4, s5, s6]20 G_E = [ a, b, c, u, n ]21 G_T = [( s0 , a, s1 ),( s1 , u, s2 ),( s2 , c, s3 ),( s0 , n, s4 ),( s4, a, s5 ),(
s5, b ,s2 ),( s4, c, s6 )]22 G_X0 = [ s0 ]23 G_Xm = [s3,s6]24 G_Econ = [ a, b, c, u, n ]25 G_Eobs = [ a, b, c ]26 G = fsa ( G_X , G_E , G_T , G_X0 , G_Xm , Sigcon = G_Econ , Sigobs = G_Eobs ,name
='$G$')27 28 Tmin = [( s0 , a, 0.25 ),( s1 , u, 0.5 ),( s2 , c, 0.2 ),( s0 , n, 0.75 ),( s4, a,
0.01 ),(s5, b, 0.5 ),( s4, c, 0.1)]29 OC = [(0.9,[a]) , (0.3,[b,c])]30 Eilo = [b]31 32 Gext = extendedauto(G,Tmin,OC,Eilo)33 34 draw(Gext)35 """36 ######################################################################################
########################################37 38 def create_newstate():39 # tihs function creates a new state40 countInstance = compCount()41 count = countInstance.counter42 return '_XD_'+str(count) # new state43 44 def create_Tmindict(Tmin):45 """46 Example47 Tmin = [( s0 , a, 0.25 ),( s1 , u, 0.5 ),( s2 , c, 0.2 ),( s0 , n, 0.75 ),( s4,
a, 0.01 ),(s5, b, 0.5 ),( s4, c, 0.1)]48 dd = create_Tmindict(Tmin)49 print dd['1']['u']50 print dd.items()51 """52 Tmindict = {}53 if not Tmin:54 return Tmindict55 for trans in Tmin:56 state = trans[0]57 event = trans[1]58 tmin = trans[2]59 if Tmindict.has_key(state):60 Tmindict[state].update( { event:tmin } )61 # nondeterministic automata - to check if this is correct62 #if Tmindict[state].has_key(event):63 # temp = Tmindict[state][event]64 # Tmindict[state][event] = tmin | temp65 #else:66 # Tmindict[state].update( { event:tmin } )
67 else:68 eventdict = {event:tmin}69 Tmindict.update({state:eventdict})70 return Tmindict71 72 def create_Tocdicts(OC):73 """74 Example:75 OC = [(0.9,[a]) , (0.3,[b,c])]76 dt1,dt2 = create_Tocdicts(OC)77 print dt1.items()78 print dt2.items()79 """80 maxDelay = {}81 eventSet = {}82 temp = frozenset([])83 if not OC:84 return maxDelay,eventSet85 for obschannel in OC:86 delay = obschannel[0]87 eset = frozenset(obschannel[1])88 if bool(eset & temp): #if we use List: any(i in eset for i in temp):89 print 'ERROR: Observation channel sets are NOT disjoint'90 return {},{}91 temp = temp | eset92 for event in eset:93 maxDelay[event] = delay94 eventSet[event] = eset95 return maxDelay,eventSet96 97 def extendedauto(auto,Tmin,OC,SigmaIlo=[],loi=0):98 99 # Step 0:
100 Sigma = auto.Sigma101 if loi<>0:102 Sigobs = set()103 for obschannel in OC:104 Sigobs = Sigobs | set(obschannel[1])105 else:106 Sigobs = auto.Sigobs107 Sigcon = auto.Sigcon108 Gtable = auto.symDict109 Tmindict = create_Tmindict(Tmin)110 maxDelay,Eoci = create_Tocdicts(OC)111 table = {}112 Xlist = {}113 transition = []114 Xme = frozenset([])115 116 def rename_event(event,p,c,loi):117 s = str(event)118 if loi<>0:119 if p in s:120 ind = s.index(p) + 1121 label = s[:ind] + '{' + s[ind:] + p + '{' + c + str(loi) + '}' + '}'122 else:123 label = s + p + '{' + c + str(loi) + '}'124 s = Gtable[event]125 if p in s:126 ind = s.index(p) + 1127 st = s[:ind] + '{' + s[ind:] + p + '{' + c + str(loi) + '}' + '}'128 else:129 st = s + p + '{' + c + str(loi) + '}'130 else:131 if p in s:132 ind = s.index(p) + 1133 label = s[:ind] + '{' + s[ind:] + p + c + '}'134 else:135 label = s + p + c136 s = Gtable[event]137 if p in s:138 ind = s.index(p) + 1
139 st = s[:ind] + '{' + s[ind:] + p + c + '}'140 else:141 st = s + p + c142 return label,st143 144 def latexname(p):145 """This function takes a tuple of the composite 146 automaton and generate a latex pretty name.147 p = x1,x2, where x1 in G.X and x2148 is a list whose elements belong to float \cap G.Sigobs149 """150 x1, x2 = p151 if x1 in auto.symDict:152 x1_name = auto.symDict[x1]153 else:154 x1_name = str(x1)155 156 name = '('+x1_name+',\{'157 for sx2 in x2:158 if sx2 in auto.symDict:159 sx2_name = auto.symDict[sx2]160 else:161 sx2_name = str(sx2)162 name = name + sx2_name + ','163 name = name[:-1] + '\})'164 return name165 166 def conc(q1,q2):167 if not(q1[-1] in Sigobs or q2[0] in Sigobs):168 return q1[:-1] + [(q1[-1]+q2[0])] + q2[1:]169 else:170 return q1 + q2171 172 def cut(q):173 flag = True174 index = 0175 for qi in q:176 if qi in Sigobs:177 return q[index:]178 index = index+1179 return [0]180 181 def add(q,x,e):182 if(e in Sigobs and e in auto.Gamma(x)):183 return cut( conc( q, [ Tmindict[x][e], e ] ) )184 elif (e in Sigma and e in auto.Gamma(x)):185 return cut( conc( q, [Tmindict[x][e]] ) )186 187 def rem(q,i):188 if i==0:189 return cut(q[1:])190 elif(i>0 and i<len(q)-1):191 return conc(q[:i],q[i+1:])192 elif i==len(q)-1:193 return q[:-1]194 195 # Step 1:196 X0e = create_newstate()197 Xlist.update( { X0e : (list(auto.X0)[0],[0]) } )198 table.update( { X0e : latexname(Xlist[X0e]) } )199 Xe = frozenset([])200 #print X0e; print Xlist[X0e]; print table[X0e]201 202 # Step 2:203 Eilol = frozenset([])204 Es = frozenset([])205 for event in Sigobs:206 if event in SigmaIlo:207 label,st = rename_event(event,'_','l',loi)208 Eilol = Eilol | {label}209 table.update({label: st})210 label,st = rename_event(event,'_','s',loi)
211 Es = Es | {label}212 table.update({label: st})213 Ee = Sigma | Es | Eilol214 for ev in Sigma:215 table.update( {ev: Gtable[ev]} )216 #print Eilol,Es,Ee217 218 # Step 3:219 F = deque()220 F.append(X0e)221 222 # Step 4:223 while F:224 225 # Step 4.1:226 state = F.popleft()227 xg,q = Xlist[state]228 #print xg,q229 230 # Step 4.2:231 Xe = Xe | frozenset([state])232 if xg in auto.Xm:233 Xme = Xme | frozenset([state])234 #print Xe235 236 # Steps 4.3 and 4.5:237 SigmaActive = auto.Gamma(xg)238 Il = range(0,len(q))239 for i in Il:240 if q[i] in Sigobs:241 tsmall = 0242 for j in range(i+1,len(q)):243 if not q[j] in Sigma:244 tsmall = tsmall + q[j]245 for event in SigmaActive:246 if tsmall + Tmindict[xg][event] >= maxDelay[q[i]]:247 SigmaActive = SigmaActive - set(event)248 for event in SigmaActive:249 newStateLabel = ( auto.delta(xg,event), add(q,xg,event) )250 isnewstate = True251 for temp in Xlist.keys():252 if Xlist[temp] == newStateLabel:253 newState = temp254 isnewstate = False255 break256 if isnewstate:257 newState = create_newstate()258 Xlist.update( { newState : newStateLabel } )259 table.update( { newState : latexname(newStateLabel) } )260 if not newState in F:261 F.append(newState)262 transition.append( [state,event,newState] )263 #print '----------'264 #print transition265 266 # Step 4.6:267 for eventset in Eoci.values():268 eventset = list(eventset)269 y = [i for i, j in enumerate(q) if j in eventset]270 if y<>[]:271 y = y[0]272 newStateLabel = ( xg , rem(q,y) )273 #print '---------------------'274 # print xg, q; print y; print newStateLabel275 isnewstate = True276 for temp in Xlist.keys():277 if Xlist[temp] == newStateLabel:278 newState = temp279 isnewstate = False280 break281 if isnewstate:282 newState = create_newstate()
283 Xlist.update( { newState : newStateLabel } )284 table.update( { newState : latexname(newStateLabel) } )285 if not newState in F:286 F.append(newState)287 label, st = rename_event(q[y],'_','s',loi)288 transition.append( [state,label,newState] )289 if q[y] in SigmaIlo:290 label, st = rename_event(q[y],'_','l',loi)291 transition.append( [state,label,newState] )292 293 # Step 5 and the construction of fsa object by using DESlab294 name = 'E(' + auto.name + ')'295 Gext = fsa ( Xe, Ee, transition, X0e, Xme, table = table, Sigobs = Es,
Sigcon=Sigcon ,name = name)296 #Gext.setgraphic('verifier')297 Gext.setgraphic('observer')298 return Gext299 300 301 ###### DECENTRALIZED DIAGNOSIS
###########################################################################302 303 def codiagVerifier_i(auto,faultevent,loi=0):304 305 def autoAlabel(auto,faultevent):306 N = create_newstate()307 F = create_newstate()308 table = auto.symDict309 table.update( {F : 'F' } )310 table.update( {N : 'N' } )311 Al = fsa([N,F], [faultevent], [(N,faultevent,F),(F,faultevent,F)], [N],
[F],table=table,Sigobs=[],name='$A_l$')312 return Al313 314 315 def rename_event(event,p,c,loi):316 s = str(event)317 if loi<>0:318 if p in s:319 ind = s.index(p) + 1320 label = s[:ind] + '{' + s[ind:] + p + '{' + c + str(loi) + '}' + '}'321 else:322 label = s + p + '{' + c + str(loi) + '}'323 s = Gtable[event]324 if p in s:325 ind = s.index(p) + 1326 st = s[:ind] + '{' + s[ind:] + p + '{' + c + str(loi) + '}' + '}'327 else:328 st = s + p + '{' + c + str(loi) + '}'329 else:330 if p in s:331 ind = s.index(p) + 1332 label = s[:ind] + '{' + s[ind:] + p + c + '}'333 else:334 label = s + p + c335 s = Gtable[event]336 if p in s:337 ind = s.index(p) + 1338 st = s[:ind] + '{' + s[ind:] + p + c + '}'339 else:340 st = s + p + c341 return label,st342 343 Gtable = auto.symDict344 #auto = auto.renamestates('number')345 346 Gm = auto.copy()347 Gm = Gm.setpar(Xm=Gm.X)348 Gm = auto.setpar(Xm=auto.X)349 Gn_temp = Gm.deletevent(faultevent)350 Gn = ac(Gn_temp)351 Gn = Gn.setpar(name= auto.name[:-1] +'(normal)$')
352 353 A = autoAlabel(auto,faultevent)354 Gf_temp = Gm // A355 Gf = coac(Gf_temp)356 Gf = Gf.setpar(name= auto.name[:-1] +'(fault)$')357 358 Sigma_uo = Gn.Sigma - auto.Sigobs359 R = []360 for event in Sigma_uo:361 label,st = rename_event(event,'_',r'\\rho',loi)362 R.append((event,label))363 Gnp = Gn.renamevents(R)364 365 V = Gnp // Gf366 V = V.setpar(name= '$V_' + str(loi) +'$' )367 368 if V <>fsa():369 SCC_selfloop = [[l] for l in selfloopnodes(V)]370 SCC_multiple = [C for C in strconncomps(V) if (len(C)>1)]371 SCC_nontrivial = SCC_selfloop + SCC_multiple372 # finding a counter example373 Xmnew = []374 for C in SCC_nontrivial:375 for x_V in (set(C) & V.Xm):376 if (V.Gamma(x_V) & auto.Sigma) <> set([]):377 Xmnew = Xmnew + list(C)378 V = V.setpar(Xm=Xmnew)379 V = trim(V)380 #print V381 #draw(auto,V)382 383 return V384 385 def is_netCoDiag(G,Tmin,OC,faultevent,SigmaIlo=[]):386 387 loi = len(OC)388 389 if loi==1:390 G1 = extendedauto(G,Tmin,OC[0],SigmaIlo[0],0)391 G1 = G1.setpar(name = '$G_1$')392 V = codiagVerifier_i(G1,faultevent,0)393 V.setgraphic('verifier')394 else:395 G1 = extendedauto(G,Tmin,OC[0],SigmaIlo[0],1)396 G1 = G1.setpar(name = '$G_1$')397 V = codiagVerifier_i(G1,faultevent,1)398 V.setgraphic('verifier')399 #print 1400 for i in range(2,loi+1):401 Gi = extendedauto(G,Tmin,OC[i-1],SigmaIlo[i-1],i)402 Gi = Gi.setpar(name = '$G_' + str(i) + '$')403 Vi = codiagVerifier_i(Gi,faultevent,i)404 Vi.setgraphic('verifier')405 #print i 406 V = V // Vi407 netcodiagnosable = True408 if V <>fsa():409 SCC_selfloop = [[l] for l in selfloopnodes(V)]410 SCC_multiple = [C for C in strconncomps(V) if (len(C)>1)]411 SCC_nontrivial = SCC_selfloop + SCC_multiple412 # finding a counter example413 Xmnew = []414 for C in SCC_nontrivial:415 if set(C) - V.Xm == set([]):416 for x_V in (set(C)):417 if (V.Gamma(x_V) & G.Sigma) <> set([]):418 netcodiagnosable = False419 Xmnew = Xmnew + list(C)420 #break421 V = V.setpar(Xm=Xmnew)422 V = V.setpar(name='V')423 #print V
424 V.setgraphic('verifier')425 426 return netcodiagnosable,V427 428 429 #DIAGNOSTICADOR PARA CODIAGNOSTICABILIDADE EM REDE 430 431 432 433 434 def marc_y_gl(Gl):435 Gly = Gl.copy()436 marc=frozenset([])437 for x in Gly.X:438 if 'Y' == x[1]:439 xmnew= x440 marc=marc|frozenset([xmnew])441 Gly.Xm = marc442 return Gly443 444 def marc_n_gd(Gd):445 Gdy = Gd.copy()446 marc=frozenset([])447 for x in Gdy.X:448 449 for el in x:450 if 'N' == el[1]:451 marc=marc|frozenset([x])452 Gdy.Xm = marc453 return Gdy454 455 def isdiagnosabletest(G1,f):456 G1 = G1.renamestates('number')457 Al = labelfailaut(f)458 Gl1 = G1 // Al459 Gl1m = marc_y_gl(Gl1)460 Gd1 = diagnoser(G1,f,G1.Sigobs)461 Gd1m= marc_n_gd(Gd1)462 Gt1 = Gd1//Gl1463 Gt1m = Gd1m//Gl1m464 Gl1.setgraphic(style='observer',direction = 'UD')465 Gd1.setgraphic(style='observer',direction = 'UD')466 Gt1.setgraphic(style='observer',direction = 'UD')467 Gt1m.setgraphic(style='observer',direction = 'UD')468 469 SCC = strconncomps(Gt1m.Graph)470 C_1 = selfloopnodes(Gt1m.Graph)471 SCC_NT = [C for C in SCC if (len(C)>1) | (C in C_1)]472 diagnosable = True473 estadosSCC_NT = frozenset([])474 for x in SCC_NT:475 for estado in x:476 estadosSCC_NT=estadosSCC_NT|frozenset([estado])477 if (estadosSCC_NT & Gt1m.Xm) <> frozenset([]):478 diagnosable = False479 print 'DIAGNOSTICABILIDADE= '480 print diagnosable481 Gt1mfinal = Gt1m.setpar(Xm = estadosSCC_NT & Gt1m.Xm)482 Gsf=observer(Gt1mfinal,G.Sigma)483 Gsf1 = trim(Gsf)484 Gsf1 = Gsf1.renamestates('number')485 Gsf1.setgraphic(style='observer',direction = 'UD')486 return Gt1mfinal, Gsf1487
Código B.1 (Checar a diagnosticabilidade de Gd.)
#Importar o DESLab
from DESLAB import *
#Definir vars simbólicas
syms('x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17')
syms('sensor_prof_up sensor_cap_up sensor_cap_down sensor_bar_up ')
syms('sensor_mag2_est fdc_mag2 sensor_bar_down sensor_mag2_rec')
syms('sensor_cor_up sensor_ind_up start_up sigma_cor')
#Definir conjunto de estados
X=[x0,x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17];
#Definir conjunto de eventos
E=[sensor_prof_up,sensor_cap_up, sensor_cap_down, sensor_bar_up,\
sensor_mag2_est, fdc_mag2, sensor_bar_down, sensor_mag2_rec,\
sensor_cor_up, sensor_ind_up, start_up, sigma_cor];
#Definir transicões do autômato
T=[(x0,start_up,x1), (x1,fdc_mag2,x2), (x2,sensor_mag2_est,x3),\
(x3,sensor_mag2_rec,x4), (x4,sensor_cap_up,x5), (x5,sensor_cap_down,x11),\
(x11,fdc_mag2,x2),\
(x5, sensor_prof_up, x6), (x6, sensor_cor_up,x7), (x7,sensor_ind_up,x8),\
(x8, sensor_bar_up, x9), (x9, sensor_bar_down, x10), (x10,fdc_mag2,x2),\
(x6, sigma_cor, x16), (x16, sensor_ind_up, x17), (x17,sensor_bar_up,x12),\
(x12, sensor_bar_down, x13),(x13,sensor_cap_up,x14),\
(x14,sensor_cap_down,x15), (x15,fdc_mag2,x2), (x6, sensor_bar_up, x12)];
#Definir conjunto de eventos observáveis
Eobs=[sensor_prof_up, sensor_bar_up,sensor_mag2_est, fdc_mag2,\
sensor_bar_down, sensor_mag2_rec,sensor_cor_up, sensor_ind_up,\
start_up];
#Definir estado inicial
X0=[x0];
#Definir estados marcados
Xm=[];
#Definir rótulos que irão aparecer nos desenhos
table = [(x0,'x_0'),(x1,'x_1'),(x2,'x_2'),(x3,'x_3'),(x4,'x_4'),\
(x5,'x_5'),(x6,'x_{6}'),(x7,'x_7'),(x8,'x_8'),(x9,'x_{9}'),\
(x10,'x_{10}'),(x11,'x_{11}'),(x12,'x_{12}'),(x13,'x_{13}'),\
(x14,'x_{14}'),(x15,'x_{15}'),(x16,'x_{16}'),(x17,'x_{17}'),\
(start_up,r'start\\uparrow'), (sensor_prof_up, r'prf\\uparrow'),\
(sensor_cap_up, r'cap\\uparrow'), (sensor_cap_down, r'cap\\downarrow'),\
113
(sensor_bar_up, r'bar\\uparrow'),(sensor_mag2_est, r'mag\\uparrow'),\
(fdc_mag2, r'fdc'), (sensor_bar_down, r'bar\\downarrow'),\
(sensor_mag2_rec, r'mag\\downarrow'),(sensor_cor_up, r'cor\\uparrow'),\
(sensor_ind_up, r'ind\\uparrow'), (sigma_cor, r'\\sigma_{cor}')];
#Definir o Autômato G
G = fsa(X, E, T, X0, Xm, Sigobs=Eobs, table=table, name ='$G$');
#Calcular o diagnosticador G_d a partir de G
Gd= diagnoser(G,sigma_cor,Eobs)
#Verificar se G_d é diagnosticável
Diag1, GV1 = is_diagnosable_verif(G, sigma_cor, G.Sigobs)
#Imprimir a resposta a respeito da diagnosticabilidade de G_d
print "Automato G Diagnosticavel Sem Atraso? ", Diag1
#Desenhar o Autômato G_d
draw(Gd,'figure')
114
Código B.2 (Gerar representação em SCL do diagnosticador)
def genAutSCLDiag(Gd, DB_name=""):
"""
Gera o automato Gd em linguagem SCL.
"""
def marc_y_gd(Gd):
"""
Marca os estados certos de que ocorreram a falha no automato Gd.
"""
Gdy = Gd.copy()
marc=frozenset([])
for x in Gdy.X:
for el in x:
if 'Y' == el[1]:
marc=marc|frozenset([x])
break
Gdy.Xm = marc
return Gdy
Gdm=marc_y_gd(Gd)
Gdm=Gdm.renamestates('number')
code=""
for i in Gdm.transitions_iter():
if i[2] in Gdm.Xm:
code+="""
IF "{DB}".estadosGd[{x0}] AND "{evento}" THEN
"{DB}".estadosGd[{x0}] := 0;
"{DB}".estadosGd[{x1}] := 1;
"{DB}".FalhaDiagG := 1;
END_IF;
""".format(DB=DB_name, x0=i[0], x1=i[2], evento=i[1])
else:
code+="""
IF "{DB}".estadosGd[{x0}] AND "{evento}" THEN
"{DB}".estadosGd[{x0}] := 0;
"{DB}".estadosGd[{x1}] := 1;
END_IF;
""".format(DB=DB_name, x0=i[0], x1=i[2], evento=i[1])
with open('SCLDiagCASSANDRAS_S7_300.txt','w') as arq:
arq.write(code)
return
genAutSCLDiag(Gd, DB_name="MS")
115
Código B.3 (Código em Python para obtenção de G1 no caso (S2))
from DELAY import *
#Definir Variaveis Simbolicas
syms('x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 x10 x11 x12 x13 x14 x15 x16 x17')
syms('a b c d e f g h i j k l')
syms('sensor_prof_up sensor_cap_up sensor_cap_down sensor_bar_up ')
syms('sensor_mag2_est fdc_mag2_up sensor_bar_down sensor_mag2_rec')
syms('sensor_cor_up sensor_ind_up start_up sigma_cor')
X=[x0,x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17];
# Conjunto de Eventos, Conjunto de Observáveis, Estado Inicial e Marcados
E=[a, b, c, d, e, f, g, h, i, j, k, l]
Eobs=E[:-1]
X0=[x0]
Xm=[]
#Nomes a serem desenhados no diagrama de transicao de estados
Table = [(x0,'x_0'),(x1,'x_1'),(x2,'x_2'),(x3,'x_3'),(x4,'x_4'),(x5,'x_5'),\
(x6,'x_{6}'),(x7,'x_7'),(x8,'x_8'),(x9,'x_{9}'),(x10,'x_{10}'),\
(x11,'x_{11}'),(x12,'x_{12}'),(x13,'x_{13}'),(x14,'x_{14}'),\
(x15,'x_{15}'),(x16,'x_{16}'),(x17,'x_{17}'),\
(a,r'start\\uparrow'), (b, r'prf\\uparrow'),\
(c, r'cap\\uparrow'), (d, r'cap\\downarrow'),\
(e, r'bar\\uparrow'),(f, r'mag\\uparrow'),\
(g, r'fdc'), (h, r'bar\\downarrow'),\
(i, r'mag\\downarrow'),(j, r'cor\\uparrow'),\
(k, r'ind\\uparrow'), (l, r'\\sigma_{cor}')];
#Transicoes do automato
T=[(x0,a,x1), (x1,g,x2), (x2,f,x3), (x3, i, x4), (x4,c,x5), (x5,d,x11),\
(x11,g,x2), (x5, b, x6),\
(x6, j, x7), (x7, k, x8), (x8, e, x9), (x9, h, x10), (x10, g, x2),\
(x6, e, x12), (x12, h, x13), (x13, c, x14), (x14, d, x15), (x15, g, x2),\
(x6, l, x16), (x16, k, x17), (x17, e, x12)]
#Definicao do automato G
G=fsa(X, E, T, X0, Xm, table=Table, Sigobs=Eobs, name='$G$')
#Tempo minimo para ocorrencia das transicoes
Tmin=[(x0,a,0.1), (x1,g,13999), (x2,f,372), (x3,i,131),(x4,c,528),\
(x5,d,4513),(x11,g,5999),\
(x5, b, 1684 ),(x6, j, 2604), (x7, k, 1107), (x8, e, 2368), (x9, h, 888),\
(x10, g, 1), (x6, e, 6099), (x12, h, 99), (x13, c, 5517), (x14, d, 2360),\
(x15, g, 6000), (x6, l, 2604), (x16, k, 3828), (x17, e, 2348)]
#Atrasos nos canais de comunicacao e eventos sendo transmitidos por eles.
116
OC11=[(150,[a,f,i,b,g])]
OC12=[(3500,[j])]
OC13=[(150, [k,e,h])]
OC14=[(10,[c,d])]#Supor que sensor capacitivo perdeu a comunicacao
#Definicao do automato G1
G1=extendedauto(G, Tmin, OC11+OC12+OC13, [], 1)
117
Código B.4 (Veri�car codiagnosticabilidade de G1)
## Verificar Codiagnosticabilidade
Al = labelfailaut(l) #Automato rotulador com falha em l (cor)
G1 = G1.setpar(name = '$G_1$');
G1 = G1.renamestates('number');
Gl1 = G1 // Al
Gl1m = marc_y_gl(Gl1) #Marca estados com Y em Gl1
Gd1 = diagnoser(G1,l,G1.Sigobs) # Diagnosticador Gd1
Gd1m= marc_n_gd(Gd1) #Marca estados com N em Gd1
Gt1 = Gd1//Gl1 #Automato Gteste
Gt1m = Gd1m//Gl1m #Automato Gteste com estados NY marcados
SCC = strconncomps(Gt1m.Graph) # Componentes fortemente conexos de Gt1m
C_1 = selfloopnodes(Gt1m.Graph)
SCC_NT = [C for C in SCC if (len(C)>1) | (C in C_1)]
diagnosable1 = True
estadosSCC_NT = frozenset([])
for x in SCC_NT:
for estado in x:
estadosSCC_NT=estadosSCC_NT|frozenset([estado])
if (estadosSCC_NT & Gt1m.Xm) <> frozenset([]):
diagnosable1 = False
##Resultado: Codiagnosticavel em rede ou nao?
print 'DIAGNOSTICABILIDADE EM REDE 1 ? ', diagnosable1
118
Código B.5 (Gerar código em SCL de G1)
### Arrumar Gd1m para obter seu codigo em SCL...
Gd1m= Gd1m.renamestates('number')
# Relacao entre a,b,c,... e eventos da planta start_up, etc..
a = start_up; b = sensor_prof_up; c = sensor_cap_up; d = sensor_cap_down;
e = sensor_bar_up; f = sensor_mag2_est; g = fdc_mag2_up; h = sensor_bar_down;
i = sensor_mag2_rec; j = sensor_cor_up; k = sensor_ind_up; l = sigma_cor;
#
newE=[a,b,e,f,g,h,i,j,k,l]
newEobs=newE[:-1]
newT=[]
newTable = [(start_up,r'start\\uparrow'), (sensor_prof_up, r'prf\\uparrow'),\
(sensor_cap_up, r'cap\\uparrow'), (sensor_cap_down, r'cap\\downarrow'),\
(sensor_bar_up, r'bar\\uparrow'),(sensor_mag2_est, r'mag\\uparrow'),\
(fdc_mag2_up, r'fdc'), (sensor_bar_down, r'bar\\downarrow'),\
(sensor_mag2_rec, r'mag\\downarrow'),(sensor_cor_up, r'cor\\uparrow'),\
(sensor_ind_up, r'ind\\uparrow'), (sigma_cor, r'\\sigma_{cor}')];
for t in Gd1m.transitions_iter():
if t[1][0]=='a': newT+=[(t[0],a,t[2])]
if t[1][0]=='b': newT+=[(t[0],b,t[2])]
if t[1][0]=='c': newT+=[(t[0],c,t[2])]
if t[1][0]=='d': newT+=[(t[0],d,t[2])]
if t[1][0]=='e': newT+=[(t[0],e,t[2])]
if t[1][0]=='f': newT+=[(t[0],f,t[2])]
if t[1][0]=='g': newT+=[(t[0],g,t[2])]
if t[1][0]=='h': newT+=[(t[0],h,t[2])]
if t[1][0]=='i': newT+=[(t[0],i,t[2])]
if t[1][0]=='j': newT+=[(t[0],j,t[2])]
if t[1][0]=='k': newT+=[(t[0],k,t[2])]
if t[1][0]=='l': newT+=[(t[0],l,t[2])]
newXm=[i for i in Gd1m.X if i not in Gd1m.Xm]
Gd1m=fsa(Gd1m.X, newE, newT,Gd1m.X0, newXm, table=newTable, Sigobs=newEobs)
print len(Gd1m.X), 'S2'
def genAutSCLDiagRobusto(Gdm, DB_name=""):
"""
Transforma o Gdi, com estados de falha ja marcados e estados renomeados,
em codigo SCL para implementar no CLP.
"""
code=""
for i in Gdm.transitions_iter():
if i[2] in Gdm.Xm:
119
code+="""
IF "{DB}".estadosDiag{sit}[{x0}] AND "A_{evento}" THEN
"{DB}".estadosDiag{sit}[{x0}] := 0;
"{DB}".estadosDiag{sit}[{x1}] := 1;
"{DB}".FalhaROBUSTOS2 := 1;
END_IF;
""".format(DB=DB_name, x0=i[0], x1=i[2], evento=i[1], sit="S2")
else:
code+="""
IF "{DB}".estadosDiag{sit}[{x0}] AND "A_{evento}" THEN
"{DB}".estadosDiag{sit}[{x0}] := 0;
"{DB}".estadosDiag{sit}[{x1}] := 1;
END_IF;
""".format(DB=DB_name, x0=i[0], x1=i[2], evento=i[1], sit="S2")
with open('SCLdiagROBUSTO_situacao%s.txt'%("S2"),'w') as arq:
arq.write(code)
return
genAutSCLDiagRobusto(Gdm=Gd1m, DB_name="obs_diag1")
120
Top Related