Implementação de um Diagnosticador de Falha a Eventos ... · Projeto de Graduação apresentado...

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






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


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.






Setembro/2018

Orientadores: João Carlos dos Santos Basilio


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


September/2018

Advisors: João Carlos dos Santos Basilio


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.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.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.


{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.


{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


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)


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;


END_IF;

IF "MS".estadosGd[12] AND "sensor_bar_up" THEN



"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).



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


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.


96



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


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

https://cache.industry.siemens.com/dl/files/188/1137188/att_27471/v1/SCLV4_e.pdf

https://cache.industry.siemens.com/dl/files/188/1137188/att_27471/v1/SCLV4_e.pdf

Apêndice A

Pacote DELAY escrito em Python

104

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

Apêndice B

Códigos em Python Utilizados na

Implementação

112

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}".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



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}".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



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

Implementação de um Diagnosticador de Falha a Eventos ... · Projeto de Graduação apresentado...

Documents

Transcript of Implementação de um Diagnosticador de Falha a Eventos ... · Projeto de Graduação apresentado...